Viewing firewall rules, with inspection column enabled, and rules ordered in the default (evaluation) order: My understanding is the per rule evaluation counts should generally reduce as you go down the table. Other than non-quick rules which may be displayed higher than their actual evaluation occurs.
What reasons might you see rules in the list with higher evaluation counts than rules preceding them?
Does state lifetime affect these counts? When are those counters reset?
Also, if a packet is not on the specified interface, presumably it is not evaluated against the rule. (But that is the only exception)?
Thanks for any insights.
Nice question @keeka.
Just touching on this part:
Quote from: keeka on Today at 04:35:07 PMOther than non-quick rules which may be displayed higher than their actual evaluation occurs.
I think pf default behavior is non-quick and the "quick" option is just a modifier that stops further evaluation on a match. That's how I interpret it:
https://man.freebsd.org/cgi/man.cgi?pf.conf(5)
QuoteEach time a packet processed by the packet filter comes in on or goes
out through an interface, the filter rules are evaluated in sequential
order, from first to last. The last matching rule decides what action
is taken.
...
quick
If a packet matches a rule which has the quick option set, this
rule is considered the last matching rule, and evaluation of sub-
sequent rules is skipped.
But in any case the rules are evaluated top-down in the order they appear, quick or not.
@OPNenthu, I need to keep reminding myself how non-quick (which as you say is the pf default) work. However the last match concept has proven diffcult to grasp, so I just look at it as evaluated last! That seems to serve me in so far things have worked as I wished.
My upgrade last week to 26.7 was super smooth despite a moderately customized setup. The final test, ACME certs renewal. completed successfully this weekend. Great job @Franco and OPNsense team.
Sorry this is not answering your original question but it's my favorite aspect of the firewall that you touched on. This mechanic makes pf more interesting, IMO.
Quote from: keeka on Today at 05:22:55 PMHowever the last match concept has proven diffcult to grasp, so I just look at it as evaluated last!
As a purely
logical construct, I think you can imagine your rules that way- as a set of 'quick' rules followed by a set of 'non-quick' rules evaluated after all the quick ones. However, in that case you have to
also think of the two sets differently:
The 'quick' set will be first-match and processing stops immediately on a match.
The 'non-quick' set will continue to be last-match and they are all processed no matter what. The last one that matched wins.
Again, sorry for the digression. I hope my last post helps in the discussion about evaluation counts.
P.S. If you imagine the rules this way, there may be cases where it breaks down... i.e. with tagging or something. Interesting thought exercise.