WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

RE: [Xen-users] Xen 3.4.2 networking help

:

>Yes, "-o ethx" is indeed a device match, but it works differently to
>physdev, which really only works well on fordwarded traffic
>(Although I think it is supposed to work on all bridged traffic)

I'll bow to your significantly greater knowledge in this area ! But
the penny drops now, is ethx a real port or a bridge port ? I'll
hazzard a guess filtering output to the bridge interface (eg br0)
would be handled differently to filtering output to a specific port
on the bridge.

>
>Can you please post a link to information about this? I can't find
>anything on Google about this.

This for starters :
http://www.shorewall.net/bridge-Shorewall-perl.html
>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.

-----------------------------------------------------------------------------------------------------------------------------------------------------------
 
Hmm that's interesting. I guess my general rule of thumb is that I only ever use physdev--in and physdev--out for traffic which is on the FORWARD chain (specifically for DomU which have public IPs assigned to them). I'm a little confused about what "When a packet being sent through a bridge entered the firewall on another interface and was being forwarded to the bridge." means. Does that sentence mean that traffic destined for the INPUT chain of the firewall?
 
I would agree that I don't think using physdev to specify a specific bridge port works for the OUTPUT chain. In my example above, "-o ethx" would be e.g. br0. I guess that since my Dom0 is not used by untrusted parties, then I don't have a need to filter by specific bridge (i.e. real) port.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users