On Tue, 2012-01-03 at 13:15 +0000, Steve Hill wrote: > 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.). <snip> I wonder if you could integrate tc and iptables here. I haven't thought it all the way through but you could do something like setup an ingress qdisc and use a tc filter ipt action (action ipt -j MARK --set-mark) to mark packets based upon the iif so you know where it came and then examine that mark on egress with a u32 filter with all the other match parameters and drop it if necessary. I'm not all that familiar with using tc is such a way but that would get you back to the physical interfaces - John -- 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
