pf "quick" best practice

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

pf "quick" best practice

Michael Glasgow
I've seen some mention that one should avoid using "quick" in
complex rulesets, but I'm not sure why.  I suspect there is some
rule of thumb that I'm missing?

As it happens, almost all of my rules in complex setups are "quick",
because first-match rules seem so much more intuitive to me.  The
main exception is for tagging type rules such as for NAT, shaping,
etc, and the initial "block all", but pretty much every other ACL
type rule is "quick".  On the other hand, why is pf last-match by
default?  Perhaps my own intuition is contrary to pf design?

Would love to hear thoughts from someone with lots of experience
designing complex rulesets.  For example, five or more interfaces
with multiple DMZs, internal networks, Inet, transparent proxy,
shaping, etc.  When would you avoid using "quick" and why?

--
Michael Glasgow <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: pf "quick" best practice

Kenneth Gober
On Wed, Feb 5, 2020 at 3:01 PM Michael Glasgow <[hidden email]> wrote:
I've seen some mention that one should avoid using "quick" in
complex rulesets, but I'm not sure why.  I suspect there is some
rule of thumb that I'm missing?

I suspect this advice was actually intended to be that you should either
use "quick" all the time, or never.  In other words, use it consistently.

If you use it all the time, your ruleset is easy to understand as long as
you keep in mind that it uses "first match" semantics -- the first matching
rule wins, because all rules are "quick".

Or, if you never use it, your ruleset is still easy to understand as long as
you keep in mind that it uses "last match" semantics -- the last matching
rule wins, because no preceding rules were "quick".

Selectively using "quick", or selectively not using it, can lead to confusion
where you thought first match or last match applied, but it actually did not.

I always use quick and I think it makes my rulesets clearer, because I
personally find "first match" to be easier to reason about.

-ken
Reply | Threaded
Open this post in threaded view
|

Re: pf "quick" best practice

Michael Glasgow
Kenneth Gober wrote:
> On Wed, Feb 5, 2020 at 3:01 PM Michael Glasgow <[hidden email]> wrote:
> > I've seen some mention that one should avoid using "quick" in
> > complex rulesets, but I'm not sure why.  I suspect there is some
> > rule of thumb that I'm missing?
>
> I suspect this advice was actually intended to be that you should either
> use "quick" all the time, or never.  In other words, use it consistently.
..
> I always use quick and I think it makes my rulesets clearer, because I
> personally find "first match" to be easier to reason about.

Thanks!  Sounds like we're pretty much on the same page, which is
reassuring.

I was accustomed to first-match from previous solutions, so I just
carried over that practice to pf without thinking too much about it.
Recently I'd begun to wonder if there was perhaps some actual reason
that pf was designed to be last-match by default, and it made me
wonder if there was some perspective I'd never considered.  It's
always interesting when someone can make a compelling case that
"you're doing it wrong", and show you that the tool you're using
was designed to be used in a different way than you're accustomed.

But perhaps last-match is only a "default" for some reason relating
to syntax, and it wasn't necessarily intended to imply a preference
for how rules are written?

--
Michael Glasgow <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: pf "quick" best practice

Peter N. M. Hansteen-3
On Thu, Feb 06, 2020 at 02:34:51PM -0600, Michael Glasgow wrote:
> I was accustomed to first-match from previous solutions, so I just
> carried over that practice to pf without thinking too much about it.
> Recently I'd begun to wonder if there was perhaps some actual reason
> that pf was designed to be last-match by default, and it made me
> wonder if there was some perspective I'd never considered.  It's

Last match wins was inherited from IPF (which, it was once jokingly suggested
by Henning, "was designed by an Australian, so everything was upside down").

Basically, in the rush to implement a reasonably-licensed replacement it was
decided that it was important to not break existing setups too horribly.

Since then of course we have seen some major shakeupis in syntax such as the
NAT rewrite and the ALTQ to new queues reimplementation. But going to first
match would still be a very fundamental change of how configurations work,
so it's unlikely to happen.

> But perhaps last-match is only a "default" for some reason relating
> to syntax, and it wasn't necessarily intended to imply a preference
> for how rules are written?

It's historical reasons, really. To quick or not is really up to whoever
is tasked with maintaining the configuration. As long as you stay in
control of the logic, either way is fine in my book.

All the best,
Peter

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.