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@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 http://vger.kernel.org/majordomo-info.html
