26.1 - after export & import incl floating rules , new floating rules is empty

[nzkiwi68]

I see what happened.

Because my floating rules only have a single interface referenced, they were migrated to the appropriate interface as LAN or WAN etc interface rules.

However - this is a significant behavior change
The reason I use these rules on floating, is to ensure these block rules are always processed before interface rules. That way, special rules like Spamhaus DROP are always processed before the WAN interface rules. I can reorder WAN rules without fear of accidentally undoing special block rules.

OPNsense firewall processing order (in part):
 1. Floating rules first
 2. Interface rules second

Lastly, if I then add a 2nd WAN later on, it's very easy with a floating rule to have these block rules apply to WAN and WAN2, etc.

[OPNenthu]

There is a GH ticket where the development team is soliciting feedback on use cases where the ability to keep a single-interface floating rule might be needed:

https://github.com/opnsense/core/issues/9652

If either enough voices are added, or if someone finds a use case that can't be solved otherwise, then I think there could be some traction on getting this added back.

Right now it seems the position of the devs is that the single-interface floating rule concept is flawed and existed as a work around to an old problem.

[Patrick M. Hausen]

use cases where the ability to keep a single-interface floating rule might be needed

A single interface group might still do the trick.

[OPNenthu]

I think that's true as long as Floating rules are not special in some way.  I had previously thought that there were some things only Floating rules could do (for example, filtering egress e.g. WAN out before NAT takes place) but I can't find anything to support that now.  The current documentation says that NAT takes place first *always*.

Are there any special properties of Floating rules besides that they have highest priority?

[Patrick M. Hausen]

filtering egress e.g. WAN out before NAT takes place) but I can't find anything to support that now.

The idea that floating rules would precede NAT on interface groups or interfaces was a misunderstanding by - most prominently - @meyergru and myself.
NAT always goes before filtering, period.

So up until now we could have three stages of filtering:

- floating
- interface group
- interfaces

and create a single interface floating rule if necessary or convenient. That is for the time being not possible, anymore, for a single interface.

Everything else has not changed.

[OPNenthu]

It wasn't just you and @meyergru, I had seen it elsewhere in the past.  Also ChatGPT believed the same (maybe it was trained on old posts from here) :)

I'm sorry to link to the competition's documentation but they have some descriptions there which have me thinking that we are losing some capability with this change.  Some of it is over my head though e.g. ALTQ.

[Patrick M. Hausen]

But NAT always goes before filtering also in pfSense. It's part of the fundamental design which was not changed after the fork.

[nzkiwi68]

Ok!

After looking at the GitHub ticket, and creating an interface group "WANgroup" with a single WAN interface in this group (in my home config anyway) - I get the desired behaviour;

>>>> interface group rules are processed before the interface rules <<<<

I therefore cannot think of a use case for floating rules.

Thanks Patrick M. Hausen - a single interface group does indeed do the trick. It wasn't hard at all to modify each rule and simple unselect the single interface "WAN and select "WANgroup" to move the rule one by one to the new interface group called "WANgroup".


Final suggestion
Update the release notes for 26.1 and provide a bit more guidance about floating rules - recommendation to migrate these to Interface Groups and also explain that a floating rule that only has a single interface in the old rules will be migrated under new rules to appear under that single interface (and not in floating rules).

[OPNenthu]

Final suggestion
Update the release notes for 26.1 and provide a bit more guidance about floating rules - recommendation to migrate these to Interface Groups and also explain that a floating rule that only has a single interface in the old rules will be migrated under new rules to appear under that single interface (and not in floating rules).

Agreed. I had this doubt also before the migration.

But NAT always goes before filtering also in pfSense. It's part of the fundamental design which was not changed after the fork.

Yes I think we can put the NAT question to bed.  Are there other scenarios where Floating rules have special powers which we might want to leverage on a single-WAN setup?

The very first sentence in the pfSense doc:

"Floating Rules are a special type of advanced rule that can perform complicated actions not possible with rules on interface or group tabs."

... is concerning.  But I don't know enough to put my finger on it.

[Patrick M. Hausen]

As far as I understand (which is comparably deep but still limited) there is nothing special apart from the precedence. Of course the "not possible" part might refer to e.g. what I am doing about ICMP echo. A single (or a pair of) floating rules permits ICMP echo for IPv4 and IPv6 from any interface to any other interface in the systems I manage.

[OPNenthu]

There's a lot of conflicting information online.  Example: https://www.reddit.com/r/PFSENSE/comments/dnjfxj/floating_rules/

This one claims that Floating rules are evaluated and applied differently than normal rules.  I can't tell what's true, what's BS, and what's true but only in pfSense and not in OPNsense.

I don't know how others feel but I for one would advocate for a topic-specific guide on Floating rules in OPNsense docs, going over their lesser known properties and uses.

[nzkiwi68]

Looking at the developers GitHub, it looks like floating rules are going to be deprecated.

I for one, can't actually see a use case for floating rules that firewall interface groups doesn't cover.
I also like how you can add and subtract interfaces to an interface group, set the interface group sequence (aka rule order processing).

With floating rules, to now add WAN3 you needed to edit every rule to now work against WAN, WAN2 and WAN3 as opposed to simply adding WAN3 to WANgroup (firewall group).