After migration, I still see "Rules [new]" and "Rules".
Within "Rules" there are still 9 automatically added rules - and I am not sure if that means they now exist double, in the old and in the new rules.
A clear way would be to remove the "Rule" and rename "Rules [new]" to simply "Rules".
Can I do this somehow?
Will this be added later?
As there are still rules listed with in the old rules (), this is not just cosmetic.
It is quite confusing :-)
Also, even as I deleted all "Floating Rules" they are still listed for other Interfaces, see the screenshot.
Quote from: senseOPN on February 28, 2026, 02:37:16 PMAfter migration, I still see "Rules [new]" and "Rules".
Within "Rules" there are still 9 automatically added rules - and I am not sure if that means they now exist double, in the old and in the new rules.
No, not double. It's just a Jedi mind trick.
All the rules exist in the new UI and can only be edited there after migration. Assuming you don't subsequently add more legacy rules.
As you click through each of the interfaces in the legacy UI, you'll notice they're all empty in terms of the rules that would normally be editable there. In other words, none of the interfaces have interface rules. None of the groups (if you have any) have group rules. Floating doesn't have any floating rules. They're all empty now.
Nevertheless, each of them still shows the rules from higher and lower sequence ranges (https://docs.opnsense.org/manual/firewall.html#rule-sequence), including automatic rules, in the drop-downs. Those are the overall, combined rules from both legacy and new UIs that still govern the interface at various levels
besides the one you're looking at.
(Not sure if that last paragraph made sense.)
Quote from: senseOPN on February 28, 2026, 02:37:16 PMA clear way would be to remove the "Rule" and rename "Rules [new]" to simply "Rules".
Can I do this somehow?
No, not yet. Unless you want to hack on the code.
Quote from: senseOPN on February 28, 2026, 02:37:16 PMWill this be added later?
The devs have said the old rules UI will be deprecated at some point, but it's too early. They're not even asking people to migrate at this time.
Quote from: senseOPN on February 28, 2026, 02:37:16 PMAs there are still rules listed with in the old rules (), this is not just cosmetic.
It isn't cosmetic and those are indeed real rules, just not duplicates. There's no conflict.
Quote from: senseOPN on February 28, 2026, 02:37:16 PMIt is quite confusing :-)
Agreed. Takes a minute to realize what's going on.
Quote from: senseOPN on February 28, 2026, 02:37:16 PMAlso, even as I deleted all "Floating Rules" they are still listed for other Interfaces, see the screenshot.
Hopefully it makes sense now. :)
---
TLDR; there's nothing more you need to do after migration
if you followed all the steps up to and including the one to delete the legacy rules.
Unsolicited advice: once you've migrated, don't look back at the legacy UI for any reason. Just forget it exists and try to acclimate to the new one (which is a lot like a spreadsheet). The exception is for Outbound NAT as that isn't migrated yet.
Quote from: senseOPN on February 28, 2026, 02:37:16 PMCan I do this somehow?
You can create a restricted administrator account and deny access to the the old Rules section (and anything else you don't use in your environment) to clean up the menu, and use that account.
There's a commit on master branch that hides old rules. It has its ups and downs and we're still trying to think of the best way forward for 26.7 and perhaps 26.1.x but that latter part is actually trickier if we don't know what people expect. We only hear about the ones that don't like hiding after its hidden. ;)
Cheers,
Franco
Quote from: franco on March 02, 2026, 11:23:38 AMWe only hear about the ones that don't like hiding after its hidden. ;)
I'm prone to oversimplification as I'm not familiar with the code, but-
As a transitional step, why not have a setting that toggles the old rules UI on/off? Then people can easily go back if they change their mind.
The pain of having two menu entries is much smaller than the pain of having a setting that needs to be placed, documented and then not forgetting to remove it afterwards.
The plan is to make the legacy firewall a plugin similar to legacy OpenVPN/IPsec. With that the setting to have legacy firewall rules is with the click of install/uninstall said plugin.
Cheers,
Franco
After migrating all of my Rules I used a port scanning service to make sure I still had a firewall in place - I used GRC Shields-Up and a couple local tools we have in place.
I have no plans at all to move to the new rules, until it is forced upon me. :)
The old rules work fine, and until such point @franco starts asking for us to move, they can stay where they are :)
Quote from: ProximusAl on March 02, 2026, 03:00:18 PMI have no plans at all to move to the new rules, until it is forced upon me. :)
The old rules work fine, and until such point @franco starts asking for us to move, they can stay where they are :)
+1 :)
Quote from: OPNenthu on March 01, 2026, 10:06:08 AMUnsolicited advice: once you've migrated, don't look back at the legacy UI for any reason. Just forget it exists and try to acclimate to the new one (which is a lot like a spreadsheet). The exception is for Outbound NAT as that isn't migrated yet.
That was very informative.
Those multiple groups of automatically created rules were confusing.
BUT, in my Interfaces below the old rules, I still see "Floating rules" and those are clearly MY floating rules, not automatically created!
They seem to be the same as from the new rules, at least I can see one new rule that I added in the new rules section after the upgrade.
But they have no Delete button.
Really, this is confusing!
But I hear you and will try to ignore :-)
Thanks!
BTW, in the old version, you could create a floating rule for any and all selection of Interfaces - now, adding a second Interface, will change the rule to a Floating rules and vice versa!
That means, adding a second Interface moves a rule automatically up to the Floating rules, which are handled before other rules.
And removing all but one Interface, removes the rules from the Floating rules, dropping it in priority!
This seems to be a fundamental change to before, where changing such things would never change the priority (rule-number)!
And, I cannot have "late" rules anymore for more than one Interface! Now, such a rule get's moved to the front.
Before, "Floating" was simply separate, not decided by the number of Interfaces.
Quote from: senseOPN on March 03, 2026, 09:27:56 PMBUT, in my Interfaces below the old rules, I still see "Floating rules" and those are clearly MY floating rules, not automatically created!
They seem to be the same as from the new rules, at least I can see one new rule that I added in the new rules section after the upgrade.
But they have no Delete button.
I can't tell from your screenshot what those Floating rules are but I think they would all be yours. System-generated and automatic rules go into their own categories.
If you created Floating rules in either of the new or old UIs, then I think those would reflect in the Floating folder in your screenshot.
It's true that in the new system rules with multiple interfaces get promoted to Floating, but it was always the case that multi-interface rules had to be Floating. You can't have an interface level rule with multiple interfaces.
I think the reason the Delete button is missing is because if the rules are native to the new UI then you can only delete them from there. You can't manage 'new' style rules from the 'old' style interface, even if they're visible. They're read-only.
Quote from: senseOPN on March 03, 2026, 09:27:56 PMThis seems to be a fundamental change to before, where changing such things would never change the priority (rule-number)!
And, I cannot have "late" rules anymore for more than one Interface! Now, such a rule get's moved to the front.
Not sure I understand this, but I'm interested. Can you elaborate on what you mean by "late" rule?
There's a kind of open challenge from the devs to come up with cases that no longer work in the new Floating system:
https://github.com/opnsense/core/issues/9652
I think so far the devs are winning with the caveat that you have to use a dummy or loopback interface to avoid splitting related Floating rules across interfaces :P
FWIW, I migrated my rules today (I recently transitioned to dnsmasq so decided why not continue the transition xD) and thanks to the migration assistant it was seamless. Nice work team!
Hi,
I'm also wondering about the presence of "old" floating rules or not after a migration from 25.x to 26.
Below the rules shown in the legacy rules setup :
FLOATING RULES-U.jpg
Does this mean (Automatically generated rules) that rules are still alive ?
If I check under "Rules [New]", so such rules are shown (normal behaviour).
Does those "legacy" Floating rules are necessary at all ?
Quote from: OPNenthu on March 03, 2026, 10:20:02 PMNot sure I understand this, but I'm interested. Can you elaborate on what you mean by "late" rule?
See below
Quote from: OPNenthu on March 03, 2026, 10:20:02 PMThere's a kind of open challenge from the devs to come up with cases that no longer work in the new Floating system:
https://github.com/opnsense/core/issues/9652
That's great, going to check this!
For example:
I could have allowed some port from interface A to interfaces B an C, only.
And this rule, add a generic block for this port for all local interfaces and all remotes IP (on WAN).
But adding this "late" rule, will now move it to the top, to the floating rules, as I need to add all interfaces.
So, now it blocks this port everywhere and the original rules cannot be reach anymore.
That is ... stupid, or? ;-)
Yes, I still can add ALL interfaces one by one, so that the late rules don't get moved to the top - but that's also stupid, right?
Quote from: OPNenthu on March 03, 2026, 10:20:02 PMI think so far the devs are winning with the caveat that you have to use a dummy or loopback interface to avoid splitting related Floating rules across interfaces :P
I don't understand.
Could you elaborate?
Quote from: NEOSA on March 04, 2026, 05:53:09 PMBelow the rules shown in the legacy rules setup :
https://imgur.com/a/7JU9MP9 (https://imgur.com/a/7JU9MP9)
Could you please attach that image to a post on this forum. I cannot see that since I block imgur.
Thinking again about this, it just feels like a bad idea to define "floating" rules by the number of affected interfaces.
Floating rules need to be a separate group, executed before all other rules - but they should also be possible for just one interface - they just have a generic character.
And on the other hand, regular interface rules should be definable for multiple interface without affecting the sequence.
There are plenty of reasons to allow or block something at a certain points of the rules and being able to do this for more than one interface.
Disallowing this just makes the rules more messy and I need now to add any such rule for each of the required interfaces!
@senseOPN What I meant in my last comment was that there haven't been any cases identified yet where someone needed to be able to have a Floating rule with a single interface in order to accomplish something. There haven't been any
functional breakages reported.
The impact is organizational. If you have any Floating rules in the legacy UI with a single interface, they will be migrated to the respective interface and come out of Floating. That could be a minor annoyance if you have related Floating rules that you wanted to keep together. One of the work-arounds provided is to add a loopback or some dummy interface if you really need to keep a single-interface rule in Floating.
Quote from: senseOPN on March 04, 2026, 07:54:16 PMFloating rules need to be a separate group, executed before all other rules
This is still the case as the processing order and rule sequences are consistent:
https://docs.opnsense.org/manual/firewall.html#processing-order
https://docs.opnsense.org/manual/firewall.html#rule-sequence