From owner-freebsd-net@FreeBSD.ORG Mon Mar 20 17:40:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8114216A41F for ; Mon, 20 Mar 2006 17:40:22 +0000 (UTC) (envelope-from jos@catnook.com) Received: from 209-204-181-78.dsl.static.sonic.net (209-204-181-78.dsl.static.sonic.net [209.204.181.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 079F343D45 for ; Mon, 20 Mar 2006 17:40:19 +0000 (GMT) (envelope-from jos@catnook.com) Received: (qmail 43531 invoked by uid 1000); 20 Mar 2006 17:40:41 -0000 Date: Mon, 20 Mar 2006 09:40:19 -0800 From: Jos Backus To: freebsd-net@freebsd.org Message-ID: <20060320174041.GA43364@lizzy.catnook.local> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Mailman-Approved-At: Mon, 20 Mar 2006 17:50:33 +0000 Subject: RELENG_6: IPFilter appears to leak active IP states, leading to blocked traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jos@catnook.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2006 17:40:22 -0000 I am seeing the following problem after upgrading a RELENG_4 system to (a very recent) RELENG_6: Within about two days of uptime the system wil no longer allow incoming or outgoing traffic, necessitating a reboot. A possible symptom is that the `active' counter in `ipfstat -s' slowly creeps up to 4013, then stops, at which time the system is unable to accept or initiate connections. Needless to say, this problem didn't occur on RELENG_4. All the while `ipfstat -t' doesn't show an unusual amount of state entries. It's almost like some state info is leaking, causing IPFilter to believe it has run out of state table entries. Increasing this maximum value is not a fix if a leak is present as it would only delay the onset of the problem. The only change to the ruleset after the upgrade has been to do what the IPFilter FAQ IV.2 suggests, i.e. add `flags S' to TCP `keep state' rules. This doesn't help, and neither does clearing the state table entries using `ipf -FS'. The reboots are obviously unwanted. Anyone else seeing this behavior? Is this a bug in IPFilter 4.1.8 (416)? -- Jos Backus jos at catnook.com