"Recent posts
#91
26.1 Series / Re: Rules [new], unable to edi...
Last post by franco - January 25, 2026, 09:12:30 AMYep, RC2 on Monday. There have been a few nice reports in that area. Exactly what the RCs are for. :)
Cheers,
Franco
Cheers,
Franco
#92
26.1 Series / Re: New rule system
Last post by franco - January 25, 2026, 09:05:00 AMI was under the impression this has been documented for a while and yielded no extensive feedback...
https://docs.opnsense.org/manual/firewall_automation.html#processing-order
Not sure if and how this will fundamentally change. "Automation" rules are already used in production environments by many users and from support experience setups can have a few thousand rules which are easy to administer and perform nicely (compared to the old rules pages where this is not the case as much).
Cheers,
Franco
https://docs.opnsense.org/manual/firewall_automation.html#processing-order
Not sure if and how this will fundamentally change. "Automation" rules are already used in production environments by many users and from support experience setups can have a few thousand rules which are easy to administer and perform nicely (compared to the old rules pages where this is not the case as much).
Cheers,
Franco
#93
26.1 Series / Re: Upgrade to RC1 successful
Last post by franco - January 25, 2026, 09:00:11 AMNo, 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
The relevant patches illustrates this clearly for reference:
https://github.com/opnsense/core/commit/f8da6e147b2
https://github.com/opnsense/core/commit/e790033253c
Cheers,
Franco
#94
26.1 Series / Re: OpenVPN legacy plugin
Last post by franco - January 25, 2026, 08:56:59 AMCorrect, you can read about support tiers here https://docs.opnsense.org/support.html#supplemental-tier-2
There are no plans to remove either this year so they will keep working. If a problem appears with them (like a major OpenVPN update) it's likely the legacy plugin will not be updated until that is shipped for the MVC version in core, which could introduce incompatibilities for example.
At some point we will make an inventory for feature parity and when there's enough overlap we will let go of the old plugins (maybe 2027, 2028, who knows yet). The tier switch is an encouragement to move to the new core GUI and report issues and missing features to reach for feature parity (as far as that's possible or wanted for a couple of reasons like design, security and robustness).
Cheers,
Franco
There are no plans to remove either this year so they will keep working. If a problem appears with them (like a major OpenVPN update) it's likely the legacy plugin will not be updated until that is shipped for the MVC version in core, which could introduce incompatibilities for example.
At some point we will make an inventory for feature parity and when there's enough overlap we will let go of the old plugins (maybe 2027, 2028, who knows yet). The tier switch is an encouragement to move to the new core GUI and report issues and missing features to reach for feature parity (as far as that's possible or wanted for a couple of reasons like design, security and robustness).
Cheers,
Franco
#95
26.1 Series / Re: Kea IPv6, random allocatio...
Last post by franco - January 25, 2026, 08:51:44 AMNo problem. The advanced rules are relatively hidden for mostly good reasons and the Kea documentation on our side is not all that complete, see
https://docs.opnsense.org/manual/kea.html
where the option is not mentioned (yet).
Cheers,
Franco
https://docs.opnsense.org/manual/kea.html
where the option is not mentioned (yet).
Cheers,
Franco
#96
26.1 Series / Re: Track interface / Identity...
Last post by franco - January 25, 2026, 08:50:04 AMSorry, I can't find your PM in my inbox.
> This does very much seem like a validation error.
It is, but I'm wondering if this is new since 25.7.11 or if it was there before. I tried to keep the state of 25.7.x compatible with 26.1 although there's clearly a refactor there that could have caused it but it uses the same code as before.
If you have a custom dhcp6c.conf also by some means the validation error doesn't even effect your setup since it only tries to validate what goes into dhcp6c.conf to avoid a syntax error.
But again I may have missed something and I'd really appreciate the interface dump so it can be fixed before 26.1 is out. You can also send via mail to franco AT opnsense DOT org
Thanks,
Franco
> This does very much seem like a validation error.
It is, but I'm wondering if this is new since 25.7.11 or if it was there before. I tried to keep the state of 25.7.x compatible with 26.1 although there's clearly a refactor there that could have caused it but it uses the same code as before.
If you have a custom dhcp6c.conf also by some means the validation error doesn't even effect your setup since it only tries to validate what goes into dhcp6c.conf to avoid a syntax error.
But again I may have missed something and I'd really appreciate the interface dump so it can be fixed before 26.1 is out. You can also send via mail to franco AT opnsense DOT org
Thanks,
Franco
#97
26.1 Series / Re: Rules [new], unable to edi...
Last post by Monviech (Cedrik) - January 25, 2026, 06:43:43 AMThere is another
https://forum.opnsense.org/index.php?topic=50474.msg257599#msg257599
Best wait for RC2 since there have been more small fixes here and there :)
https://forum.opnsense.org/index.php?topic=50474.msg257599#msg257599
Best wait for RC2 since there have been more small fixes here and there :)
#98
26.1 Series / Re: New rule system
Last post by OPNenthu - January 25, 2026, 05:49:13 AMThese were asked in another 26.1 series thread (page 1, posts #9 and #10) but there hasn't been a dev response yet.
In the legacy rules UI, it's possible to create a Floating rule for a single interface (e.g. WAN). That can be used to override NAT rules on the interface such as with a blocklist.
If we have existing Floating rules for a single interface, how are those translated by the migration tool? Are they converted to interface rules, or are they "upgraded" to apply on all interfaces (to preserve them as Floating rules)? It sounds like there could be implications either way.
In the legacy rules UI, it's possible to create a Floating rule for a single interface (e.g. WAN). That can be used to override NAT rules on the interface such as with a blocklist.
If we have existing Floating rules for a single interface, how are those translated by the migration tool? Are they converted to interface rules, or are they "upgraded" to apply on all interfaces (to preserve them as Floating rules)? It sounds like there could be implications either way.
#99
26.1 Series / Re: New rule system
Last post by Aerowinder - January 25, 2026, 04:23:16 AMI am curious about this also. From what I can tell, the difference is in the way Floating rules are assigned.
Floating rules are no longer directly specified as Floating. Now, instead you simply assign your rule to more than one interface, and this automatically makes it a Floating rule vs a typical interface rule.
You can see the order process of all rules on a specific interface by pressing the new Inspect button at the top of your rule table. This shows you ALL rules associated with this particular interface, and the sequence they are processed in (you may need to enable the "sequence" option in the filter). This shows Floating rules still processing first, as they always have in the past.
Floating rules are no longer directly specified as Floating. Now, instead you simply assign your rule to more than one interface, and this automatically makes it a Floating rule vs a typical interface rule.
You can see the order process of all rules on a specific interface by pressing the new Inspect button at the top of your rule table. This shows you ALL rules associated with this particular interface, and the sequence they are processed in (you may need to enable the "sequence" option in the filter). This shows Floating rules still processing first, as they always have in the past.
#100
26.1 Series / Rules [new], unable to edit or...
Last post by Aerowinder - January 25, 2026, 04:17:13 AMGreetings,
After some testing, I've found that I am unable to Edit or Clone rules that have multiple protocols selected - ie. TCP+UDP. Rules with single protocol - ie. TCP, UDP, ICMP, or * I am able to edit. But all my rules that use TCP+UDP as protocol, I am unable to Edit or Clone. Delete seems to work, though.
When I click the Edit or Clone button on one of these rules from the interface rule list, nothing happens. This behavior does not seem to be producing any log messages, so I'm not sure how to dig down further to find the actual issue.
I have applied these patches:
opnsense-patch ba8194de
opnsense-patch 94081fd82f
opnsense-patch d1519593
But only AFTER I already transferred my rules over, so they didn't do much for me. I decided manually fixing them would be faster than restoring a snapshot and updating again to start over.
After some testing, I've found that I am unable to Edit or Clone rules that have multiple protocols selected - ie. TCP+UDP. Rules with single protocol - ie. TCP, UDP, ICMP, or * I am able to edit. But all my rules that use TCP+UDP as protocol, I am unable to Edit or Clone. Delete seems to work, though.
When I click the Edit or Clone button on one of these rules from the interface rule list, nothing happens. This behavior does not seem to be producing any log messages, so I'm not sure how to dig down further to find the actual issue.
I have applied these patches:
opnsense-patch ba8194de
opnsense-patch 94081fd82f
opnsense-patch d1519593
But only AFTER I already transferred my rules over, so they didn't do much for me. I decided manually fixing them would be faster than restoring a snapshot and updating again to start over.
