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: > http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html 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 /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
