[pve-devel] RFC : iptables implementation

Alexandre DERUMIER aderumier at odiso.com
Wed Jan 22 20:12:24 CET 2014


>>Oh, I guess that is why you use --physdev-is-bridged?
So we simply accept routed traffic from the host? 

Too be honest, I just copied rules from openstack, I don't have read the doc yet about  --physdev-is-bridged.
But openstack add incoming rules for dhcp packets coming from the host.

They also add an -input rules for outgoing packet from tap. (I think this for from tap to host)


-A INPUT -j proxmoxfw-chain-INPUT
-A FORWARD -m physdev --physdev-out tap100i0 --physdev-is-bridged -j proxmoxfw-chain
-A FORWARD -m physdev --physdev-in tap100i0 --physdev-is-bridged -j proxmoxfw-chain

>> -A proxmoxfw-chain-INPUT -m physdev --physdev-in tap110i0 --physdev-is-bridged -j tap110i0-OUT

-A proxmoxfw-chain -m physdev --physdev-out tap100i0 --physdev-is-bridged -j tap100i0-in
-A proxmoxfw-chain -m physdev --physdev-in tap100i0 --physdev-is-bridged -j tap100i0-out



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

De: "Dietmar Maurer" <dietmar at proxmox.com> 
À: "Alexandre DERUMIER" <aderumier at odiso.com> 
Cc: "pve-devel" <pve-devel at pve.proxmox.com> 
Envoyé: Mercredi 22 Janvier 2014 19:45:41 
Objet: RE: [pve-devel] RFC : iptables implementation 


> I am also concerned about this: 
> 
> --quote-shorewall-docs-- 
> As described above, Shorewall bridge support requires the physdev match 
> feature of Netfilter/iptables. Physdev match allows rules to be triggered based 
> on the bridge port that a packet arrived on and/or the bridge port that a packet 
> will be sent over. The latter has proved to be problematic because it requires 
> that the evaluation of rules be deferred until the destination bridge port is 
> known. This deferral has the unfortunate side effect that it makes IPSEC 
> Netfilter filtration incompatible with bridges. To work around this problem, in 
> kernel version 2.6.20 the Netfilter developers decided to remove the deferred 
> processing in two cases: 
> 
> When a packet being sent through a bridge entered the firewall on another 
> interface and was being forwarded to the bridge. 
> 
> When a packet originating on the firewall itself is being sent through a bridge. 
> 
> Notice that physdev match was only weakened with respect to the destination 
> bridge port -- it remains fully functional with respect to the source bridge port. 
> --end-quote-- 
> 
> I above is right, things will not work as expected. 

Oh, I guess that is why you use --physdev-is-bridged? 
So we simply accept routed traffic from the host? 



More information about the pve-devel mailing list