Floating vs Interface rules processing order

turrican64 · Jul 14, 2019, 6:51 AM

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.1

I 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 ms

If 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!

chriva · Jul 16, 2019, 2:23 PM

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.

turrican64 · Aug 17, 2019, 12:41 AM

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?

johnpoz · Aug 17, 2019, 9:58 AM

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

turrican64 · Aug 17, 2019, 11:27 AM

@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

johnpoz · Aug 17, 2019, 11:30 AM

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?

turrican64 · Aug 17, 2019, 11:45 AM

@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 :)

kiokoman · Aug 17, 2019, 12:19 PM

@turrican64 said in Floating vs Interface rules processing order:

Floating Rules (Quick)
Floating Rules (NON Quick)
Interface Group Rules
Interface Rules

so 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

turrican64 · Aug 17, 2019, 12:23 PM

@kiokoman
Yes. This is my question.

kiokoman · Aug 17, 2019, 12:29 PM

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?

turrican64 · Aug 17, 2019, 12:35 PM

@kiokoman

@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 apply

Do you think pf works according the processing order I was questioning earlier:

Floating Rules (Quick)

Interface Group Rules

Interface Rules

Floating Rules (NON Quick)

kiokoman · Aug 17, 2019, 12:46 PM

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)

turrican64 · Aug 17, 2019, 12:48 PM

@kiokoman
I would vote on your first option, otherwise Action:Match would not work either (since match cannot be quick)

johnpoz · Aug 17, 2019, 12:52 PM

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.

turrican64 · Aug 17, 2019, 1:02 PM

@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.

kiokoman · Aug 17, 2019, 1:03 PM

@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

johnpoz · Aug 17, 2019, 1:11 PM

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.html

In 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.

kiokoman · Aug 17, 2019, 1:16 PM

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)

johnpoz · Aug 17, 2019, 1:16 PM

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.

kiokoman · Aug 17, 2019, 1:19 PM

to me it is clear but nevertheless i can be wrong