Pinging A SCO Box Across A VPN Tunnel

[joemama613]

I have two SCO boxes on a network, one is 192.168.0.200 (main), and one is 192.168.0.100 (backup). I am running a VPN tunnel between two buildings. The other default gateway is 192.168.1.1.

The VPN tunnel has been up for a while with no problems. From the other building we have been able to get into SCO using a telnet program such as Net Term.

Just recently the other building can no longer access the unix box using Net Term. Forgetting about Net Term for the moment, I can not even ping either SCO box from the other side. I can ping anything and everything else from anywhere across the network, except that I can NOT ping 192.168.0.200 OR 192.168.0.100 from the other side (192.168.1.1).

I checked the default gateways on both SCO boxes using netstat -r, and it is correct as 192.168.0.1.

One more point which may or may not matter. Both SCO boxes have the same license registration code, and in fact, I get a periodic warning to that effect that two machines with the same license number are residing on the network (which I ignore). Except for the warning, I have never had any other problems related to that, and on the "SAME" side of the VPN tunnel, everything has worked, and is working fine.

I am at the end of my rope. Can Anyone help?

Thanks, JOE

 

[stanhubble]

what is the netmask that you are using on each of the sco machines?
what other routes are defined besides the default?

 

[blabelle]

Have you tried using the "route add" command.
example: route add 192.168.10.0 192.168.0.3 255.255.255.0
the first IP is the subnet you are trying to reach and the second is the default gateway (which may be your VPN consentrator)
hope this helps
blabelle

 

[PHV]

On the SCO boxes do a

 netstat -m

.
If you have counter other than 0 in the fail column then you have streams memory problem.


Hope This Help
PH.

 

[apeasecpc]

I telnet to SCO, and have several users who access my server over a vpn.

Are you able to telnet to the SCO boxes from within their own subnet?

It sounds to me like your routing is broken, and it is probably not related to any of the SCO settings. Some possible causes are:

1) Your netmask has changed causing the SCO box(es) to no longer be within the network.

2) DHCP has stolen the network address of the SCO box(es) for some other device.

3) Another device has been hard configured with the same IP address as the SCO box(es).

I suggest that you do NOT change any routing on the SCO servers themselves until you verify the rest of your network. If they were working before and you did not do anything to change them they are probably still set correctly.

A traceroute from the side that you normally telnet from should help you pinpoint where the route is breaking.