>> so 4 rules for unfirewalled veth|tap traffic. >> for unfirewalled venet0 traffic, we enter PVEFW-VENET-OUT|IN, so I would >> like to find a way to bypass it
>OK maybe: -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. >>> 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. Also, I think it's breaking nat (which need conntrack), so we need to known which unfirewalled tap are doing nat. so if user have something like iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eth0 -j MASQUERADE iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eth0 -j MASQUERADE we need to do something like iptables -t raw -A PREROUTING -s '10.10.10.0/24' -j RETURN iptables -t raw -A PREROUTING -i vmbr+ ! --physdev-in venet0 -j NOTRACK iptables -t raw -A PREROUTING -i vmbr+ ! --physdev-out venet0 -j NOTRACK So, maybe it's too short if you want to release soon pve-firewall. ----- Mail original ----- De: "Dietmar Maurer" <diet...@proxmox.com> À: "Alexandre DERUMIER" <aderum...@odiso.com> Cc: pve-devel@pve.proxmox.com Envoyé: Mercredi 14 Mai 2014 16:56:02 Objet: RE: [pve-devel] [PATCH] use linko+ name for ovs fwbrint interfaces > so 4 rules for unfirewalled veth|tap traffic. > for unfirewalled venet0 traffic, we enter PVEFW-VENET-OUT|IN, so I would > like to find a way to bypass it OK > 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). > (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? _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
