From owner-freebsd-bugs@FreeBSD.ORG Fri Jan 13 23:50:11 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 9C53F16A423 for ; Fri, 13 Jan 2006 23:50:11 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE43343D58 for ; Fri, 13 Jan 2006 23:50:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0DNo6nJ044100 for ; Fri, 13 Jan 2006 23:50:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0DNo6dC044099; Fri, 13 Jan 2006 23:50:06 GMT (envelope-from gnats) Resent-Date: Fri, 13 Jan 2006 23:50:06 GMT Resent-Message-Id: <200601132350.k0DNo6dC044099@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Tijmen Ramakers Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B248016A420 for ; Fri, 13 Jan 2006 23:43:14 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AC4243D46 for ; Fri, 13 Jan 2006 23:43:13 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k0DNhCdc071441 for ; Fri, 13 Jan 2006 23:43:12 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k0DNhCZS071437; Fri, 13 Jan 2006 23:43:12 GMT (envelope-from nobody) Message-Id: <200601132343.k0DNhCZS071437@www.freebsd.org> Date: Fri, 13 Jan 2006 23:43:12 GMT From: Tijmen Ramakers To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: kern/91777: ipfilter: wrong behaviour with skip rule inside a group with a 'quick' head 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: Fri, 13 Jan 2006 23:50:11 -0000 >Number: 91777 >Category: kern >Synopsis: ipfilter: wrong behaviour with skip rule inside a group with a 'quick' head >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jan 13 23:50:06 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Tijmen Ramakers >Release: 6.0-RELEASE >Organization: >Environment: FreeBSD kitana.tijmen.net 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Fri Nov 11 00:37:21 UTC 2005 root@kitana.tijmen.net:/usr/src/sys/i386/compile/KITANA i386 >Description: Inside a group of a rule set whose head rule uses the 'quick' option, a matching skip rule seems to end the processing of the group. ipf was compiled into the kernel (not as a module) using the IPFILTER and IPFILTER_LOG options. ipf -V output: ipf: IP Filter: v4.1.8 (416) Kernel: IP Filter: v4.1.8 Running: yes Log Flags: 0x20000000 = block Default: block all, Logging: available Active list: 1 Consider the following simple ruleset: @0:1 block out quick on de0 head 100 @100:1 skip 1 out group 100 @100:2 block out quick group 100 @100:3 pass out quick group 100 Expected behaviour for an outbound packet on de0 would be: 1. rule @0:1 matches, branch into group 100 2. rule @100:1 matches, skip over @100:2 to @100:3 3. rule @100:3 matches, with the quick option So, the packet should be passed. However, it is not. In the ipfmon logging you see that the packet gets blocked on rule @100:1, using ipfstat -honR you see that only rules @0:1 and @100:1 have matched. However, if you leave out the 'quick' in @0:1, the rule does gets processed as expected. According to the ipf manpage and the "IP Filter FAQ", the 'quick' in the head rule is only relevant in case none of the group's rules match. I noticed this when after upgrading from 5.2.1 to 6.0, my firewall config didn't work anymore. Haven't seen any mention of this change in behaviour anywhere. >How-To-Repeat: See problem description. >Fix: >Release-Note: >Audit-Trail: >Unformatted: