On Thu, Aug 1, 2013 at 8:23 AM, Henning Brauer <[email protected]> wrote: > * Maxim Khitrov <[email protected]> [2013-08-01 13:50]: >> On Thu, Aug 1, 2013 at 4:44 AM, Stuart Henderson <[email protected]> wrote: >> > On 2013/07/31 09:04, Maxim Khitrov wrote: >> >> On Wed, Jul 31, 2013 at 3:53 AM, Stuart Henderson <[email protected]> >> >> wrote: >> >> > On 2013/07/30 14:41, Maxim Khitrov wrote: >> >> >> I expected a "match quick ..." rule in pf.conf to terminate ruleset >> >> >> evaluation without changing the pass/block state. >> >> > >> >> > "match quick" seems like a config error to me, what use would it have? >> >> > maybe it should just be rejected? >> >> >> >> I think it's nice way of preventing errors. It gives you a way of >> >> applying the default block rule, unless something else was matched, >> > >> > The default rule in PF is not block, it's "pass flags any no state" which >> > is >> > likely to trip people up if they accidentally use it with tcp and window >> > scaling (this default rule is probably responsible for the majority of >> > PF configuration mistakes that I've seen..) I'm just a bit leery of >> > changing >> > syntax in a way which allows this to be hit more easily. >> >> You're right - I meant the default "block" rule that should be at the >> top of every pf.conf. This mechanism is more general than just >> applying the default. Whichever pass/block rule was matched last, >> that's what gets applied. It's no different than falling off the end >> of the ruleset, so I don't think it exacerbates any existing problems. > > I couldn't agree more.
So what's the verdict on this?
