On Sun, Jan 30, 2011 at 01:28:12PM +0100, Henning Brauer wrote:
> >
> > is this correct:
> >
> > - match rules will not work if "no state" is also used on the rule (not
> > sure that would make sense anyway)
>
> well, they do "work".
>
> > - all packets are passed by default, but effectively with "no state"
>
> correct.
>
> > - "no state" is incompatible with counters
>
> no, that's wrong. there is a bug with counters on match rules in the
> no state case, that's gonna be fixed somewhen.
>
> > - any packets passed without matching any rules (i.e. are not
> > specifically blocked) are not accounted for (statistically)
>
> well, they still update the global counters.
>
> > that seems like a whole heap of gotchas that we don;t talk about. i
> > think we should try and document this stuff.
>
> hmm. it really comes down to the no state for packets not matching any
> pass rules.
>
ok, so that's not so bad. in a way we're already there: pf.conf(5) notes
in PACKET FILTERING first:
For block and pass, the last matching rule decides what
action is taken; if no rule matches the packet, the default
action is to pass the packet.
and then:
By default pf(4) filters packets statefully: the first time
a packet matches a pass rule, a state entry is created;
but we do not explicitly say that if no rule matches, a packet is passed
effectively with "no state" applied. is that sufficiently important that
we should say it?
jmc
