Floating vs Interface rules processing order
-
Hello,
Rule processing order is as follows:
- Floating Rules
- Interface Group Rules
- Interface Rules
I have an interface rule which allows anything IPv4 from LAN to NOT RFC1918 addresses.
I want to block 10.20.3.1 address on the LAN side therefore I've created a Floating rule (this is the only Floating rule):
Action: Block
Quick: No
Interface: LAN
Direction: In
Address/Protocol: IPv4/Any
Source: 10.20.3.1I was expecting that the Floating rule processed before the Interface rule. However it doesn't work. I can still ping from the host:
root@LEDE:~# ping yahoo.com
PING yahoo.com (98.137.246.7): 56 data bytes
64 bytes from 98.137.246.7: seq=0 ttl=50 time=228.191 msIf I check Quick this Floating rule blocks the traffic.
Since Floating is the first in the processing order I was expecting that it drops the packet before it hits the Interface allow rule.Could you please tell me why it only blocks traffic with Quick enabled?
Thank you!
-
Floating rules are evalued first.
But they are applyed on a last match base, unless quick flag is checked (in this case they follow the first match base).Hope this helps.
-
Hello,
Thank you for your answer, but as I mentioned I have only 1 floating rule, therefor this is the first and last rule at the same time so quick flag should not make any difference.
In my understanding this should block the traffice regardless quick is enabled or not. However it blocks the traffic only when quick is enabled. Why?
-
you didn't click the "quick" in the floating.
So your lan rules allows it, why should it go back to the floating that is not quick and block it. Once a rule is triggered no other rules are evaluated.
Rules on interfaces are always "quick" set.
Also be warned that ! rules can be finicky.. If you have vips set... If you don't want lan going to rfc1918, you should prob use an explicit block to rfc1918, and then below that an allow for any.
Why would you not just put the rules on your lan interface directly?
You also need to be aware of the full process order
Outbound NAT rules Inbound NAT rules such as Port Forwards (including rdr pass and UPnP) NAT rules for the Load Balancing daemon (relayd) Rules dynamically received from RADIUS for IPsec and OpenVPN clients Internal automatic rules (pass and block for various items like lockout, snort, DHCP, etc.) User-defined rules: Rules defined on the floating tab Rules defined on interface group tabs (Including IPsec and OpenVPN) Rules defined on interface tabs (WAN, LAN, OPTx, etc) Automatic VPN rules
-
@johnpoz said in Floating vs Interface rules processing order:
you didn't click the "quick" in the floating.
Rules on interfaces are always "quick" set.I am aware of both.
The guide says "Without Quick checked, the rule will only take effect if no other rules match the traffic." I interpret this as "Without Quick checked, the rule will only take effect if no other rules in Floating Rules match the traffic.", therefore my understanding is that processing order is as follows:
- Floating Rules (Quick)
- Floating Rules (NON Quick)
- Interface Group Rules
- Interface Rules
But based on your comment
So your lan rules allows it, why should it go back to the floating that is not quick and block it. Once a rule is triggered no other rules are evaluated.
I have the impression that the processing order might be:
- Floating Rules (Quick)
- Interface Group Rules
- Interface Rules
- Floating Rules (NON Quick)
Is this the correct order?
Why would you not just put the rules on your lan interface directly?
This is not a real life scenario, just a test
-
No that is not the correct order.. Again why would it go back to floating?
https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html
"Floating Rules are parsed before rules on other interfaces."Not sure what your trying to test here?
-
@johnpoz said in Floating vs Interface rules processing order:
No that is not the correct order.. Again why would it go back to floating?
I don't want it to go back I want Floating to block the packet before it reaches LAN Interface rules.
https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html
"Floating Rules are parsed before rules on other interfaces."Exactly. My block rule is in the Floating Rule therefore should block the packet before it reaches LAN Interface Rule.
"Without Quick checked, the rule will only take effect if no other rules match the traffic"
This the only rule in Floating Rules, therefore no other rules macth the traffic in the Floating Rule, so this block rule should take effect without Quick checked. Correct?Not sure what your trying to test here?
My understanding about Quick flag
Thank you for your help by the way :)
-
@turrican64 said in Floating vs Interface rules processing order:
Floating Rules (Quick)
Floating Rules (NON Quick)
Interface Group Rules
Interface Rulesso the question is.. why the rule does not match/it's ignored if it's not set as quick?
this appear more like
1 Floating Rules (Quick) if set it work
2 Floating Rules (NON Quick) - if unset is ignored / does not match
3 Interface Group Rules
4 Interface Rules -
@kiokoman
Yes. This is my question. -
so if we follow the logic of pf, the manual say:
If a packet matches a rule which has the quick option set, this rule is considered the last matching rule, and evaluation of subsequent rules is skipped.
and if we think that pf does not care about the tab you have on the gui but it's only a single list of rules following a specific orde of quick/non quick rules ..
i will say that until you have rules on lan interface with quick option set (and they are always set as quick) that non quick rule will never apply.
does it make sense? -
@kiokoman said in Floating vs Interface rules processing order:
so if we follow the logic of pf, the manual say:
If a packet matches a rule which has the quick option set, this rule is considered the last matching rule, and evaluation of subsequent rules is skipped.Correct, and this part works as it should.
and if we think that pf does not care about the tab you have on the gui but it's only a single list of rules following a specific orde of quick/non quick rules ..
i will say that until you have rules on lan interface with quick option set (and they are always set as quick) that non quick rule will never applyDo you think pf works according the processing order I was questioning earlier:
- Floating Rules (Quick)
- Interface Group Rules
- Interface Rules
- Floating Rules (NON Quick)
-
or there is something we don't understand or there are 2 possibilities
first, pf does not honour the non-quick setting
or
rules are checked in this order
Floating Rules (Quick)
Floating Rules (NON Quick)
Interface Group Rules (Quick)
Interface Group Rules (NON Quick)
Interface Rules (Quick)
Interface Rules (NON Quick)but applyed in this order
Floating Rules (Quick)
Interface Group Rules (Quick)
Interface Rules (Quick)
Floating Rules (NON Quick)
Interface Group Rules (NON Quick)
Interface Rules (NON Quick) -
@kiokoman
I would vote on your first option, otherwise Action:Match would not work either (since match cannot be quick) -
There is no such thing as group or interface non quick..
The problem I think your having is your not understanding a proper use case of floating.. It is almost never going to be used with normal setups.. It is for advanced configurations.. Say for use in marking or shaping.. Or if for some reason you want to use them to apply rules to multiple interfaces - which you would then mark quick, etc.
-
@kiokoman
I mean "pf does not honour the non-quick setting" in this Block scenario. If I use it with Match (in other scenarios) packets landing in correct queues. -
@johnpoz said in Floating vs Interface rules processing order:
There is no such thing as group or interface non quick..
yes that was only teoretically speaking.
@turrican64
i will say the second, it's pf that decide the order, Action:match probably have a priority between quick and non quick
but as jonhpoz said this is not the proper use case of floating -
Unless you have some specific thing your trying to do.. Most users will have zero need of floating rules.. They can be very complex, and can lead to stuff being allowed or blocked that you did not intend to, etc.
Please read
https://docs.netgate.com/pfsense/en/latest/book/firewall/floating-rules.htmlIn most situations, we advise having Quick selected. There are certain specific scenarios where leaving Quick unchecked is necessary, but they are few and far between. For most scenarios, the only rules they would have without quick selected are match rules traffic shaper rules.
Marking and Matching
Using the Tag and Tagged fields, a connection can be marked by an interface tab rule and then matched in the outbound direction on a floating rule. This is a useful way to act on WAN outbound traffic from one specific internal host that could not otherwise be matched due to NAT masking the source. It can also be used similarly for applying shaping outbound on WAN from traffic specifically tagged on the way into the firewall.
For example, on a LAN rule, use a short string in the Tag field to mark a packet from a source of 10.3.0.56. Then on a floating rule, quick, outbound on WAN, use Tagged with the same string to act on the traffic matched by the LAN rule.
-
that doc is well made
this is the part i like the most:
Floating rules can be a lot more powerful than other rules, but also more confusing, and it is easier to make an error that could have unintended consequences in passing or blocking traffic.and this
Without Quick checked, the rule will only take effect if no other rules match the traffic. It reverses the behavior of “first match wins” to be “last match wins”.
ergo
Floating Rules (Quick)
Interface Group Rules (Quick)
Interface Rules (Quick)
Floating Rules (NON Quick) -
The documents are quite clear, unless its all greek to you - then its just gibberish ;)
My advice to new users to firewalls and pfsense in general would be to not use the floating tab at all. Or use if for very simple things where you have a lot of interfaces, and would you would set the "quick" option.
-
to me it is clear but nevertheless i can be wrong
-
Please read
https://docs.netgate.com/pfsense/en/latest/book/firewall/floating-rules.htmlI've read this document. It lists potential use cases, but doesn't say it is improper to use block without quick. It offer this combination but it does not work in the way as the document describes.
@kiokoman said in Floating vs Interface rules processing order:
Without Quick checked, the rule will only take effect if no other rules match the traffic. It reverses the behavior of “first match wins” to be “last match wins”.
Yes this is clear statement but my previous question about this statement regards my example rule in Floating:
This the only rule in Floating Rules, therefore no other rules macth the traffic in the Floating Rule, so this block rule should take effect without Quick checked.
If someone can answer why it is not working in my very simple case would be great otherwise I consider Action:Block, Direction: In, Quick: no, is not
a proper use case of floating..
-
i think the most simple way to understand how it work is to delete all the rules on the lan interface and use only floating and check what happen after that put back the rules on the lan and compare
but as i say it is not a proper use case of floating and you should not use it -> There are certain specific scenarios where leaving Quick unchecked is necessary, but they are few and far between.
Probably Scenario that we would not understand until we are in the middle of that. -
found this
from jim-p
https://www.reddit.com/r/PFSENSE/comments/95z9p3/floating_rules/
*If you do not check Quick, then the rule will only activate if no other rules on any tab match the traffic. This includes rules on group and interface tabs as well as other floating rules that come after it.Consider this: The default block rule is, effectively, a non-quick floating rule that comes before all other rules. Thus, if there are no other matching rules (or no rules at all) on an interface, the traffic is blocked by default. This is how we enact the "default block" policy for the inbound direction.
There are similar (but more complex, due to routing needs) non-quick pass out rules for traffic exiting the firewall. But since they come before the user rules, even floating rules, if you make your own non-quick floating rules that match the same traffic, your own rules will be used instead.*
some practial use
https://www.reddit.com/r/PFSENSE/comments/7r0zfn/practical_use_of_floating_rules/ -
@kiokoman said in Floating vs Interface rules processing order:
found this
from jim-p
https://www.reddit.com/r/PFSENSE/comments/95z9p3/floating_rules/
*If you do not check Quick, then the rule will only activate if no other rules on any tab match the traffic. This includes rules on group and interface tabs as well as other floating rules that come after it.Thank you kiokoman. This supports the previous theory about the processing order
- Floating Rules (Quick)
- Interface Group Rules (always Quick)
- Interface Rules (always Quick)
- Floating Rules (NON Quick)
However this raises again the question, what about Action:Match (used for traffic shaping for example) which can be only Floating+NON Quick? If those rules would processed after everything they weren't work in many cases.
-
There is no sense to put quick on a match rule. It doesn't pass traffic so if processing stops there the traffic will be blocked anyway.
Rules are processed in order whether or not quick is set. The difference is that processing stops when a quick rule is matched whether the rule passes or blocks the traffic. No other rules are processed.
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.
Take, for example, the default deny rules:
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.
-
@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: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? -
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.
-
Ok
block in log inet all tracker 1000000103 label "Default deny rule IPv4
is at the very top of the ruleset.Clear