[lug] strange ssh performance issues

[David L. Anselmi]

Kevin Kempter wrote:
> The client I'm working for uses a SonicWall firewall to control access to the 
> data centers. Unfortunately there are issues with the Linux openVPN clients 
> (specifically open swan) where it connects but locks all other connections 
> out of the firewall.

Is that a bug in SonicWall?  Are you using their supported Linux client? 
  What are they doing about it?

> So, until we figure this out the solution is to use the 
> windows version of the SonicWall client.  I've installed vmware and installed 
> a copy of VirusXP (AKA Windows XP). I installed cygwin and followed the 
> instructions here to install the ssh server:

This seems complex enough to be pretty fragile.  You might be better off 
pursuing the Linux client problem.  Also, doesn't their Windows client 
have a feature to route traffic for other machines on its network?  That 
might be easier than your sshd hack.

> Host dataCenterHostname
>         Hostname 10.1.x.x               # data center I.P.
>         HostKeyAlias 10.1.x.x          # data center I.P.
>         ProxyCommand /usr/local/bin/netcat-proxy-command 172.16.128.128 %h

So as suggested you may not have DNS support for resolving data center 
PTRs on the client.

You might also have a problem with some piece of the pipe buffering and 
waiting for timeouts to flush.

> The main issue is that several times a day the connections start to take 
> several minutes to return the password prompt. I need to restart the cygwin 
> service in VirusXP, and sometimes that doesn't help so I reboot the VM 
> instance of VirusXP. This is quite frustrating, however I'm a DBA and have 
> limited networking knowledge. Does anyone have any thoughts?, suggestions?, 
> comments?

Perhaps this indicates that you aren't managing keep alives where you 
need them.  So you might check the SSH keep alive settings.  I've had a 
problem where NAT table entries would timeout more quickly than keep 
alives were sent so my sessions would hang.

The way to troubleshoot this is to get a packet dump off the VM and the 
host and see where the timing is different.  You'll most likely be able 
to see the host doing something that has to time out that the VM doesn't 
do (or that succeeds so doesn't need to timeout).

Dave