Re: [LARTC] What I learned about Linux bridging

[Grant Taylor <gtaylor@riverviewtech.net>]

On 6/7/2007 12:12 AM, Greg Scott wrote:
> The IP Address for br0 is 1.2.3.2.  I setup a system at 1.2.3.1 and 
> had it ping 1.2.3.2.  Everything behaved as expected.  With bridging 
> turned on, none of the iptables rules made any difference, so I 
> commented them out.  With the cable plugged into eth0, none of the 
> pings replied.  Tcpdump on the 1.2.3.2 box didn't even show anything 
> coming into br0.  Connecting to eth1 or eth2, pings replied and 
> tcpdump showed the ICMP going back and forth on br0.  Setting br0 to 
> 1.2.3.2 and eth1 to 10.0.0.1, my external host could ping both IP 
> Addresses when I fudged in appropriate routes on my test system.

Ok, good to know.

The only other thing that I can think of why you might bind your IP 
address(es) to the physical interface verses the bridge interface is if 
you were not wanting to bridge IP, but some other non routeable 
protocol, say NetBEUI.  (But why would you want to do that???)  In this 
scenario, it would be perfectly normal to use a bridging router to 
bridge any thing but IP and route IP.

> Here are a couple of my challenges.
> 
> I want to block anything coming in from the Internet claiming to come 
> from 10/8, or 172.16/12 or 192.168/16.  But anything from these 
> address blocks from any trusted eth-- interface should be OK.  Easy  
> to do with pure routing, seems a little more challenging with 
> bridging.  I think I can whip up some rules, but they depend on 
> ebtables filtering by physical eth-- port.

You should be able to easily do this with a few EBTables rules.  Just 
check the source IP of the packets as they come in eth0.

ebtables -t filter -N bogonsFromNet -P RETURN
ebtables -t filter -A bogonsFromNet -s 10.0.0.0/8 -j DROP
ebtables -t filter -A bogonsFromNet -s 172.16.0.0/12 -j DROP
ebtables -t filter -A bogonsFromNet -s 192.168.0.0/16 -j DROP

ebtables -t filter -A INPUT -j bogonsFromNet
ebtables -t filter -A FORWARD -j bogonsFromNet

(Note:  This is untested.)

If I have things correct, this should be a simple chain that checks the 
source IP and blocks drops them if they match.  The (new) chain its self 
has a default policy of RETURN to return back to the chain that jumped 
to it.

You might want to expand your bogons list a bit more to include some 
more forbidden networks.  I.e. Test Net 192.0.2.x/24...  RFC 3330 is 
your friend in this matter.

> I have a public /24 block, call it 1.2.3.nnn.  Some of these are on 
> eth0, some on eth1, a few others on eth2.  Bridging seems to handle 
> this nicely.  eth0 faces the Internet.  I am a little nervous in 
> packaging all this.  Let's say something goes haywire in startup, 
> before I run the brctl stuff.  Or let's say something bad happens and 
> bridging goes haywire.  If eth0 has no IP Address, I have no remote 
> access to the box.  So I'd like to at least give an IP Address to 
> eth0.  This  seems to work, but like I said, it's not documented to 
> work.  It just hit me what's bugging me - it bugs me to give an IP 
> Address to a logical device and cut off any kind of fallback access 
> to the physical device.  Maybe I'm looking for trouble that's not 
> there and creating problems I don't need just because bridging is so 
> new in my little world.  I wonder what others have done in this 
> situation?

I don't think you are being too paranoid, but I think you should be 
aware of something I have run in to in my own testing.

If I have eth0 up with an IP address w.x.y.z and I am connected to it 
(via ssh) and I enslave it to a bridge (bri0) (I like 3 letter / 1 
number device names) my connection goes dead.  I have to try 
reconnecting or log in to console and move the IP to the bridge.  Well, 
at least I think that's what I have to do, it's been too long sense I 
last did it and I don't remember the details.  You may want to play with 
this.  The reason that I bring it up is that I think an IP address on 
the ether interface is different than an IP address on the enslaved 
ether interface.  Your mileage may vary.  What I'm worried about is that 
if the bridging code is seeing the traffic before the system's IP stack 
sees it (supported by the fact that you can use EBTables to filter it), 
you are still passing through the bridging code even with the IP address 
on the enslaved ether interface.

I have personally used bridging extensively for the past 4+ years and 
I've been ABSOLUTELY THRILLED with it.  I have some systems with four 
interfaces bridged together with all IPs on the bri0 interface.  I have 
another system that is 802.1q trunking to a Layer 2 managed switch with 
25+ VLAN interfaces on the trunk.  I'm then bridging the 25+ VLANs plus 
the enslaved ether interface in one bridge with the IP bound to bri0.  I 
then have EBTables dividing up what access each VLAN has.  Specifically, 
each VLAN can communicate with the bri0 interface and the bri0 interface 
can communicate with all VLANs, but the VLANs can not communicate with 
each other.  I even threw in ARP tables and EBTables to masquerade MAC 
addresses b/c the managed switch that I was working with could only see 
any given MAC on one VLAN.  Let's just say this was fun to set up.  In 
the end, the system has been up and running with out problems at multi 
megabit speeds for 3+ years.

> And then there's my PPTP clients.  I give these guys a 10.0.0.xxx IP 
> Address with a gateway of 10.0.0.1.  This was all  part of the eth1 
> LAN when it was a pure router.  I suppose in this bridging setup, I 
> could make 10.0.0.1 an alias for br0 and leave eth1 with no IP 
> Address.  This just takes a little getting used to I guess.

I don't think you should be scared of bridging and / or EBTables.  With 
them you can do a LOT of things you could not do other wise.



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc