Thank you devs for the hard work that went into 26.1! It's going to be a great release and I am especially looking forward to the new rules interface. I have some feedback to share based on my initial testing of the rules migration. Please take my comments in the helpful spirit I intend:
- Anti-lockout instruction clarity: The instruction text says "enable the anti-lockout rule" while step 2 says "Deselect anti-lockout in advanced settings." Given the wording of the control itself ("Disable anti-lockout"), I suggest revising the instruction text to: "To prevent being locked out during the rule migration process, enable automatically generated lock-out rules..." and updating step 2 to: "Uncheck the 'Disable anti-lockout' checkbox."
- Import rules dialog: The dialog would be clearer with an explicit "Import" button instead of relying on the checkbox. On first use, I wasn't sure what to click to initiate the import—I expected the checkbox to validate the file and then present a button to execute the import.
- Destination field validation: The firewall rules in my test VM are the default LAN rules (allow LAN to any, v4 and v6). The import validation failed with "[destination_net] A value is required." The rules export should automatically populate "any" for the destination_net field in these cases. If this behavior is by design, the error message should clarify whether to enter "any" or "*" to resolve it. (I used "any" and the import succeeded.)
- Import completion feedback: No confirmation is displayed when the import completes—the dialog simply disappears. In my test case with no floating rules, the dialog closed with no visible indication of success because the default view is floating rules and I didn't import any (i.e., it looks like nothing happened). Suggest adding a confirmation dialog: "X rule(s) successfully imported. Select the interface dropdown to view imported rules for each interface."
- Typo: "Now we can import the exsiting rules..." → "existing"
Some of this was already discussed here (https://forum.opnsense.org/index.php?topic=50474). There are a few more glitches with the migration...
The clarity can be discussed, its always hard to have enable to disable checkboxes.
https://github.com/opnsense/core/pull/9644
Thanks for the feedback. I'm looking at:
QuoteDestination field validation: The firewall rules in my test VM are the default LAN rules (allow LAN to any, v4 and v6). The import validation failed with "[destination_net] A value is required." The rules export should automatically populate "any" for the destination_net field in these cases. If this behavior is by design, the error message should clarify whether to enter "any" or "*" to resolve it. (I used "any" and the import succeeded.)
I think that's https://github.com/opnsense/core/commit/ba8194ded
Cheers,
Franco
Is there a page of migration instructions that we can review prior to upgrade?
There is no automatic migration of firewall rules. Both new and old component are fully functional side by side.
So dont worry about upgrading, nothing will change.
After the upgrade there will be a migration assistant you can choose (or not yet choose) to follow. No rush.
Wonderful, Thanks!
Thanks Franco. Those patches solved the destination field validation issue. I tested after installing the patches and the default rules with "any" imported correctly without error.
Thanks Cedrik. Your changes to the instructions help. I agree with your point that checkboxes with "disable" as their name are confusing. If there is a desire to fix those settings in a future release, I am happy to test and update docs.
In playing around with the new rules layout, I noticed that if a rule is deactivated, the controls for that row are also dimmed. The controls work so they should be enabled. See the enclosed screenshot. I saw the same behavior with Safari and Firefox.
Do the imported rules and the system-generated rules have the same rule numbers in the new engine as they do in the old one? If the rule numbers can change, it would be helpful to add that to the docs, especially for people who use syslog servers and have logic based on firewall rule numbers.
Quote from: Monviech (Cedrik) on January 23, 2026, 03:48:54 PMThere is no automatic migration of firewall rules. Both new and old component are fully functional side by side.
So dont worry about upgrading, nothing will change.
After the upgrade there will be a migration assistant you can choose (or not yet choose) to follow. No rush.
So eventually this :
Quote from: julsssark on January 22, 2026, 10:57:18 PMAnti-lockout instruction clarity:
The instruction text says "Enable the anti-lockout rule" while step 2 says "Deselect anti-lockout in advanced settings".
Given the wording of the control itself ("Disable anti-lockout"), I suggest revising the instruction text to: "To prevent being locked out during the rule migration process, enable automatically generated lock-out rules..." and updating step 2 to: "Uncheck the 'Disable anti-lockout' checkbox."
Will not be needed at all ?!
I have the default Anti-Lockout option disabled and built my own Firewall Rules around it instead so I would like to know if anything will be incompatible with my setup :)
Hi Team
I've tested upgrading successfully 3 times on different lab environments, but I'm confused as to why the fw rules continue to remain greyed out and uneditable once migrated and step 5 is complete, am I missing something to complete the migration of fw rules?
Everything appears to function as expected although mine aren't complicated labs, but my main reason for testing was to see what happens with ISC DHCP and IPv6, which is working.
While I do appreciate all the effort that goes into the software and please I'm not disrespecting anyone, I'm not a fan of the new firewall interface to switch between networks, it's a lot of extra clicking to navigate now. If it was possible to choose a default landing page rather than floating rules, it may help. Happy to hear the reason for the change though.
You might have to wait for a new RC or the main release since a few bugs have been squashed in the migration.
Regarding the Rules landing page, you can see the interface in the URL. You can bookmark your favorite landing interface.
In my import step I get lot's of these:
[source_net] opt2 is not a valid source IP address or alias.
but the old rules seem to reference these aliases just fine. Do I need to recreate them?
That's because the old rules don't have as much integrity checks. "opt2" is gone I think so you don't need these rules?
Cheers,
Franco
Quote from: thoth on February 11, 2026, 07:07:06 PMIn my import step I get lot's of these:
[source_net] opt2 is not a valid source IP address or alias.
but the old rules seem to reference these aliases just fine. Do I need to recreate them?
Since I use floating rules I had a few of those and just removed the invalid opt entries in the csv file then imported again.
Question:
After migration and removal of the old rules I still have two rules sections.. Is it just going to stay like that for many versions to come or after a reboot or something will it consolidate to just one Rules section again without the [new] tag?
That's the intermediate plan right now:
https://github.com/opnsense/core/commit/a92b4725789092d22c2fe8beb2ae433ec45f05c7