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.
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.
Quote from: OPNenthu on February 01, 2026, 12:04:41 AMuse cases where the ability to keep a single-interface floating rule might be needed
A single interface group might still do the trick.
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?
Quote from: OPNenthu on February 01, 2026, 12:40:46 AMfiltering 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.
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 (https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html) 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.
But NAT always goes before filtering also in pfSense. It's part of the fundamental design which was not changed after the fork.
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).
Quote from: nzkiwi68 on February 01, 2026, 01:15:13 AMFinal 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.
Quote from: Patrick M. Hausen on February 01, 2026, 01:05:49 AMBut 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.
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.
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.
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).
Where did the automatic rules end up?
Those that were installed by f.e. crowsec etc.
I do use floating rules that are generic for ALL interfaces, it could be replaced by a group that has ALL interfaces in it if it needs to be.
That would require an ALL interface group to be applied first i guess, and requires an ordering on Groupnames in the rules section.
Quote from: Noci on February 01, 2026, 12:59:42 PMWhere did the automatic rules end up?
Those that were installed by f.e. crowsec etc.
I don't use crowdsec but try the "Inspect" button. That shows the system generated rules, at least. Maybe others are hidden behind that as well?
Quote from: Noci on February 01, 2026, 12:59:42 PMI do use floating rules that are generic for ALL interfaces, it could be replaced by a group that has ALL interfaces in it if it needs to be.
You can keep using Floating rules in the new UI if they apply to multiple interfaces, that's not a problem. The only new restriction is that you can't have a Floating rule on a single interface.
The do become visible under inspection, then again in the drop down selector "all rulles" only shows the non-automatic ones.
Whereas the "inspect button" mentions "all rules" to mean inclusing automatic ones. including an extra column with counter.
Could have been more clear though.
Yes, automatic rules are shown under "👁 Inspect".
But if old floating rules that only used 1 interface are no longer displayed why do they appear under "All rules" with the red layer icon if you inspect them?
Also if you inspect the rules in "All rules" they are listed as follows:
1. Automatic Rules
2. Floating Rules
3. Interface Rules (I guess in a-Z order) with checkboxes to enable/disable
4. Interface Rules again (from the legacy rules)
This was very confusing at first but I just noticed that the duplicates are actually the old rules that I didn't delete yet. So I just answered my own question again. ^^
I guess the old rules are active until you delete them and then the new ones take over?
https://github.com/opnsense/changelog/blob/7c2bcc9c4b7f6f4858a6105ff531536f4881297d/community/26.1/26.1#L123
https://docs.opnsense.org/manual/firewall.html#rules-new
> I guess the old rules are active until you delete them and then the new ones take over?
Both can and will be used.
Cheers,
Franco
I just did a clean install to version 26.1.3. I have setup everything manually, no import from old config.
I setup DNAT with 2 LAN and 2 WAN rules. At the end of each of them, I set "Register Rule".
The docs state "Adds a linked filter rule in Firewall ‣ Rules [new]..."
However, when I go to Rules [new], I can only see them by choosing inspect, as stated above.
Is the reason because they "cannot be manually edited", so you do not want confusion with a rule displayed,
but with no way to edit? (Apologize if this has been answered already.)
Edit: I created a category, added the 4 rules. Went back to Rules [new], with 'All Rules' and my new category, and Inspect active. Hoping to see just my 4 rules, but it was blank. Could this be changed at some point?
Do you mean you want the linked firewall rules to inherit the category from the NAT rule?
It would most likely be better to create manual firewall rules.
Quote from: Monviech (Cedrik) on March 06, 2026, 03:39:28 PMDo you mean you want the linked firewall rules to inherit the category from the NAT rule?
Yes, indeed. If it could work, then I would only see "my" rules. It would just be less scrolling to get to the end of the list. I will also try "Groups", but need to read up on it first.
Edit: No, 'Groups' has a very different function.
But could you confirm the 4 rules should be hidden, unless you choose Inspect? Thanks.
Register rules for DNAT are automatic rules and only visible with inspect in the new GUI, yes. That's also the reason you can't edit them directly.
Cheers,
Franco
Great, thank you for confirming. BTW, the new features are amazing. Just about done with the setup.
Quote from: franco on March 06, 2026, 09:24:08 AMBoth can and will be used.
But according to the processing order the old rules are effectively never reached if the new rules are also "First match" which is probably 99.9% of all rules (except for floating and group rules). So because everything is working fine I'm safe to delete the old ones.
The only thing bothering me now is the very laggy loading of the new rules. I have a very slow system - Biostar A68N-2100K. :)
You probably don't notice it on a fast system.
By the way what is the priority for these?
Quote2. Firewall ‣ Rules [new] and Firewall ‣ Rules floating rules
3. Firewall ‣ Rules [new] and Firewall ‣ Rules group rules
They can't really be on the same level, I see that my old floating rules are before the new single interface rules, so the list should have more numbers?
Edit: Nvm I overlooked that 2. is both floating rules, in that case the new floating rules don't even exist, so there can't be a priority issue.
Quote from: Monviech (Cedrik) on March 06, 2026, 03:39:28 PMDo you mean you want the linked firewall rules to inherit the category from the NAT rule?
It would most likely be better to create manual firewall rules.
But isn't that the preferred method advised here : https://docs.opnsense.org/manual/how-tos/nat_reflection.html#nat-method1 ?!
Quote from: vpx23 on March 06, 2026, 05:27:43 PMThe only thing bothering me now is the very laggy loading of the new rules. I have a very slow system - Biostar A68N-2100K. :)
You probably don't notice it on a fast system.
IMHO that is not a slow CPU for something like a Firewall with a webGUI so perhaps you got a webbrowser issue ?!
@franco The documentation only explains processing order but not application order of the rules.
Can you confirm that this application order is correct?
S7eCzOE.png
The graphic is from the last post of this thread: https://www.reddit.com/r/opnsense/comments/11et0b1/help_understanding_firewall_quick_and_nonquick/
Quote from: vpx23 on March 06, 2026, 09:37:52 PMThe documentation only explains processing order but not application order of the rules.
Processing and application is one and the same in my book.
Also curiously waiting for a definite answer. I think that picture is not accurate, but I don't know, so I won't post what would be just my speculation.