[CentOS] Routing issue between 2 LANs

Sun Dec 19 20:07:46 UTC 2010
Les Mikesell <lesmikesell at gmail.com>

On 12/19/10 1:45 PM, Jose Maria Terry Jimenez wrote:
>
> El 19/12/2010, a las 20:34, Les Mikesell escribió:
>
>> On 12/19/10 12:31 PM, Jose Maria Terry Jimenez wrote:
>>>>>
>>>>> First make sure that you can ping/access those 'other' services from the centos
>>>>> box with 2 nics.   It should source from the .236 interface and 'just work'.  If
>>>>> not, you have firewalls or something else blocking traffic.   When you route
>>>>> other traffic from the .1 network, the destination machines need some reason to
>>>>> send the return packets to the 192.168.236.74 address.  You can either add the
>>>>> route to every machine or on the router that is currently their default router.
>>>>>
>>>>> --
>>>>>   Les Mikesell
>>>>>      lesmikesell at gmail.com
>>>>
>>>> Thank you Les,
>>>>
>>>> Yes, i can ping/access those 'other' services from the CentOS box with 2 NICs.
>>>>
>>>> I understand that i need, for example in a networked printer in 236. network a 'return' route. I definitely have no access to configure network on every machine in the 236 network (only a few), nor the router...
>>>>
>>>> This can't be solved any other way?
>>>>
>>>> Best
>>>
>>> Hello Again,
>>>
>>> I forgot:
>>> I made a mistake in my original post, the ping is to a diferent CentOS box in the 236. network (192.168.236.80) and it replies and i can access it from the Fedora machine in the 1. net.
>>>
>>> Why the other CentOS box (in the 236. net) works (reply, can be accessed) without adding any route?
>>>
>>> The Fedora box (1. network):
>>> [jose at IDi ~]$ ping 192.168.236.80
>>> PING 192.168.236.80 (192.168.236.80) 56(84) bytes of data.
>>> 64 bytes from 192.168.236.80: icmp_req=1 ttl=64 time=1.61 ms
>>> 64 bytes from 192.168.236.80: icmp_req=2 ttl=64 time=0.684 ms
>>> [jose at IDi ~]$ ifconfig eth0 | grep -i 'inet addr'
>>>            inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
>>
>> This doesn't make much sense without a route.  Can you try a traceroute to the
>> fedora box address from the 192.168.236.80 box to see how/why it gets there?
>
> Sure, here it is:
>
>> From fresh reboot of the Fedora14 box:
>
> [jose at IDi ~]$ su -
> Contraseña:
> [root at IDi ~]# route add -net 192.168.236.0 netmask 255.255.255.0 gw 192.168.1.100 dev eth0
> [root at IDi ~]# logout
>
> [jose at IDi ~]$ traceroute 192.168.236.80
> traceroute to 192.168.236.80 (192.168.236.80), 30 hops max, 60 byte packets
>   1  puente (192.168.1.100)  0.286 ms  0.260 ms  0.239 ms
>   2  192.168.236.80 (192.168.236.80)  0.963 ms !X  0.949 ms !X  0.930 ms !X

We know why it works this direction.

> [jose at IDi ~]$ ping 192.168.236.80
> PING 192.168.236.80 (192.168.236.80) 56(84) bytes of data.
> 64 bytes from 192.168.236.80: icmp_req=1 ttl=64 time=0.668 ms
> 64 bytes from 192.168.236.80: icmp_req=2 ttl=64 time=0.599 ms
> 64 bytes from 192.168.236.80: icmp_req=3 ttl=64 time=0.566 ms
> ^C
> --- 192.168.236.80 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2000ms
> rtt min/avg/max/mdev = 0.566/0.611/0.668/0.042 ms
>
> [jose at IDi ~]$ ssh 192.168.236.80
> jose at 192.168.236.80's password:
> Last login: Sun Dec 19 20:44:44 2010 from 192.168.1.3
> [jose at control ~]$

I wanted the reverse path.  Traceroute from the 192.168.236.80 box back to the 
fedora address.  It doesn't make sense that it can return packets without a 
route going through the Centos box.

-- 
   Les Mikesell
     lesmikesell at gmail.com