Or maybe what I'm missing is some advantage in matching multiple rules. (?) If a packet matches one rule, which tells it to be tagged or logged, will the tagging or logging still be applied to the packet if it ends up matching another rule?
That could be pretty helpful. On 5/5/05, Jonathan Camenisch <[EMAIL PROTECTED]> wrote: > On 5/4/05, Nick Holland <[EMAIL PROTECTED]> wrote: > > Jonathan Camenisch wrote: > > > This is sort of an academic question, I guess. Hopefully, this is an > > > ok place to post it. > > > > > > Just wondering...it seems that most rule examples start out with > > > "block in all/block out all", wouldn't it more efficient to put "block > > > all" at the end of the rules and use "quick" to pass packets? That > > > would be one less rule that gets parsed. > > > > Lopping off one rule doesn't matter in any real way. It will never be > > the difference between a "too slow" system and a "fast enough" system. > > It will never cause more work to be done in your office. It will never > > be felt. It is unlikely to even be measured. (Insert Gentoo joke > > here). This is a place where a human error will cost much more than any > > savings of one rule. PF is plenty fast that for most apps, readability > > should take precidence over "efficiency", especially an efficiency that > > Just Doesn't Matter. > > > > The default of PF is to "pass all". > > If you wish to have a tight firewall, you generally want to have a > > "block all" default. Say it. Get it over with. Now, start passing the > > stuff you want to pass, and only that stuff. I suspect more people will > > find the results more "readable" that way. > > > > Your strategy mandates a "quick" on every pass rule. That may not be > > desired; if you mandate that "every rule must include a 'quick'", you > > cripple some of PF's flexibility. If that was desired, the "quick" > > would be implied, and PF would be a "First matching rule wins", rather > > than "Last matching rule wins" system. You can probably accomplish most > > tasks either way, but PF gives you both. Plus, if you happen to forget > > one of those "quick"s, you might spend a lot of time looking for the > > problem... > > > > Nick. > > > > Thanks, everyone, for your thoughts. > > I think I'm seeing that the "Last matching rule wins" philosophy is > something I haven't totally gotten used to yet. Since the quick option > is there, it sort of gives you two ways to prioritize rules - and I > suppose I haven't learned the advantage of that. > > I will say one word in my own defense - even if it has no practical > point (since I intend to try to do things in a standard "pf way"). It > really seems less readable to me to mix quick and non-quick rules. > When there's a mixture, you have to read and comprehend a non-linear > sequence. But with the way that pf works, I wouldn't want to throw > away quick altogether, just because I don't want pf reading the whole > file for every packet (well, minus skipped rules). > > E.g., if I want to pass everything out my firewall to ports >1024 > except port 8080, I'd have to write two rules. I could write it two > different orders: > > pass ... to port > 1024 ... > block ... quick ... to port 8080 ... (or not quick, I suppose) > > or > > block ... quick ... to port 8080 ... > pass ... quick ... to port > 1024 ... > > To me the second one seems more readable if most of my rules use > quick, and thus the first matching rule usually wins. > > Or maybe I shouldn't be _usually_ using quick? In that case, it seems > like it would be tricky, in terms of readability, to use it at all. > > I'm trying to think of a time when there's an advantage to mixing the > order. Except maybe in the sense that many of you mention - that > setting your default at the top is sort of like getting it out of the > way before you get into writing all the "interesting" rules. > > ... >
