> > > > You do have the correct brouting rules in place don't you? eg: > > > > > > > > ebtables -t broute -A BROUTING -p 802_1Q -i eth0 -j DROP > > > > > > > > This makes sure that the 802.1q tagged packets coming in on eth0 > are > > > > not sent over the bridge as is, but are 'routed' internally to the > > > > vlan code, where they are decapsulated and then maybe routed to > > bridges. > > > > > > > > > > I was not aware that, that was required. I assumed that since I had > > > the eth0.40 and eth3.40 set-up then the packets would be routed > > > correctly, as I have. > > > > > > Eth0---------br0------------eth1 > > > Eth0.40------b1-------------eth1.40 > > > > > > So do I need to add in the ebtables rule? > > > > > > > That does seem to fix it with the ebtables rule. > > > > I now see the traffic going over the bridge, I will have to wait till > > Monday > > to fully check that it is working. > > > > I can also now see the traffic going over br1 in iptables but not br0 > > which > > is strange. > > > > Not so strange once you get your head around how it all hangs together > (someone please correct me if what I'm saying is wrong). > > When a tagged (or untagged) packet comes in on the Ethernet interface, > it is first presented to the bridge. If the bridge accepts it (broute's > it), then the packet is taken from the ethernet interface and routed > onto the bridge interface, so your bridge would contain both tagged and > untagged (native) packets. If the machine running the bridge doesn't > care about the vlans at all, then this would probably just work (unless > you have a rule in your iptables that doesn't like the tagged packets). > > If the bridge doesn't accept the packet (a DROP on the BROUTING chain in > the broute table in ebtables), then the packet is passed to the next > thing listening on the Ethernet interface, which should be vlan. The > vlan see's the tagged packet, removes the tag, and 'routes' it onto the > eth0.X interface. Then the whole cycle begins again, only this time the > bridge code does pick it up, and routes it onto the appropriate bridge. > > With the above in mind, you should see why iptables does or doesn't see > a packet. If it isn't obvious, don't rule out the possibility that > something I've said above is not quite right, and do post the rule you > expect to see the packet on and we'll have a look. I believe that > iptables only see's the packet once the IP stack get's involved, which > is after bridging and vlan have both had a crack at it. > > Now, I have a vague idea that there is some trickery involved concerning > exactly where tcpdump fits in here... I think it see's all the packets > that get received on a physical interface, but it might have a blind > spot concerning packets transmitted from the bridge and/or vlan stacks, > or maybe I'm thinking of when I was first figuring out the above and had > one of my rules backwards... > > Fun, isn't it! And very confusing it. Hopefully I will find out tomorrow everything is working and then I have to start to enforce rules on it, to limit the destinations. I was hopping to do this with iptables as I know them better than ebtables but tend to cheat and use shorewall. I am not sure why I see the packets on br1 but not br0 through iptables. Adam ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. http://www.mettoni.com **********************************************************************
