Just a quick report that I upgraded from the 25.7.11 development version to 26.1.r1, so far without issues.
Switching back to Community doesn't replace the automatically installed os-isc-dhcp-devel plugin with the non-devel version, but I think that's expected. It's an additional manual step which might be worth mentioning in the upgrade instructions.
I keep hostwatch disabled for the time being, so no statement about that.
Cheers
Maurice
Same for me, I did pgrades two OPNsense installation.
One from an installation which was on the Development channel, by switching as France explained, no issue.
The other was on the Dev channel too (not that it matters), exported config (to be sure) and reinstalled using the DVD ISO. The config was found on the ZFS pool and installation when smooth, and with the config found on the ZFS pool.
The only confusing thing was that after the installation and before the reboot the text on the console told me that the OPNsense GUI will be reachable on 192.168.1.1. That specific installation is IPv6 only, so I wasn't sure if the config was applied correctly - but it was.
Ah, oui, naturellement. ;)
I added a note about the plugin situation in the forum announcement post.
The "https://192.168.1.1" is a bit of a hardcoded relic.
https://github.com/opnsense/core/blob/e75192ca461dfa/src/sbin/opnsense-installer#L53
From an imported config where "lan" may not exist it can be difficult to extract the correct value from. Let's call it an artefact for now.
Cheers,
Franco
I switched to 26.1-RC1 as well. Most things worked OOTB, however, I found that the NAT rules filter associations were gone, showing only "Manual" instead, although some link still exists as evidenced by the associated firewall rules being non-editable as usual.
After I tried the first steps of rules migration, all new style rules had no categories and were disabled per default. I wonder what would have happened if I followed the instructions and just removed the old rules at that point.
I tried to understand how the NAT rule linkage relates to new/old rules, but failed. Since it was a production system, I did not dare to remove the old rules.
What is irritating is that "floating rules" now are just the ones that have more than one interface, so if you add an interface to any existing interface rule, the rule shifts to floating rules (and also the other way around). However, I like that, because with the old style rules, you manually have to re-create a rule in the floating section. One has to get accustomed to this, however, because I also used 1-interface-only floating rules for blocking in the floating section just because of the priority being greater than implicit port forwarding rules.
Uwe, can you check the CSV if the enable flags and categories are exported correctly for you?
Thanks,
Franco
Scratch that, here's the fix for the enabled https://github.com/opnsense/core/commit/94081fd82f
And this is for categories: https://github.com/opnsense/core/commit/d1519593
Thanks!
Edit: Since were at the topic Stephan found this earlier today as well https://github.com/opnsense/core/commit/ba8194de
> I tried to understand how the NAT rule linkage relates to new/old rules, but failed.
The old page added a separate "association rule" which is a bit of a broken firewall rule.
The new system will create a shadow rule in in "Register rule" mode somewhat resembling the old approach but without injecting a real firewall rule. Manual and pass are still the same.
Cheers,
Franco
As you have found, the enabled flag was not exported correctly nor were the categories.
I now used:
opnsense-patch ba8194de
opnsense-patch 94081fd82f
opnsense-patch d1519593
configctl webgui restart
And then re-exported the old settings. This time, the enabled and categories settings seemed correct in the CSV.
BTW: In the migration assistant list of steps, it says: "Deselect anti-lockout in advanced settings" - it should be "Enable anti-lockout in advanced settings".
The thing with the manual rule is that with 25.7.11, you saw the associated firewall rule name there, so you would know which one it was. This gets lost immediately upon update, you do not have to use the migration assistant. That means I see that there is an associated rule:
2026-01-22 18_26_16-WAN _ Rules _ Firewall _ sense.congenio — Mozilla Firefox.png
Yet in the NAT rule, it does not identify which any more (before you would see the description "Allow DNS via IPv4" instead of "Manual"):
2026-01-22 18_25_03-Destination NAT _ NAT _ Firewall _ sense.congenio — Mozilla Firefox.png
> The thing with the manual rule is that with 25.7.11, you saw the associated firewall rule name there, so you would know which one it was. This gets lost immediately upon update, you do not have to use the migration assistant. That means I see that there is an associated rule:
Yes true but it's now disassociated (manual) and the display of the firewall rules is exactly the same as before and still has the same description. Functionally after the upgrade it's the same. It only starts behaving differently when modifications are being made to destination NAT rules.
We don't have a lot of leeway leaving this concept behind other than making this cut. I can make sure to add this to the migration notes.
Cheers,
Franco
If floating is now defined by "active on more than one interface" does that change the rule processing order?
I use block rules, floating, with only a single interface - WAN. I do this because I want them applied before NAT rules on WAN. This way I can use "pass" for inbound NAT but "floating before interface" still beats NAT in processing order.
I am worried if ticking more than one IF moves a rule to floating, that a floating rule with just a single IF ticked will be moved down to interface specific.
I hope I could explain the problem - if there is one at all.
That would be my question as well, as I already hinted at... with the new logic, priorities would potentially change just depending on whether you add or remove interfaces...
Quote from: franco on January 22, 2026, 08:04:53 PMYes true but it's now disassociated (manual) and the display of the firewall rules is exactly the same as before and still has the same description. Functionally after the upgrade it's the same. It only starts behaving differently when modifications are being made to destination NAT rules.
Yet the disassiciated rule is not editable (only the rule order is and I can delete the rule)? Then if I change something in the underlying NAT rule (say, change the port), I could not even make the corresponding change in the firewall rule? See my screenshots above for what I mean...
Yes, that was how it always was. There was a point in time where they were editable but it also led to strange results so at some point it was disabled. Now in theory the edit could be re-enabled.
I'm not sure what the issue was. Only remember that the associated rules were very partial rules and this lead to expectation vs. reality situations too during the time edits were allowed.
Cheers,
Franco
The edit really should be re-enabled: The lack of editing of associated rules was fine as long as they were associated, IMHO - if they become disassociated, they should gain "full freedom" during upgrade (i.e. become editable) and not stay around like they were still associated.
By not being able to edit them or see their details, it would be error-prone, because everyone used to the old scheme (like me) would assume they are still linked to and controlled by their respective NAT rule - which they are not.
Yep, I already agreed. I'll bring it up tomorrow.
Another one: When I imported the rules after the patches, I got one "new style" rule that is not editable after importing (pressing edit just does nothing).
The imported rule was:
0b229e23-b728-4a32-85fc-4226bda46771,1,keep,,61,pass,1,0,"lan,opt1,opt2,VLANS,wireguard",in,inet46,TCP/UDP,,,,,0,0,0,0,0,,,,,,,,,,,,,,,,,,"LAN Rules",,,,,"Allow DNS to firewall",0,any,,0,(self),53
where VLANS is a group of VLAN interfaces.
I see an error in the browser console when pressing edit on that rule:
Uncaught Error: Syntax error, unrecognized expression: .protocol_tcp/udp:not(div)
jQuery 7
<anonymous> https://opnsense.localhost:488/ui/firewall/filter/:2327
jQuery 8
setFormData https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:217
each jQuery
setFormData https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:140
jQuery 2
setFormData https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:132
mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:142
jQuery 2
mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:139
complete https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:312
jQuery 6
ajaxGet https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:304
mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:137
each jQuery
mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:136
show_edit_dialog https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:1743
show_edit_dialog https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:1737
command_edit https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:1902
_linkCellCommand https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:947
jQuery 2
P.S.: The old rule is editable....
Thanks for reporting this was a small oversight
https://github.com/opnsense/core/pull/9642
Quote from: meyergru on January 22, 2026, 06:19:49 PMBTW: In the migration assistant list of steps, it says: "Deselect anti-lockout in advanced settings" - it should be "Enable anti-lockout in advanced settings".
It's an "enable to disable" kind of checkbox, so whatever way turn it, it's always a bit confusing I guess.
Quote from: Monviech (Cedrik) on January 23, 2026, 08:08:23 AMThanks for reporting this was a small oversight
https://github.com/opnsense/core/pull/9642
opnsense-patch 67668828146e80de49bc6b607db06acb12da8a61
configctl webgui restart
Works for me.
From my side all seems working well, upgraded from 25.7.11_2 to 26.1-RC1.
I've already tested IPSEC, BIND, unbound, BGP with FFR, Wiregard, OVPN, Crowdsec, Suricata, and other plugins less deeply.
FW rules migrated completely.
The only thing that I noticed is that the auto-generated floating rules are visible correctly only on old rules, in the new section I see some blank rules.
I would also ask the diff between NAT outbound rules and SNAT.
Thanks :)
⚠️EDIT: it seems that floating rules apparently blank was in fact a very dangerous "any to any" and I rolled back to snapshot this time for being sure 100% that all is properly blocked as before
Identity Association and ISC DHCPv6 are mutually exclusive, correct? ISC depends on Track Interface (legacy)?
(I'm stuck with ISC since neither Dnsmasq nor Kea support prefix delegation with dynamic prefixes.)
Cheers
Maurice
No, Identity association mode is a trick that enforces "Allow manual adjustment of DHCPv6 and Router Advertisements" so you can still use RA and DHCPv6, but only if configured manually. You can also mix and match the Track interface mode and the new one for LANs.
The relevant patches illustrates this clearly for reference:
https://github.com/opnsense/core/commit/f8da6e147b2
https://github.com/opnsense/core/commit/e790033253c
Cheers,
Franco
Hm... The current situation is: LAN interface is set to "Track Interface" with "Allow manual adjustment of DHCPv6 and Router Advertisements" enabled. ISC DHCPv6 is enabled and manually configured.
When I switch the interface to "Identity association", it vanishes from the ISC DHCPv6 menu. Entering the URL directly (/services_dhcpv6.php?if=lan) doesn't work either. But according to System: Diagnostics: Services, ISC DHCPv6 is still running.
Cheers
Maurice
Ok, fair. The menu part is https://github.com/opnsense/core/commit/e1325c5d4 .. the previous refactor wasn't needed there apparently but let's make it explicit for both modes.
The plugin side is clear but I'll push a patch tomorrow morning when I can verify it since the patch is a bit longer due to all the exceptions.
Cheers,
Franco
And the isc-dhcp part.
https://github.com/opnsense/plugins/commit/276b8ecdc5
Cheers,
Franco
@meyergru haven't forgotten the talk about NAT rule association edits but it's not in RC2 since I need to look at it and RC2 should be out in a few minutes already for further feedback. I did https://github.com/opnsense/core/commit/6c10a1cb which unhides the edit button but the edit page also has glue regarding that so I need a bit more time to prepare.
Cheers,
Franco
Thanks for the fixes, Franco. ISC DHCPv6 menu is indeed back in RC2.
Cheers
Maurice
I do hope that the menu is back AND the thing actually works ;)
And here's the second half of editing associated firewall rules
https://github.com/opnsense/core/commit/8493f8d6
I'll hotfix this when I have confirmation on the fix for https://forum.opnsense.org/index.php?topic=50505.0
Cheers,
Franco
@franco I upgraded 25.7.11_2 to 26.1.r2_2 today. I haven't migrated my rules yet, but noticed a couple interface related things:
- After upgrade, the radvd service was enabled on two interfaces where it was not previously enabled. I'm using Dnsmasq for RAs on all interfaces.
- After I manually switched all my interfaces from "Track Interface (legacy)" to "Identity Association," radvd then disabled itself everywhere.
I don't know why those two interfaces, specifically, were selected and auto-enabled and not the others.
radvd-interfaces.png
- Finally I uninstalled the 'os-isc-dhcp' plugin (I think it was labelled as 'development' even though I switched back to the Community branch after upgrade). This caused the UI to break down and required a reboot.
I could not reboot from the UI itself because it was unresponsive. Had to login SSH and issue a reboot from the command menu.
ui-crash.png
All seems normal after the reboot.
@OPNenthu strange bugs but let's go through them:
Quote- After upgrade, the radvd service was enabled on two interfaces where it was not previously enabled. I'm using Dnsmasq for RAs on all interfaces.
- After I manually switched all my interfaces from "Track Interface (legacy)" to "Identity Association," radvd then disabled itself everywhere.
The config history in those cases (especially the migration of radvd) would be nice to know here. But what I can say here already is that track6 has automatic starts of interfaces as well so your second point is just a statement of how it works. I'm just not sure which interfaces you refer to (the ones seen there or not). Maybe "Allow manual adjustment of DHCPv6 and Router Advertisements" was used on those LANs (also a bit earlier in time) which has led to several code problems over the years.
Quote- Finally I uninstalled the 'os-isc-dhcp' plugin (I think it was labelled as 'development' even though I switched back to the Community branch after upgrade). This caused the UI to break down and required a reboot.
First part is easy... packages including plugins are sticky and that was also explained better here (granted I modified it later because Maurice mentioned it):
https://forum.opnsense.org/index.php?topic=50472.msg257544#msg257544
Second part I'm unsure about. Browser console might have told us something. That it's back after reboot makes it stranger. As far as plugins are concerned nothing special happens. Did you remove it from the GUI or via command line?
Cheers,
Franco
Quote from: franco on January 27, 2026, 08:38:34 AMMaybe "Allow manual adjustment of DHCPv6 and Router Advertisements" was used on those LANs (also a bit earlier in time) which has led to several code problems over the years.
Indeed, it was used in the past. I maybe even had it checked with Dnsmasq acting as the RA daemon, but the radvd service on all the interfaces was disabled. I wasn't aware that after migration from ISC->Dnsmasq that I needed to also uncheck this option.
Still unclear why only those two interfaces in the screenshot showed up in the radvd service and were enabled, when I had several other interfaces configured identically.
I took a snapshot prior to the upgrades so I can roll back and try to reproduce... if that's helpful? I could also save a copy of my config from that version.
Quote from: franco on January 27, 2026, 08:38:34 AMDid you remove it from the GUI or via command line?
I uninstalled it from the GUI.
Quote from: franco on January 27, 2026, 08:38:34 AMMaybe "Allow manual adjustment of DHCPv6 and Router Advertisements" was used on those LANs (also a bit earlier in time) which has led to several code problems over the years.
If you have the time in the middle of a major release progressing, could you elaborate on that? This is my default setup literally everywhere.
TIA
Patrick
I haven't seen the migration config diff so I can't say anything definite about it yet.
The migration has to assume all radvd servers found in the config.xml are in use when not disabled. The code for track6 and manual override option on top of radvd burried in ISC-DHCPv6 server settings is not easy to follow and may even have been wrong historically in some spots. So if you set a radvd entry for an interface at some point but it was disabled for interface settings specific reasons it may come back as enabled even if the code was previously treating it as not being started although set to enabled (not adhering to the specific configuration, but the overall interface IPv6 config). It's a complicated situation we're trying to untangle here.
Cheers,
Franco
I never used DHCPv6. I manually enabled radvd everywhere I needed it. Time will tell :-)
I think I'd have heard from you about that already. :)
Cheers,
Franco
@franco I've completed the rollback to 25.7.11_2 and taken a fresh snapshot, so am free to start the upgrade toward 26.1.r2_2 now. I've already downloaded the config from 25.7.11_2. What else might be needed from it?
BTW: this instance of 25.7.11_2 has some manual patches applied per our previous testing, e.g. hostwatch v1.0.6 and the dhcp6c improvement from the "CALL FOR TESTING" thread.
Local patches and test packages are not an issue. The upgrade will remove them.
Just make sure to directly follow up RC1 with RC2 and a reboot to ensure consistency within the latest RC2 code.
The final update to 26.1 will take care of this eventually, but intermediate RCs are a bit "floating" in terms of overall integration. ;)
Cheers,
Franco
(Sorry, saw your message late. I didn't reboot after RC2.)
---
Ok, I'm getting a different set of results this time but nothing too concerning like from earlier.
This time I got a php error after the last upgrade toward 26.1.r2_2 and I submitted the crash report from within the GUI.
I saw that on the intermediate upgrade to 26.1.r_9, the list of interfaces under Services->Router Advertisements had already shrunk down to two interfaces from the full set of ten internal interfaces that I have, and it's the same two as before (LAN & CLEAR). The other 8 interfaces are missing from the radvd list, even though they all have the same settings (Track Interface w/ Allow manual adjustments checked). The difference this time is that the radvd service was not enabled on them after the upgrade.
Next I manually changed all the internal interfaces to "Identity Association," and as before I clicked "Save" between each interface change and applied them all in one shot at the end. It took a bit to process and my WAN IPv6 gateway went down for some reason (I didn't edit that interface) but came up after some time. The UI is still responding at this point.
Finally I removed the ISC plugin from the GUI. This time I did not get a crash. The GUI is still responding.
So it seems as though the upgrade is not deterministic when starting from the "same" state. This surprised me. There's some variability somewhere, but it's likely not in the packages (?) and it's likely not in the config file (preserved by snapshot).
Anyhow, I have the before/intermediate/after configs and I also captured the terminal buffer during the major upgrade to 26.1.r_9. Let me know if you need me to send them to you.
I'd like to see the System: Configuration: History diff for the migration of the radvd settings when it went to RC1.
It says "run_migrations.php made changes" in the left dropdown. The top one is probably it. Just click and it shows the diff vs. the previous one which is the interesting one. You can send it to franco AT opnsense DOT org
Thanks,
Franco
It was further down the list but I found it. Sent.
I'm not impeded so no concern on my end if this doesn't seem actionable. Mainly just reporting on the offchance mine isn't an isolated incident.
Thanks franco!
Yep, looked good to me: only two explicit entries and both were disabled before and after migration. If you have more tracking interface the radvd was maybe starting and feeding the others, but not these two.
Cheers,
Franco
Migrated the firewall rules on my main system yesterday. I was naughty and didn't perform step 2 (left the anti-lockout rule disabled).
Also, manually created new source NAT rules and disabled legacy outbound NAT entirely.
No issues so far!
Cheers
Maurice