From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 19:50:42 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E718C1065670 for ; Fri, 27 Mar 2009 19:50:42 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7098FC08 for ; Fri, 27 Mar 2009 19:50:40 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n2RJZ2GN023894 for ; Sat, 28 Mar 2009 06:35:02 +1100 Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n2RJYsFh005133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Mar 2009 06:34:55 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n2RJYrex016630; Sat, 28 Mar 2009 06:34:53 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n2RJYpHu016629; Sat, 28 Mar 2009 06:34:51 +1100 (EST) (envelope-from peter) Date: Sat, 28 Mar 2009 06:34:51 +1100 From: Peter Jeremy To: Pierre Lamy Message-ID: <20090327193451.GA16310@server.vk2pj.dyndns.org> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> <78cb3d3f0902261619t71a054fet43779c37e2981603@mail.gmail.com> <200902262341.35069.shawn@tandac.com> <49CAB28A.9030406@userid.org> <1865.206.108.16.89.1238019698.squirrel@alder.hosix.com> <78cb3d3f0903260552g372fd4b6k886bba1ebc05a77c@mail.gmail.com> <49CBA72F.3020600@userid.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <49CBA72F.3020600@userid.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-net@freebsd.org, Adrian Penisoara , Shawn Everett Subject: Re: FreeBSD Router Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 19:50:43 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Mar-26 11:02:55 -0500, Pierre Lamy wrote: >A 1 day default timeout for established connections is retarded, since=20 >virtually all client apps and OSs as well as intervening stateful=20 >firewalls will lose state after 1 hour. With respect, this is nonsense. An app or OS should never "lose state" for an established TCP connection - if it does, it is broken. Note that the default TCP keepalive interval (in many OSs, not just FreeBSD) is 2 hours. Firewalls are a different case - far more variable and far more often tweaked to suit the owner. IPFW2 defaults to 4096 dynamic rules and defaults to a 5 minute timeout (it also supports its own keepalive generation). IPfilter defaults to a 120 hour timeout. Our corporate firewall at $work times out after about a minute. Again - none of these match your '1 hour' statement. > A session which is idle for more=20 >than an hour can't be considered to be active. This depends on what you consider active. I manage one firewall-like device at work where access to services through the device is controlled be the presence of a specific TCP connection (ie, the user sets up a TCP connection to an app on the box and that app then allows that user to have access to other services mediated by that box whilst that connection remains established). In this case, once the initial authentication phase is complete, the control connection never carries any further application-level data but its continued presence is required (and monitored via TCP-level keepalives). --=20 Peter Jeremy --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAknNKlsACgkQ/opHv/APuIdpgwCguMQDQe1cmeLvyuy5ZKpoHQar /WwAni1Z+XrtiJiyd0DqNcMCKvFXuQDB =I+GN -----END PGP SIGNATURE----- --ibTvN161/egqYuK8--