I have a Linux Redhat 6.1 VPN that is on the 192.168.1.0 subnet. We have a number of other machines running WINNT and WIN95 that are also on the .1 subnet. The problem is that users coming in on the VPN can not get to any other subnets(.2,.3,.4). I thought that I would start with the most obvious and see if the Linux VPN could ping anything on the .2. The VPN server can ping the router interface(192.168.1.1) with some ping times in excess of 78000 ms. All of the Windows machines are able to ping the router interface and any subnet fine. For the internal network, here is what the route -n shows me.
192.168.1.0 0.0.0.0 255.255.255.0 U eth1
192.168.2.0 0.0.0.0 255.255.255.0 U eth1
0.0.0.0 203.156.145.32 0.0.0.0 UG eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG eth1
Eth1 is the inside nic and eth0 is the outside nic.
Before everything was on the .1 subnet. Then we brought in the Cisco 4006 so that we could create vlans and give them their own subnet. It seems that the Cisco hardware is the culprit but I don't know because we only had one subnet before. Any help would be appreciated.
Just found out an interesting development but I am not sure what the problem is. If I do a ping -n 192.168.2.33, I get a good ping response. Without the -n though the ping is about 18000ms. I guess that something is trying to resolve the ip to a name but I don't know that for sure.
thanks,
jim

[Edited by Shoki on 05-24-2001 at 02:55 PM]

Hi Shoki,

Looks like the packets are going out to the eth0 interface first, then trying the eth1 and giving you misleading information.

Try "ping -r 192.168.1.1"
If this shows you a normal latency then that's the problem.

The second problem I can see, is you have 2 default routers in your FIB table.

Try removing the one:
0.0.0.0 192.168.1.1 0.0.0.0 UG eth1

Then add the static route back in:
route add -net 192.168.0.0 netmask 255.255.0.0 gw 192.168.1.1

The Windozes boxes find the correct router because they are sending out a ICMP type 10 request, which is part of the router discovery protocol, all the routers on a multicast address of 224.0.0.2 respond to them on a unicast address and they update the windozes routing tables, so the routes to the 192.168.*.* subnets are correct.
The Linux box doesn't do this as you have static addresses setup that override any router advertisement query messages.

/Raz

Thanks for the help razbot but that didn't seem to do the trick. I did a ping -r 192.168.1.1 and the latency was the same as it had been before which was about 18000ms. Then all of the sudden after about 8 replies, it picked up. I also did the route delete and the route add but it didn't seem to change anything. It just seems that it should work.
Re-reading my post it seems misleading about the Windows machines and their ability to ping. I meant that the Windows machines on the internal network are fine, they can access any machine on the entire network. The Windows machines that are connecting through the VPN can only ping the .1 subnet. They can not ping any other subnet(i.e, 2.1, 3.1). We recently added the .2 and the .3 subnet and a Cisco 4006. It seems that the VPN users can connect fine and browse the machines on the .1 subnet but they are not able to get to the .2 subnet machines. Once they are past the VPN should that not just be treated like any other user from the .1? When they login to the VPN they are being assigned a 192.168.1.x address, so I don't understand why the cannot connect to the .2 machines like our internal users can.
I only started learning about Linux on Monday so I know that I am missing a lot of knowledge. It seems all the pieces are there but it doesn't work. Anything info that I can give that would help?
thanks,
jim

ok, right.

try
ping -I eth1 -r 192.168.1.1
Is the ping latency still v-high ?

ok next.
What happens when you do a DOS "tracert" from the Windozes systems on the other end of the VPN to an active IP address on a different subnet, within your internal network.

i.e what's the last hop it stops responding from. ?

This last hop IP address is the point at which the packet can't get the TTL information or the correct route to continue to it's requested destination addresses.

/Raz

Razbot, I did the ping -l eth1 -r 192.168.1.1 and the latency was still very high.
When I did the tracert from a remote windows machine, it shows the first hop as the 192.168.1.180(the VPN server) then nothing after that.
What do you think,
jim

Not sure why the ICMP reply's are so high, you'll have to do some packet sniffing to see what's happening to them.

Looks like the VPN server at the 192.168.1.180 is the cause of the problem. I would start to look at its settings for static routes and other filtering rules that would deny the packets to other subnets.

/Raz

Thanks for your help Raz. I know that when I do the ping -n the pings are great. It seems that when it tries to resolve the name, that it runs into difficulties. I changed to the resolv.conf file from the DNS server to the WINS server and I could ping anything from the VPN server with good times. I changed it back and then the pings went back to the way they were.
Since I have never set up a VPN, are there any good books or something that I can get for a VPN newbie? I have read a lot of howto's but it is just bits and pieces. I need to understand the relationship between all of the pieces that make up the VPN. It is just somewhat frustrating because I don't know how it all ties together to work.
thanks,
jim

You've got a tricky problem.
If your having problems with the resolve time, it could be something to do with the times you have set on UDP packets for DNS resolve.

Difficult to tell without understanding your set-up further.

Anyway to get more info on the VPN world read all these books and you'll be an expert.

http://www.omega23.com/books/comp1/vpn.html

/raz