Re: Filtering on bridges

[Steve Hill <steve@opendium.com>]

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     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