[lug] strange ssh performance issues

[Kevin Kempter]

How do I set the timing for ssh keepalives? Is it in the sshd_config file?




> 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
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug