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 192.168.209.43 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 0.0.0.0 255.255.255.252 U 0 0 0 eth0 aaa.bbb.ccc.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1 0.0.0.0 aaa.bbb.ddd.53 0.0.0.0 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 169.254.0.0 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 192.168.0.1 and the netmask 255.255.255.0. 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 (192.168.209.43) 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 192.168.0.1 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.