packet mangling and routing

Lonnie Olson lists at
Tue Oct 16 12:19:04 MDT 2007

On Tue, 2007-10-16 at 08:58 -0600, Michael L Torrie wrote:
> This is for any iptables and networking gurus out there.  I have a
> server that sits on both the BYU private and public network.  The one
> NIC is on a 10.x.x.x/24 network, and the other is on the 128.187.x.x/24
> network.  This is, of course a bit of a problem, because there can be
> only one default route.  Now one would think, then, that we could
> trivially add static routes, keeping 10.x traffic on the one NIC, and
> then everything else on the 128.187 NIC.  But the problem is that inside
> of BYU, computers who are also on the 10.x network can reach both 10.x
> addresses *and* 128.187. addresses.  So in the worst case, traffic from
> a fellow 10.x node will come in the 10.x NIC and return traffic will go
> out the 128.x NIC, which  I don't think is going to really work,
> especially if the originating computer is running a firewall, since
> connection tracking just isn't going to work, and the packet won't be
> recognized as being a reply.

Why won't this work?  If a fellow 10.x node requests traffic from your
10.x address, the source IP is 10.x.  There should be a route in the
routing table for the 10.x network to traverse the private interface.
No problem, exactly what you want.

The routing table is consulted per packet, not per connection.  The
default route is only used when a connected or static route doesn't

Example routing table:
Destination	Genmask		Gateway		Iface	eth0		eth0		eth1	eth1

Explanation.  eth0 is the public interface.  eth1 is the private.  
There are two connected routes (public and private), a default route,
and a static route.  No outbound packets destined to 10.x addresses will
ever touch the public interface, no matter what interface the packet
comes in on.  

The key is to remember that routing is per packet by destination.  It is
perfectly valid to have return traffic travel through a different
interface than the source traffic.


More information about the PLUG mailing list