[pve-devel] [PATCH] use linko+ name for ovs fwbrint interfaces

[Alexandre DERUMIER]

> like this, we do lookup in PVEFW-venet0 ipset only for venet0 traffic, to
> known if it's firewalled or not.

Is that different than this?

-A PVEFW-FORWARD -i venet0 -m set --match-set PVEFW-venet0-ipset src -j PVEFW-VENET-OUT

If so, why?

a small difference:

1)
-A PVEFW-FORWARD -i venet0 -m set --match-set PVEFW-venet0-ipset src -j PVEFW-VENET-OUT

all unfirewalled packets (fwpr+->vmbr+) for example, will lookup inside the ipset PVEFW-venet0-ipset

2)
-A PVEFW-FORWARD -i venet0 -j PVEFW-VENET-OUT
    -A PVEFW-VENET-OUT  -m set --match-set PVEFW-venet0-ipset src -j RETURN

only venet0 will lookup inside the ipset PVEFW-venet0-ipset. (other traffic will only lookup -i venet0).

Maybe this can improve performance ?
But both are technically correct.







> but current code allow only filter table (we need to use table raw), and I'm 
> not sure it's possible to manage multiple table currently. 
> I have had a look at it, but I'm a bit lost in the code. 
> 

>>Oh no - I don't want to do that. Let's keep what we have for now. 

That's why I thinked too ;)



One last missing thing currently, is to enable nat for fwbr tap.
We need to add an option "nat" for example, and do

iptables -t raw -A PREROUTING -i fwbr110i0 -j CT --zone 1 
(kernel 3.10)







----- Mail original ----- 

De: "Dietmar Maurer" <dietmar at proxmox.com> 
À: "Alexandre DERUMIER" <aderumier at odiso.com> 
Cc: pve-devel at pve.proxmox.com 
Envoyé: Mercredi 14 Mai 2014 18:09:32 
Objet: RE: [pve-devel] [PATCH] use linko+ name for ovs fwbrint interfaces 

> -A PVEFW-FORWARD -i venet0 -j PVEFW-VENET-OUT 
> -A PVEFW-VENET-OUT -m set --match-set PVEFW-venet0-ipset src -j 
> RETURN 
> -A PVEFW-FORWARD -m physdev --physdev-in fwln+ --physdev-is-bridged -j 
> PVEFW-FWBR-IN 
> -A PVEFW-FORWARD -m physdev --physdev-out fwln+ --physdev-is-bridged 
> -j PVEFW-FWBR-OUT 
> -A PVEFW-FORWARD -o venet0 -j PVEFW-VENET-IN 
> -A PVEFW-VENET-IN -m set --match-set PVEFW-venet0-ipset dst -j RETURN 
> 
> 
> like this, we do lookup in PVEFW-venet0 ipset only for venet0 traffic, to 
> known if it's firewalled or not. 

Is that different than this? 

-A PVEFW-FORWARD -i venet0 -m set --match-set PVEFW-venet0-ipset src -j PVEFW-VENET-OUT 

If so, why? 

> >>> also, 
> > 
> > I don't known if we want to keep 
> > -A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j 
> ACCEPT 
> > for non firewalled vms ? 
> 
> >>no opinion (AFAIK you wanted that). 
> 
> If we keep conntrack for non firewalled vm, it make sense to have it early. 
> if not, we can put in at begin of PVEFW-FWBR-IN|OUT, PVEFW-VENET- 
> OUT|IN. 
> 
> 
> > (do we want to conntrack non firewalled vms ? can improve performance, 
> > but in case of firewall attack (synflood for example), if conntrack if full, 
> this 
> > will impact non firewalled vms) 
> 
> 
> >>I guess it is better to do not touch traffic for non firewalled vms. Do you 
> >>want to provide that patch? 
> 
> I'm not sure it super easy ;) 
> 
> we need to do something like 
> 
> iptables -t raw -A PREROUTING -i vmbr+ ! -o venet0 -j NOTRACK 
> iptables -t raw -A PREROUTING -o vmbr+ ! -i venet0 -j NOTRACK 
> (should not track tap->vmbr,veth->vmbr,fwpr->vmbr) 
> iptables -t raw -A PREROUTING -i vnet0 -m set ! --match-set PVEFW-venet0- 
> ipset dst -j NOTRACK 
> iptables -t raw -A PREROUTING -o vnet0 -m set ! --match-set PVEFW-venet0- 
> ipset -j NOTRACK 
> (should not track vnet0 non firewalled) 
> 
> 
> 
> 
> but current code allow only filter table (we need to use table raw), and I'm 
> not sure it's possible to manage multiple table currently. 
> I have had a look at it, but I'm a bit lost in the code. 
> 

Oh no - I don't want to do that. Let's keep what we have for now.