Sitting on two networks with overlapping routes
hans at fugal.net
Fri Nov 30 13:25:39 MST 2007
On Fri, 30 Nov 2007 at 12:45 -0700, Michael L Torrie wrote:
> A while back I posted about a situation where I have a computer that
> sites simultaneously on the BYU private and public networks. Someone
> mentioned that linux shouldn't have a problem with this because packets
> just know to go back out the interface they came in on. This turns out
> to be untrue.
You aren't kidding. It's especially fun when someone put two NICs (with
two IPs, though they were both on the same subnet) into
the box for load balancing, but although traffic came in on both all
outbound traffic went out on one NIC. And when that NIC died, guess
what? Yeah, nothing worked. In that situation I remedied the situation
by getting rid of the 2-IP hack and delving into various matters of
bonding and which switch they got plugged into and all that jazz, so the
solution looked nothing like the original setup (not your situation).
> When I first set up the machine, with the default route set to be the
> private network, any traffic that arrived in on the public interface
> would have responses sent out the private interface, since that was the
> default route. When I set the default route to be the public
> interface, then outside computers could ping it again, but not people on
> the private network.
> The solution lies in the advanced routing features of the linux kernel.
> This is described here:
I don't remember the details now, but I have had trouble with the src
option being ignored in the past. So when you go off exploring new
possibilities don't assume that just because you specified src it
necessarily is listening to you.
I need to look at this closer and see if it will solve a problem I've
been seeing. I have an OpenVPN server using bridging (tap), with various
clients. Now, my (not rigorous) observation is that client A can ping
client B only when --client-to-client is enabled, which means that it
never comes up out of OpenVPN into the kernel for routing. But, since
that subnet is explicitly routed through tap0 I don't see why that
should be necessary. Shouldn't a packet that originated from tap0 go
back out tap0 if that's what the routing table says? Apparently not, but
I'm not sure why.
Why don't I just use --client-to-client? I do, but this is a matter of
curiousity, and I wanted to see what else --client-to-client might be
doing besides short circuiting the routing, and the docs are fairly
silent on the matter.
Hans Fugal ; http://hans.fugal.net
There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
More information about the PLUG