[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] Xen 3.4.2 networking help

  • To: "Simon Hobson" <linux@xxxxxxxxxxxxxxxx>, <Xen-users@xxxxxxxxxxxxxxxxxxx>
  • From: "Jonathan Tripathy" <jonnyt@xxxxxxxxxxx>
  • Date: Wed, 27 Oct 2010 10:05:27 +0100
  • Cc:
  • Delivery-date: Wed, 27 Oct 2010 02:08:32 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: Act1slcDe0Y0KoSCTDu7ch+Fl+hhUgAA8Haq
  • Thread-topic: [Xen-users] Xen 3.4.2 networking help

When a bridge is involved, there is a problem with physdev match (if
I recall correctly) which means that outbound traffic on the firewall
machine cannot be filtered because of the sequence in which the net
stack does operations. The practical result is that you cannot apply
rules filtering traffic which originates on the firewall and leaves
via a bridge interface. I vaguely recall it's to do with the
matching/filtering happening before the outbound interface is
determined - and that in turn is related to requirements for handling
VPN traffic. You can still filter inbound traffic, and you can still
forward transiting traffic - it's only outbound traffic that
originates on the firewall that is a problem.

That is my understanding from following the Shorewall list for some time.


If you are refering to the OUTPUT chain of the Dom0 itself, surely you wouldn't use physdev at all? Wouldn't you just use "iptables -A OUTPUT -o ethx ...."?

In any case, I don't block by interface on the Dom0's OUTPUT chain. No real need to when the INPUT chain is protected with "iptables -A INPUT -i ..."
I only ever use physdev on the FORWARD chain, which works for both incoming and outgoing traffic.

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.