how to stop your firewall from timing out your ssh session

So a customer was complaining ssh sessions to his VPS were timing out. I've hit this problem several times myself, so I thought I'd write a bit about it.

The problem is usually a NAT with an aggressive TCP session timeout (large corporate NATs are notorious for this. The thing is, the NAT must keep track of every TCP session, so it times out sessions after a certain period without a packet.) Of course, if you have control over the NAT, you can usually set the timeout long enough that you don't have a problem. Of course, many low-end NAT boxes don't allow you to adjust this setting, and in many corporate environments, you don't have access to that setting.

Remember kids, lobby for IPv6, or else we will all be behind giant NAT boxes at our ISP that we don't control.

However, if you are, for whatever reason, trapped behind a NAT you do not control, you can use the ssh client keepalive to send packets when your session is idle. Now, the ssh client keepalive was designed to kill the connection when the TCP stream is interrupted (the idea is that if nobody sends any packets, a TCP session can stay 'open' for many days, even if one of the devices is disconnected from the network. the client keepalive sends a packet over the encrypted connection every ClientAliveInterval seconds.

     ClientAliveInterval
             Sets a timeout interval in seconds after which if no data has been
             received from the client, sshd will send a message through the
             encrypted channel to request a response from the client.  The
             default is 0, indicating that these messages will not be sent to the
             client.  This option applies to protocol version 2 only.

Of course, if you are on a connection that drops a lot of packets (like my cellphone) this can present another problem, namely that a few dropped packets kill your ssh connection. There is another setting that can be used to mitigate that to some extent:

     ClientAliveCountMax
             Sets the number of client alive messages (see below) which may be
             sent without sshd receiving any messages back from the client.  If
             this threshold is reached while client alive messages are being
             sent, sshd will disconnect the client, terminating the session.  It
             is important to note that the use of client alive messages is very
             different from TCPKeepAlive (below).  The client alive messages are
             sent through the encrypted channel and therefore will not be spoofa-
             ble.  The TCP keepalive option enabled by TCPKeepAlive is spoofable.
             The client alive mechanism is valuable when the client or server
             depend on knowing when a connection has become inactive.

             The default value is 3.  If ClientAliveInterval (see below) is set
             to 15, and ClientAliveCountMax is left at the default, unresponsive
             ssh clients will be disconnected after approximately 45 seconds.

so personally, at the bottom of my /etc/ssh/sshd_config file, I have the following:

ClientAliveInterval 100
ClientAliveCountMax 1000

it works well enough