On Tue, Sep 29, 2020 at 04:22:32PM +0200, to...@tuxteam.de wrote:
On Tue, Sep 29, 2020 at 08:18:54AM -0400, Michael Stone wrote:
On Wed, Sep 23, 2020 at 03:48:56PM -0400, Greg Wooledge wrote:
>The normal reason people need to use ServerAlive or ClientAlive is NAT.
>If your connection from ssh client to ssh server goes through a NAT
>router, the router may keep track of activity on that connection, and
>drop the translation when it goes idle for 5 minutes or so. Forcing the
>*Alive packets to happen every few minutes prevents a NAT timeout.
This is a stateful firewall thing, not a NAT thing
That depends on what Greg means by "activity". NAT has to keep a
map of (internal IP, internal local port) to external local port
to do the translation (the so-called "translation table"). Since
it'd grow without bounds whenever one side drops the connection,
it's customary to let NAT table entries to expire after some
inactivity (typical: 1h, but network admins are known to be a
capricious species ;-)
So Greg is probably right. NAT is, in its own way, stateful.
NAT is a special case of a stateful firewall. You can get rid of NAT but
basically the entire modern internet has stateful firewalls so getting
rid of NAT won't make the problem at hand go away. The basic connection
state tables and NAT state tables track basically the same information
using the same algorithms for session start & stop, have the same issues
with potentially leaking entries if hosts disappear, and have the same
strategy of expiring inactive entries.
In general it's kind of dumb on modern hardware to expire sessions that
are still exchanging TCP keepalives unless you're under extreme pressure
from a DoS attack or somesuch. (Modern devices just don't have the
memory constraints that were an issue 20 years ago and don't need to
aggressively prune sessions that are actively advertising that they're
alive.) But people rarely get to choose the other end's firewall
configuration, so enter kludges like the ssh protocol keepalives.
