From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Hill Subject: Re: Filtering on bridges Date: Tue, 03 Jan 2012 13:15:13 +0000 Message-ID: <4F02FF61.5020806@opendium.com> References: <4EF1B216.50303@opendium.com> <4EF1E3B0.6080200@opendium.com> <4EF26A14.2070409@opendium.com> <4EF30CCC.4090703@opendium.com> <4EF36A9A.3040803@opendium.com> <4EF40499.3020005@atc.tcs.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4EF40499.3020005@atc.tcs.com> Sender: netfilter-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Vigneswaran R Cc: Jan Engelhardt , netfilter@vger.kernel.org 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