Firewall rules migration

[julsssark]

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"
  

[meyergru]

Some of this was already discussed here. There are a few more glitches with the migration...

[Monviech (Cedrik)]

The clarity can be discussed, its always hard to have enable to disable checkboxes.

https://github.com/opnsense/core/pull/9644

[franco]

Thanks for the feedback. I'm looking at:

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

I think that's https://github.com/opnsense/core/commit/ba8194ded


Cheers,
Franco

[agh1701]

Is there a page of migration instructions that we can review prior to upgrade?

[Monviech (Cedrik)]

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.

[agh1701]

Wonderful, Thanks!

[julsssark]

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.

[nero355]

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.

So eventually this :

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

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

[OzziGoblin]

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.