Date: Wed, 2 Jul 2003 14:52:32 +0200 From: "Michal F. Hanula" <frankie@kyblik.pieskovisko.sk> To: questions@freebsd.org Subject: Re: ssh keepalives Message-ID: <20030702125232.GC25388@kyblik.pieskovisko.sk> In-Reply-To: <Pine.LNX.4.44.0307020715270.2161-100000@localhost.localdomain> References: <Pine.LNX.4.44.0307020715270.2161-100000@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
--+nBD6E3TurpgldQp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 02, 2003 at 07:17:19AM -0400, Steve Coile wrote: > On Tue, 1 Jul 2003, Philip J. Koenig wrote: > > I'm having a problem with premature termination of ssh sessions after= =20 > > an idle period of a few minutes, getting a "connection reset by peer"= =20 > > message. I presume this is due to intermediate stateful firewalls=20 > > closing the connection when no traffic passes for a period of time. >=20 > Is this a common problem with firewalls? We suffer from this problem > here, also, and I've thought it must be a misconfiguration with the > firewall or elsewhere in the netwrok. But since you mentioend it, > I'm rethinking my assessment. >=20 > Can someone explain why these connections get dropped? The firewall is tracking the state of TCP connections (among others). The information about the state needs some memory, which means that the firewall cannot keep state of an infinite number of connections. After some time the state gets dropped. A reasonable firewall (such as ipfilter) takes the state of the connection (syn sent, ack sent, open, ...) into account when determining the timeout (eg. with ipfilter the timeout for a partially open connection is (by default) 480s, for an open connection it is 86400s (a week). When a connection is closed, the state is dropped immediately). Unreasonable firewalls don'tm which means that the time before the connection is dropped has to be quite short to prevent the state table =66rom overflowing. Finding the reason for this happenning with NAT is left as an exercise for the reader ;-) m&f --=20 What do you care what other people think? --+nBD6E3TurpgldQp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/AtWQ4PY2BaN84VwRAqpdAJ4gedkOIepehVCankrCk5hjjMp8sQCeJQG1 /EJ4zl04fdS0c/QL8hZLYe4= =hpug -----END PGP SIGNATURE----- --+nBD6E3TurpgldQp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030702125232.GC25388>