I have read the topics in this new 26.1 Series forum and I tried to understand what the new rule system entails.
I couldn't find any documentation or a clear direction and I am worried that my rules stop working, because I am using floating rules quite extensively and some posts suggest that the evaluation order will change with this new rule system in 26.1.
Can you please explain what the new rule system will look like and what the difference to the current one is?
P.S.: I don't have a test OPNsense VM, because I haven't had the time to properly isolate and setup such a test instance. It can't be a clone of my current (physical) OPNsense instance, since it would mess up my network. I would have to setup a system from scratch and create X VLANs for all interfaces in this test VM and then try to replicate my prod rules which would be a nightmare. This is just an explanation why I have to ask instead of playing around and testing it myself.
I 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.
These were asked in another 26.1 series thread (https://forum.opnsense.org/index.php?topic=50474.0) (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 (https://forum.opnsense.org/index.php?topic=49053.msg248278#msg248278) 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.
I 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
I'm familiar (https://forum.opnsense.org/index.php?topic=50304.msg256210#msg256210) 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...?
Although 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 (https://forum.opnsense.org/index.php?topic=50474.0).
And BTW: This is why both Patrick and I asked basically the same questions there (https://forum.opnsense.org/index.php?topic=50474.0). 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.
When 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)
It 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:
2026-01-25 10_10_55-LAN _ Rules _ Firewall _ OPNsense.mgsoft — Mozilla Firefox.png
Quote from: meyergru on Today at 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?
Good 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.
In 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.