Messages

You are correct. I am sorry, I should have tried it with your exact example. I see the same behavior you do. It looks like a bug. I tried a few different variations. The "address" field with "contains" or "is", generates the problem but using "is not" or "does not contain" works correctly. I suggest filing a bug report: https://github.com/opnsense/core/issues

I created a new criteria using Safari and it worked correctly. I am running 26.1.1. Maybe a browser issue? Is auto-refresh enabled?

26.1.1 adds some really nice updates to the rules interface!

Thank you for sharing!

See here for the answer to your second question: https://forum.opnsense.org/index.php?topic=50564.0

@Patrick, thanks for posting your firewall rule structure. You've given me some ideas for improving mine. What are your categories (i.e., how do you use them)?

I was looking for "rulenr" as displayed in the live-view details dialog. I use them in Grafana for log analysis of specific rules.

Could rule # be displayed in the statics column (or its own column or within the details dialog)? It would make downstream log management more convenient. Today, you need to trigger a rule and catch it in live view, or do some text file manipulation. If it's a feasible request, I can open an issue and help test.

Thank you to the awesome OPNSense team for another "boring" update. Updated to 26.1 without problem (boring). Removed unused ISC plugin and no longer see those legacy entries under Services (boring). Migrated to new rules interface without incident (boring). Love the new update! My pre-update snapshot will get deleted soon. Yawn :)

I completed a test rules migration with 26.1 in a VM. I clicked to remove all rules in the legacy interface. I thought the old Rules interface would disappear, but it continues to coexist with Rules [new]. I rebooted the router but both are still there. Is that the expected behavior?

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.

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"
  

I was using almost the same setup you are thinking about, and it worked great for my homelab that only uses IPv4. I used Kea for DHCP and AdGuard to Unbound for DNS. Just make sure that you set the DNSMasq port to 53 and use a different port for Unbound (e.g., 15353). Be aware that with this configuration, when you set static hosts in Kea, you will also need to add an entry to DNSMasq if you want to reference that host by name/DNS.

Is there a reason/feature that you want to use Kea for DHCP vs. letting DNSMasq do it? The OPNsense docs summarize the options nicely: https://docs.opnsense.org/manual/dhcp.html#available-options

Edit: I switched to DNSMasq for DHCP when that became the recommended setup for small installations.

Watchful Wolf :)

You've got a brand new Protectli and you are going to wait for 26.1? You are way more patient than I would be with a new toy. :)