From owner-freebsd-stable Mon Jan 14 21:21:12 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id E744237B41C for ; Mon, 14 Jan 2002 21:21:09 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA08775; Mon, 14 Jan 2002 22:21:08 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0F5L8100538; Mon, 14 Jan 2002 22:21:08 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15427.48196.58840.602666@caddis.yogotech.com> Date: Mon, 14 Jan 2002 22:21:08 -0700 To: Ian Cc: Subject: Re: tcp keepalive and dynamic ipfw rules In-Reply-To: References: X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >>> My solution to keep my ssh sessions from hanging because I made a cup > >>> of coffe was to up the syctl MIB 'net.inet.ip.fw.dyn_ack_lifetime' to > >>> a more reasonable value. > >> > >> So, non-active TCP sessions can now get packets through since the > >> lifetime of the rules now exceed the lifetime of many of your TCP > >> sessions, so I can now watch your firewall and punch packets through it > >> by analyzing the data. > >> > >> (In short, anyone good enough to punch through packets using the other > >> firewall setup is also capable of punching through packets with extended > >> lifetime TCP dynamic rules.) > > > > Is ipfw really that dumb? > > [snip] > > No, it's not that dumb. The implication of Nate's reply was wrong. When a > tcp connection closes a dynamic rule involving that connection is changed > from the dyn_ack_lifetime period (which can safely be long) to the > dyn_fin_lifetime period which by default is fairly short. Really? I thought IPFW's state handling was *really* that dumb, at least in comparison to IPF's. Does ipfw really keep track of setup and teardown of the link? > If you use dynamic rules and human-interactive connections that involve the > dynamic rules (such as ssh, ftp, etc) then it makes sense for your dyn_ack > lifetime to be longer than the tcp keepalive period (if you want to leave > terminal sessions open indefinitely), or at least longer than you're likely > to be away recycling coffee. Except that if it misses the teardown of the link (the remote side causes it due to lack of traffic and the network is down), you've still got an rule in place w/out anyone listening on it. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message