Dhirendra,
: Dsl feed goes to gateway 1. Its internal ip address is of 192.168.1.XXX.
: Now from here goes the feed to another gateway which eth0 ip address is
: 192,168.1.50. It has 2 more eth - eth1 and eth2. Their ip address are
: 192.168.2.51 and 192.168.3.XXX respectively.
: Now my problem is that all the computers connect to 192.168.2.XXX are
: unable to point to the computers of 192.168.1.XXX. Though strangely I
: can ping to 192.168.1.1 wich is the internal ip address of the gateway 1.
Is this your network, or did I mangle it in reconstruction?
eth0
192.168.1.50
\
|----------| |----------|
| gateway 1|-------------------------| gateway2 |
/|__________|\ | |----------|
/ \ | / \
eth0 eth1 | / \
61.X.X.X 192.168.1.1 | eth1 eth2
(public) | 192.168.2.51 192.168.3.52
| |
------------ |
| BOX 1 | -------------
------------ | Box 3 |
192.168.1.101 -------------
192.168.3.101
You can ping 192.168.1.1 because it is a locally hosted IP on the default
gateway of the machines in the 192.168.2.0/24 network.
: I have the following setup on redhat linux 8.0 ...
:
: A) I am unable to ping from Box 3 (192.168.3.101) to Box 1. Any
: comments or reasons why?
It looks like you have a common routing problem. If you examine the
routing tables on gateway 1 and box 1, they are probably missing routes
to 192.168.3.0/24 and 192.168.2.0/24 via 192.168.1.50. Host 1 probably
has a default route to 192.168.1.1 and gateway 1 certainly doesn't have a
default route pointing *into* your network.
<gripe>
This is not really a LAR (and certainly not a TC) question. This is a
basic routing question. Let's try to keep these questions off the LARTC
list....this is probably better for a forum like comp.os.linux.networking
or a LUG.
</gripe>
<helpful-hat>
You may find some of my documentation useful in conceptualizing static
routing:
http://linux-ip.net/
http://linux-ip.net/html/ch-routing.html
For others who are following along with questions like this, I would
recommend using a network analyzer of some kind to look at the packets on
each of the machines involved.
- use tcpdump or ethereal on each affected router and end-host
- generate regular traffic (ping, nc, socat, etc.) while trying to
determine where the packets are getting dropped or misrouted
</helpful-hat>
So, Dhirendra:
Remove the masquerading from gateway2
[root@xxxx]# ip route add 192.168.3.0/24 via 192.168.1.50
[root@xxxx]# ip route add 192.168.2.0/24 via 192.168.1.50
[user@xxxx]$ ping -n 192.168.1.101
You should get a response.
[root@xxxx]# ip route add 192.168.3.0/24 via 192.168.1.50
[root@xxxx]# ip route add 192.168.2.0/24 via 192.168.1.50
: B) I have figured out that if I enable Masquerading then problem A is
: solved. Can someone explain why?
Because you are changing the source IP on the packets to a 192.168.1.0/24.
When you do this, the other hosts in 192.168.1.0/24 have a direct route
for reply packets.
: C) Is it possible without Masquerading ?
Yes.
-Martin
Anybody think a LARTC FAQ is a good idea?
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
