From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 1 11:06:54 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 314CB10656D7 for ; Mon, 1 Jun 2009 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 161EC8FC22 for ; Mon, 1 Jun 2009 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n51B6rtg021119 for ; Mon, 1 Jun 2009 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n51B6rdP021115 for freebsd-ipfw@FreeBSD.org; Mon, 1 Jun 2009 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Jun 2009 11:06:53 GMT Message-Id: <200906011106.n51B6rdP021115@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org 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: Mon, 01 Jun 2009 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 57 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Jun 2 08:04:21 2009 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4762C106564A; Tue, 2 Jun 2009 08:04:21 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1CEC28FC19; Tue, 2 Jun 2009 08:04:21 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5284K4L023913; Tue, 2 Jun 2009 08:04:21 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5284KW5023909; Tue, 2 Jun 2009 08:04:20 GMT (envelope-from linimon) Date: Tue, 2 Jun 2009 08:04:20 GMT Message-Id: <200906020804.n5284KW5023909@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/134975: [patch] ipfw(8) can't work with set in rule file. 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: Tue, 02 Jun 2009 08:04:21 -0000 Synopsis: [patch] ipfw(8) can't work with set in rule file. Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jun 2 08:04:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134975 From owner-freebsd-ipfw@FreeBSD.ORG Thu Jun 4 00:58:47 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 603821065670 for ; Thu, 4 Jun 2009 00:58:47 +0000 (UTC) (envelope-from root@h1603454.stratoserver.net) Received: from h1603454.stratoserver.net (paysecuritygate.com [85.214.149.143]) by mx1.freebsd.org (Postfix) with ESMTP id 28D928FC0C for ; Thu, 4 Jun 2009 00:58:47 +0000 (UTC) (envelope-from root@h1603454.stratoserver.net) Received: by h1603454.stratoserver.net (Postfix, from userid 0) id 775152EB186D; Thu, 4 Jun 2009 02:34:26 +0200 (CEST) To: freebsd-ipfw@freebsd.org From: www.moneybookers.com Message-Id: <20090604003426.775152EB186D@h1603454.stratoserver.net> Date: Thu, 4 Jun 2009 02:34:26 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Update Account. 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: Thu, 04 Jun 2009 00:58:47 -0000 ********************************************************************** ******************** THIS IS AN AUTOMATED EMAIL - . ********************************************************************** ******************** Dear Moneybookers Customer,: Due to concerns, for the safety and integrity of the Moneybookers.com account we have issued this warning message. It has come to our attention that your Moneybookers.com account information needs to be updated as part of our continuing commitment to protect your account and to reduce the instance of fraud on our website. If you could please take 5-10 minutes out of your online experience and update your personal records you will not run into any future problems with the online service. Once you have updated your account records your Moneybookers.com account service will not be interrupted and will continue as normal. To update your Moneybookers.com records click on the following link: [1]http://Moneybookers.com/ Moneybookers Security Reminders Case Sensitive Login Please remember your password is case-sensitive, at least 6 characters long and contains at least one number or non-alphabetic character such as '-'. ******************************* Moneybookers Ltd., London, Registered in England and Wales no 4260907. Registered office: Welken House, 10-11 Charterhouse Square, London, EC1M 6EH, United Kingdom. Authorised and regulated by the Financial Services Authority of the United Kingdom (FSA). References 1. http://www.protocolinfogate.com/moneybookers/directory.php?app=login.pl From owner-freebsd-ipfw@FreeBSD.ORG Thu Jun 4 01:19:14 2009 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78936106566B for ; Thu, 4 Jun 2009 01:19:14 +0000 (UTC) (envelope-from root@h1603454.stratoserver.net) Received: from h1603454.stratoserver.net (paysecuritygate.com [85.214.149.143]) by mx1.freebsd.org (Postfix) with ESMTP id 41CEB8FC15 for ; Thu, 4 Jun 2009 01:19:14 +0000 (UTC) (envelope-from root@h1603454.stratoserver.net) Received: by h1603454.stratoserver.net (Postfix, from userid 0) id B3BD03357BF2; Thu, 4 Jun 2009 02:53:31 +0200 (CEST) To: ipfw@freebsd.org From: www.moneybookers.com Message-Id: <20090604005331.B3BD03357BF2@h1603454.stratoserver.net> Date: Thu, 4 Jun 2009 02:53:31 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Update Account. 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: Thu, 04 Jun 2009 01:19:14 -0000 ********************************************************************** ******************** THIS IS AN AUTOMATED EMAIL - . ********************************************************************** ******************** Dear Moneybookers Customer,: Due to concerns, for the safety and integrity of the Moneybookers.com account we have issued this warning message. It has come to our attention that your Moneybookers.com account information needs to be updated as part of our continuing commitment to protect your account and to reduce the instance of fraud on our website. If you could please take 5-10 minutes out of your online experience and update your personal records you will not run into any future problems with the online service. Once you have updated your account records your Moneybookers.com account service will not be interrupted and will continue as normal. To update your Moneybookers.com records click on the following link: [1]http://Moneybookers.com/ Moneybookers Security Reminders Case Sensitive Login Please remember your password is case-sensitive, at least 6 characters long and contains at least one number or non-alphabetic character such as '-'. ******************************* Moneybookers Ltd., London, Registered in England and Wales no 4260907. Registered office: Welken House, 10-11 Charterhouse Square, London, EC1M 6EH, United Kingdom. Authorised and regulated by the Financial Services Authority of the United Kingdom (FSA). References 1. http://www.protocolinfogate.com/moneybookers/directory.php?app=login.pl From owner-freebsd-ipfw@FreeBSD.ORG Thu Jun 4 22:23:49 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 3122F106566B for ; Thu, 4 Jun 2009 22:23:49 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by mx1.freebsd.org (Postfix) with ESMTP id E18808FC19 for ; Thu, 4 Jun 2009 22:23:48 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by gxk3 with SMTP id 3so562549gxk.19 for ; Thu, 04 Jun 2009 15:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=o/ulJbdxEaZvwjP2IQYPvxSbr0pqbfxU3U3JNY16ub4=; b=YJ1fu/3kCOfHZO2joijcV7bJ7g1lRNe7Bga6xiEPTdnY9b+u7cWUZysMjRTx954PnA qbgmQ9fCe19T7eRasl/p5Hj1xFmzHhgi0EBYy3j2y8LOBhMpBzbt88KedAPV1IFy4Oif I9Xiw2UOKtrX+AdFV1D9Rg3v6Sdi3SYjJU4ls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=woqcALjFyK7QA6EAOTN6UWgvA/lsMS7Y25EwHXb3MPbDe0kvOLIXLgONuNVKBgtC6u b4J3XcOFIylajrCihiwYqlY3fGXmZrb6NKNFxhpO0CBkeD5wwurpzQgA98Xfk7IQzEEj vPQAQho3FoUsdAnHO54heCXG/qp0H9S1OmRNo= MIME-Version: 1.0 Received: by 10.151.139.3 with SMTP id r3mr4577941ybn.137.1244154228315; Thu, 04 Jun 2009 15:23:48 -0700 (PDT) Date: Thu, 4 Jun 2009 15:23:48 -0700 Message-ID: From: Freddie Cash To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: 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: Thu, 04 Jun 2009 22:23:49 -0000 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) 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. 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. 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. 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? -- Freddie Cash fjwcash@gmail.com From owner-freebsd-ipfw@FreeBSD.ORG Fri Jun 5 05:33:27 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 49E77106566C for ; Fri, 5 Jun 2009 05:33:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 2DEA28FC1C for ; Fri, 5 Jun 2009 05:33:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id E477D322D9; Thu, 4 Jun 2009 22:33:26 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id A0CC52D600D; Thu, 4 Jun 2009 22:33:26 -0700 (PDT) Message-ID: <4A28AE26.6010805@elischer.org> Date: Thu, 04 Jun 2009 22:33:26 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Freddie Cash References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 05:33:27 -0000 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) > > 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. > > 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. the packet is compared against each rule it encounters however it might not encounter a rule by 3 means: 1/ it matches a rule before the rule in question and stops processing 2/ it bypasses the rule in question due to matching a rule with a skipto action. 3/ it matches a check-state rule and effectively shortcuts to the exact rule that is needed for that session, skipping all intermediate rles. > > 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. > > 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? > 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 From owner-freebsd-ipfw@FreeBSD.ORG Fri Jun 5 17:35:19 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 70E79106564A for ; Fri, 5 Jun 2009 17:35:19 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6038FC15 for ; Fri, 5 Jun 2009 17:35:19 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by gxk3 with SMTP id 3so1653352gxk.19 for ; Fri, 05 Jun 2009 10:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=AYAlUIzrdF/LwYCiQcQnZdW6t2ODtJ56vucYPOTLkfQ=; b=S8LVMQfQUxEfuj7pg7IfO6lOudDoB0eu5WSXqE09vDIfNkCS0OHJAUHqfmxLA/N8tT aZ/yW+AfGnXL0SKCeqdBGzn143rDnrU2/BjZy02a7mptfReeAT1izRM3kYtxlkyvcPuc Zc+H8rWq5iYf223ujhHX0UJOSuHfCK+CNXWRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=dfPyOmErgt+WXLOr8MwYydw+ei9f1FuPiFTYM7oYOcCn0EWcZZr8BmeW6M/0b8Nnes 7CgCdydBybeuwOwDH61dUqz+W9fxS+HSG5Kajyb/iXDtIhNUeHCmTFxGyfvtWAl92XYQ vMacBI9KBFXIL/GLxW570S/pMLYoP+lFbpfdg= MIME-Version: 1.0 Received: by 10.151.119.9 with SMTP id w9mr6488723ybm.82.1244223318611; Fri, 05 Jun 2009 10:35:18 -0700 (PDT) In-Reply-To: <20090605152016.N38006@sola.nimnet.asn.au> References: <20090605152016.N38006@sola.nimnet.asn.au> Date: Fri, 5 Jun 2009 10:35:18 -0700 Message-ID: From: Freddie Cash To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 17:35:19 -0000 Okay, so my understanding was (mostly) correct. Thanks for the extra info. -- Freddie Cash fjwcash@gmail.com