Hi.
What are the plan for the old rules ? Will they be deprecated, and then removed at some point ?
Yes but there is no plan for that yet and it might take a longer while still. Check our roadmap sometimes for updates:
https://opnsense.org/roadmap/
Likely moving to plugins where they would still work, but definitely not before 2027. No plans to EoL it.
Cheers,
Franco
There is enough time to get use to it, explore it and inspect it :)
The new rules section provides more visual appealing look and fixes some "mistakes" of the old ones.
Regards,
S.
I'm pretty surprised by the lack of negative feedback so far. So I guess overall it's a win (for most).
You are surprised? :D
But people literary wanted/cried for separators.... They got it and even more...
Regards,
S.
The funny thing is, once the separators were implemented the people who cried for them never gave any feedback anymore.
well... BAU [business-as-usual]
Or you guys achieved 100% customer satisfaction.
Regards,
S.
I've been meaning to try the rule migration (haven't yet worked up the courage) mostly because I wasn't sure how a couple of single-interface floating rules would be handled. I saw this in the 26.1 release notes:
QuoteSingle interface from the floating interface will not be considered "floating" in priorities.
But I still don't know, will I need to make manual edits in the csv export to fix those? Or will I need to add them manually afterward?
I'll probably give it a go soon. :)
You don't need any manual edits. Just import them, see the result, change things in the GUI as needed and then apply.
Thanks. That's a relief, as I'm a bit afraid it'll take me some time to migrate my main production system and its 2000 or so rules (or maybe the migration will work on first try, who knows ;-) )
Quote from: Monviech (Cedrik) on January 29, 2026, 02:10:21 PMI'm pretty surprised by the lack of negative feedback so far.
I will let you know once I have decided it's time to do the 26.x upgrade... Mwahahaha!!! >:)
But seriously :
Sometimes certain changes just simply
"Hit the Jackpot!" and make everything soo much better that there is exactly 0,0 reason to complain about it :)
For me one of the most recent experiences was switching to OPNsense instead of my Ubiquiti UniFi USG 3P Router because it reminded me of the days when I had xDSL instead of Fiber and was using a DrayTek Router for that connection :
A simple and clear webGUI with so far all the options I could ever dream of and probably more than that, without fussing and fighting with Java and MongoDB from time to time !!!
And another change that was also simply excellent was the upgrade from Pi-Hole v5.x.x to v6.x.x when it was released last year and the whole concept of it basically totally changed :
- Dumped LigHTTPd
- Dumped PHP
- Switched to Civetweb
- FTLDNS got even better with a lof of new functions and features.
- The webGUI got basically 1:1 access to the config file which is also commented very nicely and extensively.
These two are now my favorite software projects on my network ;)
I am having the same combination, Pihole + OPN.
But I run Piholes in a HA setup cause why not.
Regards,
S.
Quote from: Monviech (Cedrik) on January 29, 2026, 02:15:29 PMThe funny thing is, once the separators were implemented the people who cried for them never gave any feedback anymore.
Alright so that you don't feel sad about this I have one complain :)
Would it be possible to have the Statistic section in a single row if I expand its section?
(https://forum.opnsense.org/index.php?action=dlattach;attach=51720)
It drives me nuts that its in two rows even tough I have a lot of space...
Regards,
S.
Quote from: Monviech (Cedrik) on January 29, 2026, 02:35:45 PMYou don't need any manual edits. Just import them, see the result, change things in the GUI as needed and then apply.
Just reporting back to say that the import went without hitch. :)
I did it yesterday and haven't seen any issues so far. The single-interface Floating rules got converted to interface rules automatically.
The only negative is that it split up my related floating rules which were previously together. I had two similar rules for the same purpose, but one was for IPv4 and one for IPv6. The IPv4 rule was for WAN only and the IPv6 rule was for WAN + an interface group. I had given them similar descriptions and everything. Post migration the IPv4 rule became a WAN interface rule and the IPv6 rule stayed as Floating. Same end result, but difference in organization and view.
I should probably take time to re-think my rules in light of the new way.
One more thing: the hyperlinks in Firewall->Groups continue to point to the legacy Rules UI which is now empty. I'm guessing that's the case in more places wherever links exist to 'firewall_rules.php' or 'firewall_rules.php?if=<name>'.
Since the legacy rules UI is going to be around for a long while still, could we have an option to update all the links in OPNsense to point to the new UI? Or is that not really in the cards because the links are static?
Can you add a ticket for this? There's two spots actually.
src/opnsense/mvc/app/views/OPNsense/Firewall/group.volt: return '<a href="/firewall_rules.php?if='+row.ifname+'">'+row.ifname+'</a>';
src/opnsense/mvc/app/views/OPNsense/Interface/overview.volt: $a_fw = $anchor.clone().attr('href', '/firewall_rules.php?if=' + row.identifier);
Not sure what to do. We can't make a single decision here and removing the links may be better.
Cheers,
Franco
https://github.com/opnsense/core/issues/9672
Quote from: Seimus on January 29, 2026, 06:48:34 PMWould it be possible to have the Statistic section in a single row if I expand its section?
https://github.com/opnsense/core/issues/9674
Regards,
S.
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.
If you mean the rule refid (aka whats used in the live log), that is volatile and only exists inside the lifetime of the log. It cannot be added to the rules.
Quote from: Monviech (Cedrik) on January 30, 2026, 05:48:11 PMIf you mean the rule refid (aka whats used in the live log), that is volatile and only exists inside the lifetime of the log. It cannot be added to the rules.
Wait what? Do you mean this?
rid.png
I think I wrote a post on another thread where I suggested to use the rule ID for parsing firewall logs with Monit and nobody corrected me! Uff.
Do rules in OPNsense have a persistent identifier at all?
Oh thats the UUID I think, you can just use the bootgrid menu to unhide it. At the top right next to the number dropdown that changes how many lines can be seen (50).
Phew. :)
I'm not sure if that's what @julsssark is asking for, but I got nervous with your response. Thanks.
There is some kind of volatile ID inside the live log that changes and out of that the current rule reference is generated (aka the UUID). So you can map from the live log to the firewall rule (the firewall rule uuid will always be the same), but you cannot map from the firewall rule to a specific livelog ID.
But not 100% sure here, just somethibg I picked up a while ago I think.
Unless I'm mistaken, I'm seeing that the rule UUIDs have changed since I migrated my rules to the new UI. They no longer match the UUIDs I had used in my Monit tests.
Do those UUIDs persist between config imports and OPNsense updates?
I was looking for "rulenr" as displayed in the live-view details dialog. I use them in Grafana for log analysis of specific rules.
I guess "rulenr" is the volatile one?
I don't understand why it would change unless you add/remove rules, in which case a reordering of the rule numbers would be called for. 🤷
Automatic rules shift the rulenr of rules below it unfortunately. The best way to track the rule is the rule label hash.
Cheers,
Franco
Quote from: franco on January 31, 2026, 09:06:42 PMThe best way to track the rule is the rule label hash.
Just want to make sure I got this right.
In the file /var/log/filter/latest.log, the 4th comma field (e.g. 748a8bd4b5eb7bd575386d52b70e4100 below) is the rule UUID. However I've observed on my own system that this value has changed for a particular rule even though the rule label hasn't changed, so am I correct that this is not the hash of the rule label?
<134>1 2026-01-31T15:47:02-05:00 firewall.h1.home.arpa filterlog 3729 - [meta sequenceId="217800"] 259,,,748a8bd4b5eb7bd575386d52b70e4100,igc1,match,pass,out,4,0x0,,63,15842,0,DF,1,icmp,28,69.xxx.xx.99,1.1.1.1,datalength=8
In that case, is there anything reliable by which we can filter on these log lines with Monit to catch rule matches?
Feedback on New Rule interface...
Looks nice, needs a bit of getting acquainted i guess.
Two issues that could be handled better.
1) During export old, import new there was one error: interface lo0..? rule. I deleted that one as i see no reason for a rule filtering traffic on lo0. appearently it doesn't exist in 26.1 anymore.
2) There is an error either in export or import of rules with html encoding. allrules having special signs like > are different.
Allow Float -> ICMP out changed into Allow Float -> ICMP out
If exporting uses HTML safe data, then import should as well.
https://github.com/opnsense/core/issues/9694