Floating vs Interface rules processing order

johnpoz

@chriva said in Floating vs Interface rules processing order:

I think the evaluation order you said:

No that is not the evaluation order.. Not sure how much clearer Derelict can be.

Rules are processed in order whether or not quick is set.

turrican64

From Derelict good explanation I can say the following

Processing order:
1.Floating Rules (Quick + NON Quick)
2.Interface Group Rules (always Quick)
3.Interface Rules (always Quick)

However Quick flag reverses the behavior of “first match wins” to be “last match wins”.
Therefore if there is another rule after the Quick rule which matches that will take effect not the Quick one.

And as you say MATCH applied immediately and evaluation continues for the rest of the ruleset.

turrican64

And statement from the pfsense book that:

"Without Quick checked, the rule will only take effect if no other rules match the traffic"

is not applicable to MATCH rules.

chriva

After re-reading Derelict comment it is much clearer.
Let me know if i'm right or not.

All rules are read and parsed in order of the ruleset.
The rule order is floating > group > interface
All match rules should apply before pass/block rules

For match rules (last match case, all rules should be read)
quick flag is unrelevant
if there is a match set the modifier (queue/tag) to the one dictated by this rule
Read Next rule
Loop until there are no more rules.
Apply the modifier.

For pass/block rules (first match case, maybe not all the rules needs to be read)
If there is a match and rule is quick, stop reading and apply action.
If there is a match but rule is not quick save the action (only first time).
Read next rule.
Loop until there are no more rules.
If there is a saved action apply the action.

@turrican64

However Quick flag reverses the behavior of “first match wins” to be “last match wins”.
Therefore if there is another rule after the Quick rule which matches that will takes effect not the Quick one.

Sorry, but I don't think this is correct
Try
quick floating allow ping
quick floating deny ping

Ping will be allowed
(If there is a match on a quick rule there is not further evaluation.)

turrican64

@chriva

So sorry I meant the other way around

However Without Quick flag reverses the behavior of “first match wins” to be “last match wins”.
Therefore if there is another rule after the NON Quick rule which matches that will take effect not the NON Quick one.

kiokoman

something like this ?

Derelict

All rules without quick set do is modify the default treatment of the packet should nothing else further down in the rule set change it.

It's really that simple.

turrican64

@Derelict said in Floating vs Interface rules processing order:

block in log inet all tracker 1000000103 label "Default deny rule IPv4"
block out log inet all tracker 1000000104 label "Default deny rule IPv4"
These are very high in the rule set and do not have quick set. They set every packet to be blocked in or out of any interface. When all the other rules have been processed and the end of the rule set is reached and no other rule has changed the behavior and passed or blocked it, then that action is taken and the packet is dropped.

Based on the above if I create only 1 rule for example

allow in dst 10.0.0.1 Quick:NO

will never take effect because the also non quick rule

block in log inet all tracker 1000000103 label "Default deny rule IPv4

is higher in the rule set (“last match wins”).
Correct?

Derelict

Man...

block in log inet all tracker 1000000103 label "Default deny rule IPv4

That sets the default deny on all traffic.

Then, further down the rule set:

allow in dst 10.0.0.1 Quick:NO

That changes that behavior.

As long as nothing further down the rule set matches and changes that allow, it will be passed.

turrican64

Ok
block in log inet all tracker 1000000103 label "Default deny rule IPv4
is at the very top of the ruleset.

Clear

Derelict

cat /tmp/rules.debug