Re: Filtering on bridges

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

On 23/12/11 04:33, Vigneswaran R wrote:

Sorry for interrupting your discussion. I am following this thread from
the beginning. However, I couldn't get exactly how your setup looks
like. If possible, could you please give a simple (ascii) pictorial
representation of your setup. This may help more people (normal iptable
users like me) to understand the discussion better. Thank you.

|                        Linux Server                       |
|                                                           |
|                            (br0)                          |
|                              |                            |
|     +------------+-----------+-----------+-----------+    |
|     |            |           |           |           |    |
|  (eth0)       (eth1)      (eth2)      (eth3)      (eth4)  |
      |            |           |           |           |
      |            |           |           |           |
+----------+  +--------+  +--------+  +--------+  +--------+
| Upstream |  | Other  |  | Other  |  | Other  |  | Other  |
|  Switch  |  | Server |  | Server |  | Server |  | Server |
+----------+  +--------+  +--------+  +--------+  +--------+

As you can see, the Linux server has several network interfaces, all of which are bridged together. I'm using iptables to filter the traffic between those NICs. Filtering bridged traffic largely works as expected (although there is an issue that using REJECT filter rules causes the kernel to panic as the ICMP response is injected into the bridge!) This means I can write iptables filter rules in the FORWARD chain using the physdev module to reference the physical NICs (e.g. "DROP TCP traffic from eth0 to eth1 that has a destination port == 25")

The issue I'm having is that traffic that has passed through the local IP stack (whether that be from a local process, or routed) is handled differently to traffic that is being bridged - iptables is no longer aware of the physical NIC from which the traffic will egress. I.e. for this traffic I can only create rules referencing the whole bridge (br0) rather than individual physical NICs (eth0, eth1, etc.).

The following is NOT a description of what actually happens, it is what I believe would be a cleaner model than the current system: Logically, I would say that routing and bridging are two completely different processes, so should have separate chains. i.e. the PREROUTING, FORWARD, POSTROUTING and OUTPUT chains should refer *only* to traffic that is passing through the IP stack, and there should be separate PREBRIDGE, FORWARDBRIDGE, POSTBRIDGE chains for the bridged traffic. The bridge interface (br0) should be seen as just another member of the bridge, exactly like the physical NICs.

So following the above idea, a packet generated by a local process would pass though:
iptables:OUTPUT (egress NIC: br0)
iptables:POSTROUTING (egress NIC: br0)
ebtables:BROUTING (ingress NIC: br0)
ebtables:PREROUTING (ingress NIC: br0)
iptables:PREBRIDGE (ingress NIC: br0)
ebtables:FORWARD (ingress NIC: br0, egress NIC: eth0)
iptables:FORWARDBRIDGE (ingress NIC: br0, egress NIC: eth0)
iptables:POSTBRIDGE (ingress NIC: br0, egress NIC: eth0)
ebtables:POSTROUTING (ingress NIC: br0, egress NIC: eth0)

And similarly, a bridged packet would look something like:
ebtables:BROUTING (ingress NIC: eth1)
ebtables:PREROUTING (ingress NIC: eth1)
iptables:PREBRIDGE (ingress NIC: eth1)
ebtables:FORWARD (ingress NIC: eth1, egress NIC: eth0)
iptables:FORWARDBRIDGE (ingress NIC: eth1, egress NIC: eth0)
iptables:POSTBRIDGE (ingress NIC: eth1, egress NIC: eth0)
ebtables:POSTROUTING (ingress NIC: eth1, egress NIC: eth0)

Unfortunately this isn't what happens :)

Hope that explains what I'm talking about anyway. In my case, the "other servers" are actually virtual machines running on the Linux server, so "eth1..4" aren't really physical NICs, they are tun/tap interfaces. But for the purpose of this discussion, that is unimportant.


 - Steve Hill
   Technical Director
   Opendium Limited

Direct contacts:
   Instant messager: xmpp:steve@xxxxxxxxxxxx
   Email:            steve@xxxxxxxxxxxx
   Phone:            sip:steve@xxxxxxxxxxxx

Sales / enquiries contacts:
   Email:            sales@xxxxxxxxxxxx
   Phone:            +44-844-9791439 / sip:sales@xxxxxxxxxxxx

Support contacts:
   Email:            support@xxxxxxxxxxxx
   Phone:            +44-844-4844916 / sip:support@xxxxxxxxxxxx
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Linux Netfilter Development]     [Linux Kernel Networking Development]     [Linux Networking Development]     [Linux Kernel Development]     [Linux Resources]     [LARTC]     [Bugtraq]     [Consulting]     [Free Internet Dating]     [Yosemite Forum]     [Photo]

Add to Google Powered by Linux