[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Migration to PF - some questions
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: Migration to PF - some questions
- From: jared r r spiegel <jrrs_(_at_)_ice-nine_(_dot_)_org>
- Date: Sun, 2 Oct 2005 22:03:00 -0600
- Mail-followup-to: jared r r spiegel <jrrs_(_at_)_ice-nine_(_dot_)_org>, misc_(_at_)_openbsd_(_dot_)_org
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
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.
> #! /bin/sh
> 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
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.
[ openbsd 3.8 GENERIC ( sep 10 ) // i386 ]
Visit your host, monkey.org