On Sat, Oct 01, 2005 at 04:43:40AM -0500, Travis H. wrote: > > Ah, but the matching engine doesn't have to traverse the whole rule > list that way. Unless pf is doing something really tricky, every > packet will have to traverse every firewall rule without use of > quicks. On a complicated, busy firewall setup, this might have a > noticable performance impact.
might might might; but does it? i mean, i'm all about getting a good MPG in my car, but my side-view mirrors *REALLY* aren't hurting the MPG i do get. i might get a better MPG by chopping them off (forget legal crap for a second), and i can just turn and look if i want to make a lane change, sure... but i'm not going to chop them off just because some day i might be really low on gas and might run out but might've been able to make it to the gas station due to having been able to go farther on a tank because i achieved a better MPG because i chopped of my side-view mirrors... > I agree, with the added use of quick on each of the pass rules. > > In fact, you can probably use quick on virtually every rule other than > that default without any loss of expressiveness. if you get in to tagging, you might run into situations where quick would quickly f' your entire situation up. if you want to privately add quick to all your rules, that's what it's there for, naturally; but pf has (in my side-line estimation) been running to the satisfaction of those who contribute code to it for quite some time, so maybe the first-match camp who pops up now and again only really have a chance at changing things when they become valuable to the code-base ? > It's probably not necessary, and I may offend purists by my > performance optimizations probably only offend purists by saying 'performance optimizations' without actually experiencing any suboptimal performance begging to be optimized to begin with. > pass quick on lo0 'set skip on lo0' up top, unless you need to 'rdr on lo0' or other actions which set skip would kill. this gives you one fewer vile "rule" for the PC to spend all of its time evaluating, quick or not. > I also find it useful to use the following rule right after "default deny": > > block return on $lan_if or just set block-policy to return. one less rule. unless you feel better with zonealarm stealth mode :/ > I also don't see why NAT should necessarily occur before the filtering > rules. It makes more sense to my intuition <snip> i think this is called barking up the wrong tree. new dude on list + 'my opinion > yours' usually != warm welcome > Also, I find supporting $macros in pf.conf a little crufty. diff(1), sendbug(1) > #! /bin/sh > lan_if=xl1 > wan_if=ex0 > pfctl -f /dev/stdin <<EOM > pass quick on lo0 > block all > pass quick in on $lan_if all keep state > pass in quick on $wan_if from any to $wan_if proto tcp port = 22 keep state > [...] > EOM omg pf != iptablesnetfilterchains doing something like that is not hard with the rest of the tools you've got in the system, which makes it somewhat of a useless complexity for pf to have it. new packet-filtering features are not bloat, but why make pf call out to the shell when you can just choose to make a script or two to make your shell call out to pf? > But you can easily do > conditional inclusion of rules, and that's useful for cases like DHCP. dhclient listens on BPF. pf has no effect on dhclient. jared -- [ openbsd 3.8 GENERIC ( sep 10 ) // i386 ]
