kern/91777: ipfilter: wrong behaviour with skip rule inside a group with a 'quick' head

[Tijmen Ramakers]

>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 at 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: