Floating vs Interface rules processing order
-
@Derelict said in Floating vs Interface rules processing order:
There is no sense to put quick on a match rule.
Yes, and the pfsense book confirms it as well: "Match rules do not work with Quick enabled."
With a rule without quick set, they take effect at the END of the rule set (though they are set in the order they are in the rule set.) If any other rule matches that has quick set processing stops so the end of the rule set is never reached so the rule without quick set never takes any action on the packet.
Based on your comment above, for example: I have a rule in the
LAN Interface Rules (always Quick) allow dst 10.0.0.1
and I also want to direct the same packets to a particular queue therefore I create a similar rule in the
Floating rules (NON Quick) match in dst 10.0.0.1Does it mean that the NON Quick Floating rule will be never evaluated because the LAN Interface rule allows the packets and the processing stops there?
Thank you!
-
No. Quick means nothing on a match rule. A later rule could change the queue assigned there but if nothing else does that, that will be the queue that is set.
-
Will macth rules (which are non quick) evaulated before the Interface rules and not at the end of the ruleset (as other non quick rules)?
-
They set the queue. If nothing later in the rules change that, that is what happens.
-
As i understand
Interface rules are automatically Quick flagged
"Quick" in floating rules means "evaluate before group and interfacce rules - early rules".
"Non Quick floating" means evaluate After group and interface rules - late rules".I think the evaluation order you said:
1.Floating Rules (Quick)
2.Interface Group Rules (always Quick)
3.Interface Rules (always Quick)
4.Floating Rules (NON Quick)Is the correct one
If you want to check, disabile LAN rule and let quick unchecked on floating rule.
Traffic should pass.Match option:
Match + Quick does not work ( I think the flag quick is useless with match and does not make any difference in this kind of action)
Match action rules don't stop packet evaluation, packet tagging or packet queueing, they are all evalued consecutively before any other pass/block rule .So about the original question:
- ping is allowed without quick floating because lan rules comes first.
- ping is blocked with quick floating because quick floating comes first.
Regards.
-
@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.
-
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.
-
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.
-
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 rulesFor 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.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 pingPing will be allowed
(If there is a match on a quick rule there is not further evaluation.) -
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. -
something like this ?
-
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.
-
@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:NOwill never take effect because the also non quick rule
block in log inet all tracker 1000000103 label "Default deny rule IPv4is higher in the rule set (“last match wins”).
Correct? -
Man...
block in log inet all tracker 1000000103 label "Default deny rule IPv4That sets the default deny on all traffic.
Then, further down the rule set:
allow in dst 10.0.0.1 Quick:NOThat changes that behavior.
As long as nothing further down the rule set matches and changes that allow, it will be passed.
-
Ok
block in log inet all tracker 1000000103 label "Default deny rule IPv4
is at the very top of the ruleset.Clear
-
cat /tmp/rules.debug
