From owner-freebsd-pf@FreeBSD.ORG Fri Jan 8 13:33:36 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A80D106568F for ; Fri, 8 Jan 2010 13:33:36 +0000 (UTC) (envelope-from Olivier.Thibault@lmpt.univ-tours.fr) Received: from mailhost.lmpt.univ-tours.fr (mailhost.lmpt.univ-tours.fr [193.52.212.1]) by mx1.freebsd.org (Postfix) with ESMTP id ECA808FC2F for ; Fri, 8 Jan 2010 13:33:35 +0000 (UTC) Received: from mailhost.lmpt.univ-tours.fr (localhost [127.0.0.1]) by mailhost.lmpt.univ-tours.fr (Postfix) with ESMTP id F0914DB0FB; Fri, 8 Jan 2010 14:33:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= lmpt.univ-tours.fr; h=content-transfer-encoding:content-type :content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=main; t=1262957613; bh=1FLDZsN/wN3mR4oxkvkGKvFFr8+F /JRq+js/dO5rpqA=; b=To+QYfnsJDvyX1pcAh2bvii5OwFguhTLZxP15yB1Y183 u0mPY1eo1lglzBEHLzh4LN4sjRwdJy+h8Gand62DInEs7U48s4GnonBcV2vW3lW3 ZSg2sV+wdMZLKD6nGtZkN4AQblZQ18Z/A78wRsBxxd08vMNuaOzv9E/xKd11spg= X-Virus-Scanned: amavisd-new at lmpt.univ-tours.fr Received: from mailhost.lmpt.univ-tours.fr ([127.0.0.1]) by mailhost.lmpt.univ-tours.fr (mailhost.lmpt.univ-tours.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yuJfn42oP00n; Fri, 8 Jan 2010 14:33:33 +0100 (CET) Received: from [10.68.5.128] (trinity.lmpt.priv [10.68.5.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailhost.lmpt.univ-tours.fr (Postfix) with ESMTPSA id EDD07DB0ED; Fri, 8 Jan 2010 14:33:32 +0100 (CET) Message-ID: <4B473429.6010508@lmpt.univ-tours.fr> Date: Fri, 08 Jan 2010 14:33:29 +0100 From: Olivier Thibault User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Peter Maxwell References: <40fc01eb1001071427g335634c9u1ffa8aacba1360f3@mail.gmail.com> <4B46EAA2.5050904@lmpt.univ-tours.fr> <7731938b1001080231p75e6ee17g59c8fbacda90d983@mail.gmail.com> <4B470B28.8070408@lmpt.univ-tours.fr> <7731938b1001080314k1de75328l15afb2f636b8cae2@mail.gmail.com> In-Reply-To: <7731938b1001080314k1de75328l15afb2f636b8cae2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: freebsd 8 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 13:33:36 -0000 Hi, Thanks a lot for your answer and explanations. This will be very helpfull to me and I will update my pf.conf. Thanks again. Olivier Le 08.01.2010 12:14, Peter Maxwell a =E9crit : > 2010/1/8 Olivier Thibault : >> Le 08.01.2010 11:31, Peter Maxwell a =E9crit : >>> 2010/1/8 Olivier Thibault : >>> >>>>> # keep stats of outging connections >>>>> pass out keep state >>>> This rule allows everything out and next outgoing rules won't be che= cked >>>> as >>>> this one first match. >>> That's incorrect, pf does the opposite and uses the *last* match - at >>> least that's what the documentation says... >>> http://www.openbsd.org/faq/pf/filter.html >>> >>> The quick keyword is used for shortcut evaluation. >> Yes ! Actually, all the following rules in my pf.conf use this keyword= . >> That's why I said that. >> I suppose the rules evaluation is quicker this way but I may be wrong. >> Am I ? >=20 > Erm, mostly wrong... it wouldn't improve performance if even a > majority of your rules use it, in that case all you've done is change > last match processing to first match processing. >=20 > If when pf is actually processing packets (this is not the same as > loading your rule set), lets assume that the packets are evaluated > against each rule in a sequential manner. With that assumption, > having most of your rules *without* the quick keyword then only use > quick for those rules near the top of your ruleset that process a > large amount of new connections (again, not synonymous with traffic - > it's new connections that matter), in that case you may see a > performance improvement. For example, say you have a complex ruleset > but lots of incoming connections on port 80 - then using the quick > keyword and placing the rule near the top of your ruleset may improve > things. >=20 > However, that assumes pf goes through the rules in a sequential manner > when actually processing packets - that may not be true. My advice > would be to put a single 'block all' rule at the top, then have the > remainder of your rules doing 'pass': it is much much easier to read > and debug. What is more valuable to you, saving hours on debuging a > firewall box or a 2% performance improvement? It is also unlikely > you'd be getting enough traffic to warrant the use of 'quick' ;-) >=20 > Most other packet filters/firewalls I've used use match first. > Logically using match last is no different (you essentially just write > your rule set upside-down), but it is actually my preference. --=20 Olivier THIBAULT Universit=E9 Fran=E7ois Rabelais - UFR Sciences et Techniques Laboratoire de Math=E9matiques et Physique Th=E9orique (UMR CNRS 6083) Service Informatique de l'UFR Parc de Grandmont 37200 Tours - France Email: olivier.thibault at lmpt.univ-tours.fr Tel: (33)(0)2 47 36 69 12 Fax: (33)(0)2 47 36 70 68 Mobile : (33)(0)6 62 60 80 44