Date: Fri, 08 Jan 2010 14:33:29 +0100 From: Olivier Thibault <Olivier.Thibault@lmpt.univ-tours.fr> To: Peter Maxwell <peter@allicient.co.uk> Cc: freebsd-pf@freebsd.org Subject: Re: freebsd 8 Message-ID: <4B473429.6010508@lmpt.univ-tours.fr> In-Reply-To: <7731938b1001080314k1de75328l15afb2f636b8cae2@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <Olivier.Thibault@lmpt.univ-tours.fr>: >> Le 08.01.2010 11:31, Peter Maxwell a =E9crit : >>> 2010/1/8 Olivier Thibault <Olivier.Thibault@lmpt.univ-tours.fr>: >>> >>>>> # 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B473429.6010508>