[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Migration to PF - some questions

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.  

  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
> [...]

  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