Problems connecting SCO with Cisco VPN

[lorel]

I have been researching a problem with SCO and Cisco VPN, so far I found a tread (58-760504) the is similar but not the same as my problem
I have a SCO UNIX 5.0.7 running in one office, everyone within that office is able to work with no problems. The same SCO box is connected to another office via a Cisco VPN. This is the problem, I connect to the server from the external office using an emulator (Eric's telnet98) I am able to login as root, I enter the command cd /etc, then I enter the command ls, at this time the screen will hang and will not respond to anything.
If my client attempts to run the application in the server, they are able to login but not much more before they also get stuck.
Cisco claims is not their problem, that the problem resides in the SCO box.
The only thing we change in a server to allow it to work with a VPN is to add the default gateway number.
We have several other clients using VPN with no problems, but, none of them use Cisco, most of them use Netgear equipment.

Any ideas?

Again thanks

Joe

 

[M577A2]

We had a problem when the Cisco PIX devices became more widespread. They don't like packets that come in "out of order" and caused the remote PC's connection to freeze. Our solution was to change the TCP/IP Send and Receive packet window to 32K, change the keepidle to 5 minutes instead of two hours, and the tcp_initial_timeout to 10 seconds. The values are kept in /etc/default/inet. You can log in as root and execute the following:

inconfig in_recvspace 32768
inconfig in_sendspace 32768
inconfig tcp_keepidle 600
inconfig tcp_initial_timeout 10

This changes the kernal on the fly and changes the values in /etc/default/inet so they'll be in effect after a reboot.

Finally, on one customer system we had to add /usr/bin/idleout 0 to the end of /etc/rc2.d/P88USRDEFINE

Hope this helps, because it's not on the SCO box if it doesn't.

 

[lorel]

M577A2:
Thanks for you input, but it did not work, I followed the instructions you provided, but when I when to test it it again hanged the screen.

Anything else you could suggest?

Thanks

joe

PD I did not reboot the system after adding the /usr/bin/idleout line, I did reboot after using the inconfig command

 

[stanhubble]

you probably have a dead (or not quite dead) nfs connection mounted in the directory that you are trying to "ls" in.

you will probably see a similar reaction with "df -Pk"
and this will show the mounted file systems up until the offending one. so you will have to remember which one normally show up next.

these "hung" sessions are usually impossible to kill and the only recourse is to have the mount correct itself or reboot the system.

my guess is that this is unrelated to the vpn unless the offending mount was at the other end of the tunnel.

 

[lorel]

We also get hang when we go into scoadmin, it may allow me to go to the first window ( sometime does not even get that far) but it will hang as soon as I try to get to another window.

When our user starts their application the system may go as far as ask for the application login, and may show the main menu. but shortly after that it will hang.If the user do not exit, after a long while (about 5 minutes) the user is kick out of the emulator.

I say may, because the user may not get that far. The users located were the system is at (the local network) do not have any problems of this nature. For this reason, I believed the problem is related to the VPN.

We have over 30 client using VPNs with our system, None of them have any problems over the VPN, but, then again, they are not using Cisco VPN, they are either using Netgears or Sonicwalls.

Thanks

Joe

 

[stanhubble]

Sorry i misread part of your original post.. thought it said that the client had the same problem when trying it from the server. "if my client attempts to run the application in the server, they are able to login but not much more before they also get stuck."

ok then the problem is only when clients connect to the server from the remote location. and only when they try to transfer a "large" amount of screen data, or rather it works as long as the transfer of screen data is small.

you might need to adjust the MTU size such that the packets are not split (or fragmented) in a strange way. try dropping it from 1500 to something like 1460. it may need to be even lower than that depending on the overhead the vpn is wrapping on the packets.

 

[lorel]

stanhubble:

Thanks you for taking the time to answer.

When you say to change the MTU, do you mean to change it at the VPN or in the UNIX system?

If I need to change it in the UNIX system, can you tell me the command to use? I have no experience changing this parameter in the UNIX system.

Thanks

Joe

 

[stanhubble]

the MTU is a setting of the network interface, and in this case you would modify it on the the unix system.

ifconfig -a will tell you what it is currently set to for each interface.

you can modify it in /etc/tcp and add a -mtu #### parameter to the ifconfig line for the interface that goes thru the vpn tunnel.

 

[lorel]

The command ifconfig -a tells me that my nic is net0

Using this info I tried this command:
ifconfig net0 -mtu 1460

I get the following error message:
ifconfig: -mtu: bad value

I also tried with 1440 and got the same answer

can you help?

Thanks

Joe

 

[PHV]

Try this:
ifconfig net0 mtu 1460

Tip: man ifconfig

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886