Hung ssh client connection

[Damien Mascord]

Darren Tucker wrote:
> Damien Mascord wrote:
> 
>> We have a netscreen 5gt-plus, running ScreenOS 5.0.2, which has an ssh
>> daemon running.
> 
> [...]
> 
>> If I restart the firewall using the command 'reset', I get a message
>> that the firewall is resetting, which is good.
> 
> [...]
> 
>> What could be the cause of this connection 'hanging' ? Is it on the SSH
>> client, the SSH server not closing the connection correctly upon reset ?
>>  Or could it be something in the TCP OS layer ?
> 
> 
> When you "reset" your firewall, it flushes its state table, right?  If
> so then would probably include the SSH TCP connection too.

*nods* ok, makes sense, so because the firewall isn't responding at all
to the SSH connection (that it no longer knows about), the client is
just waiting until it either times out or gets a connect reset ?

> One place this might show up is in "netstat" on the client: if there's a
> constant value in the "Send-Q" column for the ssh connection to your
> firewall then that's almost certainly what's happening.

The Send-Q starts at 0, and starts increasing as I 'send' characters
through the ssh client, until it grows until 5632:


tcp        0   5632 <ip of client>:38428      <ip of firewall>:22
   ESTABLISHED 30202/ssh

(Where does the value 5632 come from?)

tcpdump shows an ack sent every 2 minutes:

11:05:45.612452 IP <ip of client>.38428 > <ip of firewall>.ssh: P
2749294956:2749295044(88) ack 270286710 win 7680
11:07:45.594004 IP <ip of client>.38428 > <ip of firewall>.ssh: P
0:88(88) ack 1 win 7680
11:09:45.575585 IP <ip of client>.38428 > <ip of firewall>.ssh: P
0:88(88) ack 1 win 7680

>> If it is expected behaviour, I apologize, though would like to
>> understand why this is happening on a technical level.
> 
> If connections *to* the firewall (as opposed to *through* it) are
> subject the the firewall rules and unless it has the capability to
> re-learn established connections then it's the behaviour I would expect.

So, because the firewall silently ignores the ACKs sent to it, the
client has nothing to do except wait for some indication?

Would the following sysctl value have an effect on the timeout ?

net.ipv4.tcp_retries2 = 15 # Defines how many times a TCP packet is
retransmitted in established state before giving up.

Cheers,

Damien