[TriLUG] Routing...once again.

Ryan Leathers ryan.leathers at globalknowledge.com
Tue Aug 8 10:32:53 EDT 2006


Maybe there is a slick way to do this using Linux.  I don't know what
that is though.  The easiest way I can think of to solve this is to use
a router or firewall to perform outside source NAT. 

If you happen to have a Cisco router or firewall I can tell you exactly
how to configure this, but in general terms it works this way:

Suppose you have this network

So some terms:
the vpnclienthost ip address is called the outside global address
the isp side of the firewall is called the outside local address
the lan side of the firewall is called the inside global address
and Bob's Eth1 is called the inside local address

What you need to do is translate source addresses as they pass from
outside to inside, so this type of NAT is called "outside source nat"

When a packet from the outside global reaches the firewall's outside
interface, you want it to be translated to a predetermined address.

(If I were doing this on a Cisco device I would make a decision here to
use either ip nat outside source (static OR list) depending on whether I
knew what all the outside globals would be in advance.)

After the packet is translated to use a new source address, say, it is then routed to the destination address which is
your inside local (Bob's Eth1).

When Bob responds, he sends the reply traffic to the destination address
of the inside global.  You simply give Bob a static route to for example, so he will always route the VPN traffic out
his Eth1.

When the reply reaches the firewall's inside interface the NAT process
will put the original address back in the destination field and route it
on its way.

I don't know what equipment you may be using or what its capabilities
are, but I would hope it could do outside source NAT.  If not, at the
very least a crusty old 2500 series can probably be had these days for
under $20 and it would do a superb job on a link sporting sub-10MBPS
line rates.     

Now then, even though this would work, I wouldn't do it this way.
Instead, I would connect both the DSL and the Cable devices to a router
and then use policy based routing to select the path.  This is a much
cleaner, centralized, and scalable way to control traffic, by traffic
type (or other criteria), to multiple ISPs.  If you'd like more detail
on this I'm happy to pontificate.

On Tue, 2006-08-08 at 08:43 -0400, Brian Henning wrote:
> Hi Gang,
>    I know y'all are probably tired of hearing me ask about this stuff, 
> but for some reason it's just one thing I'm having a heck of a time 
> really grasping.  I think it's because I'm missing some fundamental 
> understanding, some important piece of info, which is leaving the rest 
> of it shaky.  Anyway:
> I have a machine (let's call it "bob") with two NICs, on two subnets, 
> for argument's sake and  eth0 is on 
> .1.0, eth1 is on .10.0.  Both subnets have their own gateways, located 
> at .1.1 and .10.1.
> Because of certain important services that come in through the gateway 
> on the .1.0 subnet (such as SMTP, httpd, ssh, etc.), I need bob's 
> default gateway to be .1.1.  However, I really really really want to run 
> OpenVPN on bob and have it move traffic solely in and out through the 
> .10.1 gateway.  That service on that machine never needs to move a 
> single packet out of the default gateway.
> I know that that's impossible without some sort of fiddling; even if UDP 
> packets come in to OpenVPN via the correct gateway (.10), the responses 
> are routed out through the .1 gateway and dropped somewhere along the 
> way (or ignored, if they make it all the way back to the client).
> I figure it must be doable, though, right?  I shouldn't have to have a 
> separate box to provide the exact same services through two different 
> gateways, should I?  So what's the magic incantation?  route tricks? 
> iptables tricks?  Clever misuse of load-balancing software?  I'm open to 
> all suggestions.
> Thanks!
> Cheers,
> ~Brian
> -- 
> ----------------
> Brian A. Henning
> strutmasters.com
> 336.597.2397x238
> ----------------

More information about the TriLUG mailing list