[CentOS] Simple routing question

Thu Sep 6 19:04:11 UTC 2012
James B. Byrne <byrnejb at harte-lyne.ca>

Per: Les Mikesell lesmikesell at gmail.com
Thu Sep 6 14:20:43 EDT 2012

On Thu, Sep 6, 2012 at 1:09 PM, James B. Byrne <byrnejb at
harte-lyne.ca> wrote:

> OK, there is no better match than the default in the route table
> above, so it goes to the default gateway.  I assume that's what you
> want if you don't make the netmask span the 192.168.x.x range, but a
> side effect is that it will source from the aaa.bbb.ccc.x interface
> address.

> This seems to say that is being routed out to the
> Internet as aaa.bbb.ddd.53 is our external gateway address on the
> router.
> This is the routing table on the router:
> [root at gway01 ~]# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref
> Use Iface
> aaa.bbb.ddd.52 U     0      0
> 0 eth0
> aaa.bbb.ccc.0   U     0      0
> 0 eth1
>     U     1002   0
> 0 eth0
>     U     1003   0
> 0 eth1
>         aaa.bbb.ddd.53         UG    0      0
> 0 eth0

I don't see any 192.168.x.x interface/mask there.   Where else could
it go?   Or is that 2nd a typo?

You see, this is the question I am trying to fathom.  Once upon a
time, 2 days ago, the interface on the gateway system included
ifcfg-eth1:192 which had the address and the netmask  At that point I was not aware of any underlying
problems and virtual interfaces on other hosts which had addresses
like 192.168.216.ddd could be found and connected to from internal
host addresses of the form aaa.bbb.ccc.0 where aaa.bbb.ccc is our
publicly routable C class assigned address block.

The difficulties started when I began testing a new virtual host which
eventually will be moved off-site to our DR facility (which is a lot
less impressive in fact than it appears when I write that, but at
least we have one).  On that machine, for no particular reason, I
decided to use a different sub-net for the 192.168 IP on the VM guests
eth1 i/f.

When I did that the kvm host could connect to those i/f, presumably
because its own eth1 was set to an address on the same netblock
( but no other host could connect to either the host's
eth1 or any of the running guests' eth1.  This is what prompted the
question which has turned into this thread.

When I set this network up many ages ago I added to the
internal i/f of the gateway router in the apparently unfounded belief
that if the router knew that the internal i/d had an address in the
192.168 address space then it would not try to route traffic destined
for those addresses through the router.  As I say, my knowledge of
this is very limited. Although, to be fair, everything has worked as I
expected up to now and this situation is simply an experiment of my
own devising.  So, I am hardly a walking accident waiting to happen.

What I wanted to have happen was for all traffic destined for
192.168.anything to stay inside the LAN and attached to the specified
address, while any traffic that originated from 192.168.anything
destined to anywhere else would route through the gateway; where it is
NAT mangled.

I just want to understand what is going on in this specific case
without delving deeply into the subject of routing, for which I do not
have the luxury of time.  This not impacting anything of significance
so I take it up on a time available basis.  On the other hand, I am
definitely gaining an education in the process.

***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3