Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VPN tunnel won't see SCO 1

Status
Not open for further replies.

piperent

Programmer
Feb 7, 2002
156
US
Ok, I've read all the previous threads, searched in vain for a solution, and still can't get my SCO box to respond to a ping thru a VPN tunnel. Here's the particulars:

Router is a Netgear FVS318

Local VPN Router: 192.168.0.1 (on a static ip)

Remote Client: 192.168.1.95

Once the tunnel is established, the client can see all devices EXCEPT for the SCO box. When I veiw the VPN status log on the router to see what devices are available, I see all the Windows PC's, but not the Unix machine.
What is it about SCO's TCP/IP and/or ICMP responses that prevents any off-network machine from seeing it? All the local PC's on the same network subnet (192.168.0.x) can see it. But a remote machine on a different subnet can not.

I've added the IP's to the hosts file for both the router and the remote PC and I've performed a route add to point SCO to the router

route add -net 192.168.1.95 192.168.0.1

and the routing table reflects the entry.

Does SCO do something funky in the kernel parameters that could prevent this type of recognition?

I'm totally tapped out with no where else to search, have been looking for more than two days. Can I also say that this is not unique to a particular client. I have experienced this on several occasions with different clients. Some have gone to the extreme of adding a Linux box attached to the SCO box, then they can telnet to the Linux machine (because it can be recognized) and then step across to SCO. Not a good solution, but it does work.

Any new light would be greatly appreciated.
I'll be glad to provide more details, just tell me what you need.

Thanks
Joel

piperent
 
What about this instead ?
route add default 192.168.0.1

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886
 
Sorry, I mis-stated the route add command I used.

It was: route add -net 192.168.1.0 192.168.0.1

Joel
 
Thanks for the quick response PHV, I'll try that as soon as I get back to my office. I'll post back the results. Just out of curiosity, what is the effective difference between 'default' and 'net', and why would one possibly work while the other wouldn't?

Joel
 
A great big thank you goes to PHV for his suggestion. I haven't a clue why declaring a 'default' route works and configuring a 'net' route doesn't, but the 'default' did the trick. The VPN client can now see, ping, and telnet direct to the Unix machine.

All I did was remove the original route table entry to delete the network:
route delete 192.169.1.0 192.168.0.1

Then I added your suggestion:
route add default 192.168.0.1

My routing table ends up as

Destination Gateway Flags Refs Use Interface
------------ ------- ----- ---- --- ---------
default 192.168.0.1 UGS 1 10 net0
127.0.0.1 127.0.0.1 UH 3 1027 lo0
192.168 192.168.0.200 UC 1 0 net0
192.168.0.200 127.0.0.1 UGHS 3 50 lo0
224 192.168.0.200 UCS 0 0 net0


Thanks for the help.

JP
 
It looks like your subnet mask is wrong. That would explain why you couldn't route to the 192.168.1.XXX. Actually, I'm surprised setting the default resolved that issue.

What is the result of this command:

# ifconfig -a



"Proof that there is intelligent life in Oregon. Well, Life anyway.
 
OK, I'll buy it. What is it in that routing table that says what the netmask is set to? All I see are a couple of flags and some numbers. They all look the same to me.

net0: flags=4043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.200 netmask ffffff00 broadcast 192.168.0.255
perf. params: recv size: 24576; send size: 24576; full-size frames: 1
ether 00:01:02:47:39:a6
lo0: flags=4049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 127.0.0.1 netmask ff000000
perf. params: recv size: 57344; send size: 57344; full-size frames: 1
atl0: flags=404a<BROADCAST,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 0.0.0.0 netmask ff000000
perf. params: recv size: 4096; send size: 8192; full-size frames: 1

And here is the routing table:

Routing tables
Destination Gateway Flags Refs Use Interface
default 192.168.0.1 UGS 0 10 net0
127.0.0.1 127.0.0.1 UH 3 1063 lo0
192.168 192.168.0.200 UC 1 0 net0
192.168.0.200 127.0.0.1 UGHS 3 50 lo0
224 192.168.0.200 UCS 0 0 net0

JP
 
I expected it to be closer to this:


Code:
Routing tables
Destination      Gateway            Flags    Refs      Use  Interface
default          192.168.0.1        UGS         0       10  net0
127.0.0.1        127.0.0.1          UH          3     1063  lo0
192.168.0        192.168.0.200      UC          1        0  net0
192.168.0.200    127.0.0.1          UGHS        3       50  lo0
224              192.168.0.200      UCS         0        0  net0
The output from your "ifconfig" command looks good, though, so it's still a mystery to me. The bottom line is that you got it working, PHV got a star (well deserved, as always), and all is well.

"Proof that there is intelligent life in Oregon. Well, Life anyway.
 
You know, I have 5.0.5 running on about a dozen clients machines, with all the same patches, release upgrades, and so-forth applied. In most cases, command output will be the same, but in a few strange instances, I get something totally off the wall. Maybe it has something to do with hardware, maybe with network layout and configuration, and maybe, just maybe, it has something to do with the phases of the moon or the alignment of the stars. Who knows.

At any rate, thanks to both of you for your input.
It is very much appreciated.

JP
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top