From owner-freebsd-bugs@FreeBSD.ORG Mon Feb 27 09:53:05 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 043F116A420; Mon, 27 Feb 2006 09:53:05 +0000 (GMT) (envelope-from darrenr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C382543D58; Mon, 27 Feb 2006 09:53:04 +0000 (GMT) (envelope-from darrenr@FreeBSD.org) Received: from freefall.freebsd.org (darrenr@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1R9r4r3042060; Mon, 27 Feb 2006 09:53:04 GMT (envelope-from darrenr@freefall.freebsd.org) Received: (from darrenr@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1R9r4rv042059; Mon, 27 Feb 2006 09:53:04 GMT (envelope-from darrenr) Date: Mon, 27 Feb 2006 09:53:04 GMT From: Darren Reed Message-Id: <200602270953.k1R9r4rv042059@freefall.freebsd.org> To: devteam@donut.ugcs.caltech.edu Cc: freebsd-bugs@FreeBSD.org, spartak@aif.ru, keramida@freebsd.org Subject: Re: kern/79416 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 09:53:05 -0000 IPFilter now converts a "pass" rule into a block if, during processing the packet, it decides that it has the final matching rule but something else happens that means some sort of assumption about the packet being passed is bad. That "something else" might be a NAT proxy decided it wants the packet to be dropped or adding state fails with a rule that isn't "quick". I believe what was happening here is that in earlier versions of ipfilter 4.1 than 4.1.10, it would see that state couldn't be added (at the end of rule processing) and drop the packet - even with "quick" rules. Now, if "keep state" fails for a packet on a "quick" rule, the failure to add state becomes a reason to treat the packet as not matching the rule and we go to the next filter rule. In FreeBSD prior to IPFilter 4.x, if state failed to be added then the packet would still be allowed through. What is the difference here? If the original packet is allowed through, say it is a TCP SYN packet and no state is created then a SYN-ACK will be received and consequently blocked because there is no state. This can be a bit puzzling and also fails to enforce session limits, like it should, without impacting the system "inside." My real concern with this bug report is that the block ICMP packet should have been matched by state and wasn't. Is that still reproducible with FreeBSD-current ? Darren