[Top] [All Lists]

Re: [Bridge] Re: [RFC] bridge-netfilter patch 0.0.4pre1 available

To: Lennert Buytenhek <buytenh@xxxxxxx>
Subject: Re: [Bridge] Re: [RFC] bridge-netfilter patch 0.0.4pre1 available
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Thu, 06 Dec 2001 15:07:11 -0700
Cc: netfilter-devel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, bridge@xxxxxxxxxxxxxxxxxx
Organization: Candela Technologies
References: <20011206154334.B3632@xxxxxxx> <3C0FE155.9010303@xxxxxxxxxxxxxxx> <20011206165209.A18646@xxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2

Lennert Buytenhek wrote:

On Thu, Dec 06, 2001 at 02:21:25PM -0700, Ben Greear wrote:

2. Add members ->physindev and ->physoutdev to struct sk_buff.  This is
  necessary for 'interface transparency'; the ability to filter on enslaved
  devices in iptables rules transparently.  For example, if eth0 is enslaved
  to br0, and a packet comes in from eth0, destined for the local machine,

       iptables -A INPUT -i eth0 -j DROP

  would drop the packet if you have interface transparency.  It's easy to
  see that in this case, you need to keep at least one extra variable with
  the sk_buff to make the mentioned rule work.  In the case of a locally
  originated packet, you also need at least one extra member.  In the case
  of an IP-forwarded packet with both source and destination interfaces
  being bridge interfaces (sounds somewhat artificial, but there actually
  are such setups), you need two.

Does this scheme still work if you go:  eth0 -> vlan5 -> br0
(Does vlan5 or eth0 count as the physindev?)

I'm not familiar with how your vlan stuff works.. is 'vlan5' a kind of
bridge device in itself?  Or is it just tagged VLAN 5 over eth0?

It definately isn't a bridge...much more like the latter.  For that reason,
it's good that your bridging stuff works :)

Currently, the bridge-nf patch uses as physindev skb->dev from-when-the-
packet-was-passed-to-the-bridge-code in net_rx_action.  So, it all depends on
which device you enslaved to br0.  In the above scenario, it would look
like 'vlan5' is the one.

Good.  I think that is probably the right way for things to work because
you can not have more than one ethernet device feed a particular
vlan for firewalling reasons there should be little reason to
distinguish the physical (eth0) device while using VLANs...



Ben Greear <greearb@xxxxxxxxxxxxxxx>       <Ben_Greear AT>
President of Candela Technologies Inc

<Prev in Thread] Current Thread [Next in Thread>