Re: pf configuration subleties

On 9/12/2009 10:25 PM, Karl O. Pinc wrote:
 > set state-policy if-bound|floating
 >
 > Whether it matters or not depends on your application.  It surely
 > can matter, e.g. with muti-homed hosts where replies may come in
 > an interface other than the one out which the request was sent.
 > OTOH if you're gatewaying multiple very different networks you may want
 > things locked down tightly with state bound to the interfaces
 > because there's no way such traffic should be allowed.

That's not going to remove double states, because the traffic is passing 
through the interfaces in opposite directions.  [shrug]

 > I don't know.  My general rule is that unless performance is
 > really an issue it's a lot more important to write programs/
 > configurations in a way that people can read than it is to
 > write them so that they are executed optimally.  If nobody
 > can read the file then it's useless.

That's a good point.  I rewrote my ruleset recently in a way that uses 
more rules, but is way more maintainable and easy to understand. 
(Multiple pass in rules on different interfaces instead of single pass 
out rules that applied to a bunch of things.)



On 9/13/2009 5:38 AM, Stuart Henderson wrote:
 >> ---
 >> block in on $ext_if
 >> pass  in on $ext_if from any to $ext_if port 22
 >> ---
 > You don't have a rule handling $int_if or outbound traffic, so the
 > default _non stateful_ pass rule is used. You're doing a whole ruleset
 > evaluation per outgoing packet.

Ahhhh.  I didn't realize the default rule worked like that.  So that 
certainly removes any efficiency argument even without the other reasons.



On 9/13/2009 10:18 AM, Henning Brauer wrote:
> there's no memory problem really. you will have memory bandwidth / bus
> bandwidth / interface bandwidth maxed out long before memory for the
> states becomes an issue. i am not aware of a _single_ case of state
> table size problem in at least 5 years (in the early days the pools
> used had limitations that actually made that a bit problematic, but
> that is long solved).

Ok.  That's pretty much the info I was looking for in terms of my 
efficiency question.

> you want default deny and double states... really. not bored enough to
> write that down again tho.

I should clarify that these questions aren't necessarily practical, 
since I'm not working with a huge ruleset, so much as coming from a 
desire to understand how the packet filter actually works.

> won't make a difference that matters.
> with just 3 entries they are probably about the same, the more entries
> the more advantage for the table.
> but then the optimizer will make that a table anyway (exceptions apply)

It didn't when I tried it, but like you said, I guess exceptions apply...



Thanks, guys.  I have some more to come, but I'll save it for another email.