From owner-freebsd-ipfw@FreeBSD.ORG Fri Jun 5 06:04:53 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F30181065688 for ; Fri, 5 Jun 2009 06:04:53 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 43FA78FC2C for ; Fri, 5 Jun 2009 06:04:52 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n555s4kd016796; Fri, 5 Jun 2009 15:54:04 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 5 Jun 2009 15:54:04 +1000 (EST) From: Ian Smith To: Freddie Cash In-Reply-To: Message-ID: <20090605152016.N38006@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org Subject: Re: Rules processing in ipfw: processing ends with rule 65535 or first match? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 06:04:54 -0000 On Thu, 4 Jun 2009, Freddie Cash wrote: > Over the years, various how-tos and docs that I've read comparing ipfw > to ipf and pf have categorised them as such: > > - ipf/pf compares the packet against every rule in the ruleset, and > the last matching action is used once the end of the ruleset is > reached (last-match-wins) > > - ipfw compares the packet against the rules, and stops processing > the rulesset once a rule matches (first-match-wins) That's true for terminal actions (allow, deny) but not for non-terminal actions (esp. skipto), but also pipe, queue, divert, nat .. which may continue rule processing, modulo net.inet.ip.fw.one_pass, until a match with a terminal action occurs. worst case, rule 65535 always matches. > And, if one wants to get the ipfw behaviour in ipf/pf, they can use > the "quick" keyword, which stops processing of the ruleset as soon as > one of those rules matches. > > IOW, for a ruleset with 1000 rules, ipf/pf will scan every single rule > for every single packet; and ipfw will only scan the ruleset up to the > first matching rule. In theory, the ipfw method would be a lot > faster, and less intensive. I can't comment on ipf or pf or their relative efficiencies. > However, reading through the man page for ipfw(8) on FreeBSD 7.2, it > lists the following (Description section): > The packet passed to the firewall is compared against each > of the rules in the firewall ruleset. When a match is found, the action > corresponding to the matching rule is performed. Yes, but noting the following para: Depending on the action and certain system settings, packets can be rein- jected into the firewall at some rule after the matching one for further processing. > And, later, in the Packet Flow section: > Also note that each packet is always checked against the complete rule- > set, irrespective of the place where the check occurs, or the source of > the packet. That's referring to where ipfw is invoked from on each pass, eg from ip_input or ip_output at layer 3, or ether_demux or ether_output_frame if filtering at layer 2 for routing, or bdg_forward if bridging. In each such ipfw pass invoked on a packet, that indicates rule scanning starts at the beginning of the ruleset and ends on a (terminal) match. > These make it sound like ifpw processes the entire ruleset for every > packet, regardless of when a match occurs. > > So, which is it? Is ipfw a first-match-wins and rule processing ends > setup? Or does it check every single rule for every single packet? First _terminal_ match terminates the search. Just saw Julian's post arrive .. dynamic rules matching state indeed short-circuit the search at the first encountered check-state or keep-state rule, though even in that case the action may be a skipto rather than a terminal action. cheers, Ian