From: Steve Hill <steve@opendium.com>
To: netfilter@vger.kernel.org
Subject: Filtering on bridges
Date: Wed, 21 Dec 2011 10:16:54 +0000 [thread overview]
Message-ID: <4EF1B216.50303@opendium.com> (raw)
I have previously used iptables to filter traffic on bridged interfaces
using the physdev module. However, recently it seems there was a change
in the semantics of physdev:
For bridged traffic (i.e. traffic that is coming in through one physical
NIC, traversing a bridge and being sent out of another one without being
routed), physdev still works as expected.
However, for traffic that has gone through the machine's own IP stack
(either by being routed or by being generated locally), --physdev-out is
no longer allowed. At the time the iptables rules are being executed,
the only thing you know is the logical bridge interface it is being
routed to rather than the physical NIC it will eventually be sent from.
Is there a recommended method of filtering this traffic based on the
physical NIC it is being sent out of, now that the deferred rule
functionality has been removed? ebtables doesn't really seem to be an
option since it is nowhere near as powerful as iptables when it comes to
IP filtering.
Background:
I'm running virtualised servers which are bridged to the physical
network (this makes VM migration between physical hosts possible - doing
this using a routed infrastructure would be messy since the routers
themselves would need to be adjusted during VM migration). I run
iptables/ip6tables on the host machine in order to firewall the VMs and
also for statistics reporting - these iptables rules reference each VM's
network interface. I would like to be able to filter routed traffic in
the same way as the bridged traffic, but this involves knowing which VM
it is destined for (and hence which NIC it will be sent to).
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com
Direct contacts:
Instant messager: xmpp:steve@opendium.com
Email: steve@opendium.com
Phone: sip:steve@opendium.com
Sales / enquiries contacts:
Email: sales@opendium.com
Phone: +44-844-9791439 / sip:sales@opendium.com
Support contacts:
Email: support@opendium.com
Phone: +44-844-4844916 / sip:support@opendium.com
next reply other threads:[~2011-12-21 10:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-21 10:16 Steve Hill [this message]
2011-12-21 13:30 ` Filtering on bridges Jan Engelhardt
2011-12-21 13:48 ` Steve Hill
2011-12-21 15:36 ` Niccolò Belli
2011-12-21 18:36 ` Jan Engelhardt
2011-12-21 23:21 ` Steve Hill
2011-12-21 23:31 ` Jan Engelhardt
2011-12-22 10:56 ` Steve Hill
2011-12-22 16:28 ` Jan Engelhardt
2011-12-22 17:36 ` Steve Hill
2011-12-22 22:05 ` Jan Engelhardt
2011-12-23 4:33 ` Vigneswaran R
2012-01-03 13:15 ` Steve Hill
2012-01-03 16:09 ` Jan Engelhardt
2012-01-03 18:43 ` John A. Sullivan III
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EF1B216.50303@opendium.com \
--to=steve@opendium.com \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.