SecureCRT 5.2.1 Hangs shortly after connecting SSH2

[jet70]

Ok, a little background.
I am using SecureCRT 5.2.1 (and older versions of 5), I am using SSH2 to connect to a Suse Linux Enterprise Server 10 over a VPN. My computer is a WindowsXP SP2 laptop. I only experience this problem with 1 particular site, we have another site that I have no problems with but the server is SLES 9. My colleague has no problems with Putty (which I haven't tried yet).

I can connect and get a prompt but once I do a cat on a file or a ls of a large folder it hangs. I can do a ls on a folder that has only a couple files in it but anything else tends to hang.

Any ideas or tips would be appreciated.

[tnygren]

Hi Jet70,

I just want to clarify my understanding of what is happening.

Are both the SLES 9 and SLES 10 connections going through the same VPN connection?

Is your co-worker also connecting to these same servers through the same VPN when using Putty?

Would it be possible to get 'Trace Option' output from both the SLES 9 and SLES 10 connections?

To enable trace options, click on the "File" pull down menu and select "Trace Options". If you click the "File" pull down menu again you should see a check mark next to "Trace Options".

After trace options is enabled, try to connect to the server.

After the completes, right click inside the window and "Select All", then right click and select "Copy", and then either send the information to me using this form or post it here to this forum thread.

Could you also provide a server log from the SLES 10 server for this connection?

There may be information as to why the connection is hanging.

[jet70]

After gathering all your required info and even doing a sniff of the transaction we discovered the actual problem. Our Cisco engineer called about another issue and I mentioned the problem and he suggested checking the MTU. Using "SG TCP Optimizer" I found all the computers except the working one had the MTU size set to 1500. On the PC, if we set it t 1400 the problem goes away. Our Engineer is going to make the changes in the VPN for the future but for now we are working.

Thanks for your follow up and questions, it forced us to take it to the next level.

[mekanik]

Originally Posted by jet70

After gathering all your required info and even doing a sniff of the transaction we discovered the actual problem. Our Cisco engineer called about another issue and I mentioned the problem and he suggested checking the MTU. Using "SG TCP Optimizer" I found all the computers except the working one had the MTU size set to 1500. On the PC, if we set it t 1400 the problem goes away. Our Engineer is going to make the changes in the VPN for the future but for now we are working.

Thanks for your follow up and questions, it forced us to take it to the next level.

For future reference, IPSec based VPNs (if this is the type of VPN in use) will cause these types of symptoms and problem. This is due to the additional header overhead for the VPN. IPSec adds addtional header overhead (appx ~52 - 58~ bytes) on top of the standard IP (usually 20bytes) and TCP (usually 20bytes) headers. Add those up and they equal a combined total of appx ~92 - ~98 bytes of header overhead. The reason this issue is observed is because the underlying TCP session negotiates the max payload of data that can be transfered via each TCP packet during the TCP handshake using the MSS (maximum segment size) option. The MSS value that is negotiated is based on the MTU value assigned to the interface.

NOTE: The MSS value is dependent on both TCP endpoints and their MTU values and will honor the lowest advertised MSS value during the 3way handshake of a TCP session.

FYI, if you use broadband xDSL at home and it is PPPoE based, then this will consume an additional 8bytes of header overhead for the PPPoE protocol. Thus setting the MTU to 1400 bytes may not work. You may have to set your MTU to 1380, which will usually work in most all cases. In cases where there is a network that is designed to use IPSec over GRE, then you need to add an additional 24bytes of header overhead for GRE. In some cases you can just set your MTU to 1300 and be done with it.

HTH,

/mekanik/

[tnygren]

Hi Jet70,

Thanks for letting me know and I'm glad that changing the Windows MTU setting resolved the issue!

Please let us know if you have any other questions.

Hi Mekanik,

Thanks for posting the additional information on the MTU settings!