[CentOS] Addressing outgoing connections to a specific interface

Mon Nov 8 16:14:33 UTC 2010
Les Mikesell <lesmikesell at gmail.com>

On 11/8/2010 3:34 AM, Dotan Cohen wrote:
> On Sat, Nov 6, 2010 at 23:19, Bob McConnell<rmcconne at lightlink.com>  wrote:
>> To amplify this just a little bit, by the rules of IP routing, every
>> machine must:
>>
>> A) Have a unique address.
>> B) Be attached to the proper subnet for that address as defined by the
>> local netmask.
>>
>> Once those are true, there exists a unique route between any two
>> machines connected to the network, or the Internet.
>>
>
> Both those conditions are met in this use case, however the machine in
> question is on two networks:
>
> |--Network1--|--Network2--|
> A            C            B

You are missing the big picture and the most fundamental thing about 
internet connectivity and routing.  There aren't 2 networks.  Everything 
you can reach is one network.  On the public side, unique addresses are 
enforced because there is a hierarchy of address delegation.  On private 
networks behind NAT you can do anything you want, but it isn't going to 
work unless you have unique addresses for all reachable destinations. 
Your problem is an unfortunate consequence of virtually all 
consumer-type NAT routers using 192.168.0/24 as their default internal 
subnet. IP protocols use the destination address early in the routing 
decision to pick the interface to use to send to the next hop.  That 
can't work if you have to send to the same destination address in 2 
different places.  If you are interested in learning about this, find an 
IP routing reference that show the address and netmask as binary values. 
It is very easy to understand when you line up the bits of the addresses 
and netmasks in binary.

> A: router on the wireless network
> B: router on the wired network
> C: CentOS laptop
>
> Each router has a unique address on it's own network, as per spec.

No, once these subnets are connected to a common machine, you have one 
network. But it won't work.

> The laptop is connected to two networks, on two different interfaces.
> The networks were never designed to be connected, and in fact there is
> no connection between them.

As soon as your machine connects to both they are connected.

> Correct me if I'm wrong, but NAT is what C would do to let a computer
> on Network1 access a resource on Network2. C would be the gateway,
> rerouting packets between the two networks and correcting for address
> used on both sides.

Yes, but you have to present a unique address for forwarding.  An 
intermediate machine with an intermediate subnet range could nat and 
present a different address to you, but one machine can't deal with 2 
different directly connected destinations with the same address.

> However, I am not trying to create a gateway! In this case, C itself
> (as a workstation) needs to access resources on both networks.

There's no difference in routing packets that have come from some other 
machine and routing packets from your own applications.  The IP layer 
that decides where to send the packet for its next hop will look at the 
destination address and has to be able to figure out which interface to 
send it out.  That's obviously impossible when you have the same address 
connected to two different interfaces at the same time.

There are an assortment of ways to tackle the problem if you can't apply 
the obvious solution and change the subnet addressing on one side or the 
other.   The simplest might be to run a virtual machine (vmware, 
virtualbox, etc.) that is bridged to the wireless interface without 
letting the host itself get an address there.  That would maintain the 
isolation you need between the target addresses.  Or, you could arrange 
for some other connection (vpn or physical) to a machine on the wireless 
network (even the virtual machine above), where this connection would 
have it's own unique subnet range.  Then you'd be able to use nat or a 
proxy to get forwarding to the other subnet, hiding the real destination 
address.

-- 
   Les Mikesell
     lesmikesell at gmail.com