"Recent posts
#81
26.1 Series / Re: Upgrade to RC1 successful
Last post by Maurice - January 25, 2026, 11:53:41 AMHm... 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
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
#82
26.1 Series / Re: New rule system
Last post by Monviech (Cedrik) - January 25, 2026, 10:50:31 AMIn the new view when you press inspect you will see all rules in the correct processing order, so legacy rules can sneak between new rules. All of them have an icon (eg magnifying glass) to find them.
You cannot create folders with all rules in front of other rules because thats not the real processing order.
If you want categories to become folders you can choose "Tree", but you are yourself responsible to create categories in a way that make Tree look "good" for your usecase.
You cannot create folders with all rules in front of other rules because thats not the real processing order.
If you want categories to become folders you can choose "Tree", but you are yourself responsible to create categories in a way that make Tree look "good" for your usecase.
#83
26.1 Series / Re: New rule system
Last post by meyergru - January 25, 2026, 10:34:04 AMGood question, but I think you could create that rule as the first interface rule as well. Creating a floating rule as suggested only makes extra sure it gets processed first.
#84
26.1 Series / Re: New rule system
Last post by OPNenthu - January 25, 2026, 10:23:18 AMQuote from: meyergru on January 25, 2026, 09:43:54 AMLast week, we found - to our surprise - that the docs were correct in specifying that this is not the case. Floating rules are in fact less prioritized than implicit NAT "PASS" rules. You have to create an associated rule, which then goes to the interface rules and thus is always preceeded by floating block rules.Thanks, this explains that use case.
One more I'm curious about, pertaining to VPN killswitch floating rule as per: https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html#step-11-add-a-kill-switch-optional
I have such a rule with direction "out" on WAN, which I believe is processed post source-NAT (but irrelevant in this case- it's just matching on a tag and dropping packets). That is another case of a single-interface floating rule. Will the migration tool just convert this to a WAN interface rule?
#85
26.1 Series / Re: New rule system
Last post by meyergru - January 25, 2026, 10:14:16 AMIt is true that you can inspect the rules. What I miss is the quick overview where you can see the list of rules with all preceeding rules before them like so:
You cannot view this attachment.
You cannot view this attachment.
#86
26.1 Series / Re: New rule system
Last post by Monviech (Cedrik) - January 25, 2026, 10:03:17 AMWhen you press "Inspect" in the new rules page it should show all automatic, legacy, new rules, floating group interface etc... in the correct order filtered by the current interface.
When you press "Tree" it will also group the automatic rules in folders like the old view (only if Inspect is also active)
If a rule is missing in that overview and you have steps to reproduce it, let us know. (best as a github issue)
When you press "Tree" it will also group the automatic rules in folders like the old view (only if Inspect is also active)
If a rule is missing in that overview and you have steps to reproduce it, let us know. (best as a github issue)
#87
26.1 Series / Re: New rule system
Last post by meyergru - January 25, 2026, 09:43:54 AMAlthough I second the opinion that the migration tool will spark much more interest (and problems) with the existing user base on release of 26.1, I have to object OPNenthu's potential rationale here:
Based on what Patrick and I (and obviously, OPNenthu) believed until Friday last week, a floating rule was the only thing that preceeds a port-forwarding "PASS" rule. Thus, our workflow was based on that false assumption. For example, we used port-forwarding rules with "PASS" for simplicity, but has floating rules to black any access from blocklists like Firehol, Blocklist.de or QFEEDs.
Last week, we found - to our surprise - that the docs were correct in specifying that this is not the case. Floating rules are in fact less prioritized than implicit NAT "PASS" rules. You have to create an associated rule, which then goes to the interface rules and thus is always preceeded by floating block rules.
On a side note, such rules will get disassociated during update to 26.1, as discussed here.
And BTW: This is why both Patrick and I asked basically the same questions there. Consider them obsolete.
The only thing about order that I find irritating is that, after migration, the only spot were you can really see what order all al the rules (i.a. automatic, floating, interfaces, groups, automation, "old") are being used in, is the old rules - and those will presumably be removed at some point.
Based on what Patrick and I (and obviously, OPNenthu) believed until Friday last week, a floating rule was the only thing that preceeds a port-forwarding "PASS" rule. Thus, our workflow was based on that false assumption. For example, we used port-forwarding rules with "PASS" for simplicity, but has floating rules to black any access from blocklists like Firehol, Blocklist.de or QFEEDs.
Last week, we found - to our surprise - that the docs were correct in specifying that this is not the case. Floating rules are in fact less prioritized than implicit NAT "PASS" rules. You have to create an associated rule, which then goes to the interface rules and thus is always preceeded by floating block rules.
On a side note, such rules will get disassociated during update to 26.1, as discussed here.
And BTW: This is why both Patrick and I asked basically the same questions there. Consider them obsolete.
The only thing about order that I find irritating is that, after migration, the only spot were you can really see what order all al the rules (i.a. automatic, floating, interfaces, groups, automation, "old") are being used in, is the old rules - and those will presumably be removed at some point.
#88
26.1 Series / Re: New rule system
Last post by OPNenthu - January 25, 2026, 09:29:02 AMI'm familiar with that :) It doesn't answer how existing Floating rules for a single interface will get migrated (or not) to MVC. If there is already a migration document, I haven't found it.
What I do understand from that document, is that MVC has a design restriction that a single-interface Floating rule is not possible.
Ergo, do some uses cases not transfer? Do those types of existing Floating rules simply remain in the legacy UI, or...?
What I do understand from that document, is that MVC has a design restriction that a single-interface Floating rule is not possible.
Ergo, do some uses cases not transfer? Do those types of existing Floating rules simply remain in the legacy UI, or...?
#89
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by franco - January 25, 2026, 09:25:17 AMNo, that's not something we're considering at the moment.
Cheers,
Franco
Cheers,
Franco
#90
25.7, 25.10 Series / Re: Interfaces: Neighbors: Aut...
Last post by franco - January 25, 2026, 09:18:27 AMIt's likely, but I'm not sure which version. We're at 1.0.9 now which goes into RC2 tomorrow and then we'll decide.
Cheers,
Franco
Cheers,
Franco
