[SLL] Bridging two networks

[Robert Woodcock]

On Fri, May 30, 2008 at 11:46:03AM -0700, Ralph Sims wrote:
> I've never used bridging before and have now have a need for it:
> 
> I have a Linux machine connected via eth0 to a DSL line and eth1 to a LAN
> that's accessible from the Internet with public IP addresses (1.2.3.0/20).
> No filtering in place.  I can currently log in to the DSL link and access
> the Linux box.  Now I want to be able to access the devices on the other
> network.  The Linux machine's address before bridging is 10.0.0.2 and its
> gateway is 10.0.0.1.
> 
> First I took down the interfaces.  Then ifconfig eth0 0.0.0.0, and the same
> with eth1.
> 
> > brctl addbr br0
> > brctl addif br0 eth0
> > brctl addif br0 eth1
> > ifconfig br0 10.0.0.2 (so I can still get in to the box from the 
> > outside) route add default gw 10.0.0.1
> 
> So far, so good and I can ping the world.  This is where I lose it.  All
> traffic goes through the DSL link on eth0.  But I can't get to anything on
> the LAN via eth1.   There has to be something simple that I'm missing and
> Google while helpful didn't yield any solutions.

Basically, the bridge should behave like an ethernet switch.

Traffic to a certain MAC address should go out both interfaces until the
bridge learns which interface the address is on, then it should only go out
that interface. ARP who-has packets (to ff:ff:ff:ff:ff:ff) should always
go out both.

According to my reading of the Ethernet Bridge netfilter HOWTO, by default
it uses spanning tree protocol which means the interfaces will spend 30
seconds learning the network topology (30 seconds not forwarding anything).

I would check 'brctl show', 'brctl showbr br0', and 'brctl showmacs br0'
output to see if it is actually learning the MACs on each side properly. 

> IP forwarding is on.

In theory this shouldn't matter because you're forwarding packets at the
ethernet level, regardless of whether they are IP packets or not.

> I tried assigning IP addresses to each NIC and still got no joy.

That'd probably break it.

> I would have thought that the bridge would forward packets in and out of
> each discrete network transparently.

Yes, it does.

I'm not really sure what you're trying to accomplish here, because the
closer I read what you wrote, the less I think you need bridging at all.

You have two network blocks here, your public 1.2.3.0/20 and your private
10.0.0.0/8.

You say "Linux machine's address before bridging is 10.0.0.2" but don't
specify which interface that is. I'll assume since 1.2.3.0/20 was eth1,
that 10.0.0.2 is eth0, and your DSL modem (which since it's probably a DSL
line to the Internet, but 10.0.0.1 is an internal IP) is doing NAT.

You say "I can currently log in to the DSL link" but don't say what you mean
by this. Are you sshing from some other machine on the Internet to the DSL
line's public IP address? If not, then what? If so, then how do you expect
to address the other machines on 1.2.3.0/20 through this DSL link? It's not
like you have a BGP feed to your ISP - you can't tell the Internet at large
that 1.2.3.0/20 is on this DSL link right over here.

The other explanation is that you want a machine (or several, doesn't
matter) to have two paths out to the Internet and use both. Again, we're not
running BGP, we're not multihomed, you don't get to do this The Right
Way(tm). But this list isn't necessarily about that, so if this is really
what you want, I'll tell you how to do it.

Say you have a server (S) hooked up to a network with two Internet gateways
(A and B) on it. You want all outgoing traffic from S to go through link A,
but you want incoming TCP connections from both.

Normally, if you configured both A and B with NAT rules to allow the TCP
connections through, and B forwarded a TCP connection from a client on the
Internet (C) to S, then S would send the response to its default gateway -
A. A would either block this packet or send it back to C with its own
external IP address - not the one C sent the packet to. So either way, C
gets nothing useful back.

The only way for S to know which gateway to send a response back to C is
to have multiple internal IP addresses for S (S1 and S2) and route based on
the source address, not the destination. Most operating systems will not let
you do this but Linux does.

Basically you set up two routing tables, each with their own default
gateway, and set up a rule that makes any packet specially marked (with
iptables mangling) use the appropriate routing table:

ip rule add fwmark 1 table toA
ip rule add fwmark 2 table toB
ip route add default via A.A.A.A dev [interface] table toA
ip route add default via B.B.B.B dev [interface] table toB
ip route flush cache
iptables -A PREROUTING -t mangle -s S1.S1.S1.S1 -j MARK --set-mark 1
iptables -A PREROUTING -t mangle -s S2.S2.S2.S2 -j MARK --set-mark 2

There - any packets from S's first IP will go to A.A.A.A, any packets from
S's second IP will go to B.B.B.B.

Just in case you're not actually trying to do something that crazy, let me
cover the other possibilities I can think of (at least the ones where
bridging would actually have been the right thing to do):

* Your DSL line routes multiple public IPs to you (1.2.3.0/20). You want to
  set up additional systems directly in this IP space without any NAT. This
  would be basically like you had your DSL modem hooked to a network switch
  and your Linux box and several other boxes hooked to that switch - just
  without actually needing a switch. Getting a switch would certainly be
  simpler, but Linux bridging supports filtering, QoS features that other
  reasonably-priced switches don't.

* Your DSL line routes multiple public IPs to you. You want to set up
  additional systems accessible through those public IPs, but those systems
  along with several other internal systems live on a separate internal
  subnet (maybe even a couple separate internal subnets). For this, you can
  tell your Linux box to listen on those public IPs, use iptables NAT rules
  to translate the external addresses to internal addresses, and use
  iptables FORWARD rules to allow external traffic to those internal
  addresses.

Anyway, some more specifics on what exactly you are trying to do will help
us figure out how to help you get it working.
-- 
Robert Woodcock - rcw at blarg.net
"Now string theory, your theory, let me just try to recap what you said to us
before - it's multidimensional vibrating strings that are so small that there's no
way to ever measure whether they exist or that the state of the universe
that you describe in your mathematics can be quantified in physical
verifiable ways on any level at any imaginable point in the future, and yet,
people still take you seriously?"
	-- Stephen Colbert to Brian Greene