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 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?
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.
In the new rules system, how do we override a floating rule for a specific interface?
For example we have a quick block rule in Floating, but in one of the interfaces we want to override that block with a higher priority rule. Is this still possible?
In the old system we could just create another Floating rule for the specific interface and position it above the block rule. As far as I can tell, the pf manual allows for that:
https://www.openbsd.org/faq/pf/options.html#state-policy
Quoteset state-policy option
Sets PF's behavior when it comes to keeping state. This behavior can be overridden on a per-rule basis. See keeping state.
if-bound - states are bound to the interface they're created on. If traffic matches a state table entry but is not crossing the interface recorded in that state entry, the match is rejected. The packet must then match a filter rule or will be dropped/rejected altogether.
floating - states can match packets on any interface. As long as the packet matches a state entry and is passing in the same direction as it was on the interface when the state was created, it does not matter what interface it's crossing. It will pass.
The default is floating.
https://man.openbsd.org/pf.conf.5
Quoteset state-policy if-bound | floating
The state-policy option sets the default behaviour for states:
if-bound
States are bound to an interface.
floating
States can match packets on any interfaces (the default).
... by use of the word 'any' instead of 'multiple', it doesn't preclude floating rules for single interfaces. I think the behavior of the old rules system is still legal.
"state-policy" directives have nothing to do with the parting of the rule GUI "floating" tab concept and they won't change behaviour either.
Cheers,
Farnco
Thanks for the correction. I think my question still stands. :)
It kind of depends what parameters you're targeting the traffic on. You can just use a floating rule without an interface selected while select the source or destination of the traffic in an "in" direction rule correctly. There's no apparent need for an interface and routing domains don't exist so networks don't overlap in a routing setup.
Cheers,
Franco
Another way to force priority changes:
- Fake Floating: Add a random loopback interface additionally to any single interface rule
- Fake Group: Add a new firewall group with a single interface
Or you change the approach how you build your ruleset.
Thanks for the all the replies. I am still trying to understand how the new interface will look like. Are there annotated before/after screenshots for all the changes available? I have read the link Franco provided about the processing order when I started to use OPNsense (many yers ago), but since I do not use "Rule Automation", the overall processing order documentation was much more helpful to me back then.
While I could glean that the changes mostly pertain to the automation rules and UI, a bunch of posts suggested that the order of other rules (interface, floating, NAT) will change with 26.1.
If this is not the case and if everything will still work without changes when I do not use automation, this can be closed from my side. (Although I am still interested in the current discussion about automation as well.)
However, if there's anything in the UI and/or processing order that will change for anything but automation, I would like to repeat my question: how exactly does it change and what is the difference to the current UI and/or processing order?
@tessus The "Automation" rules UI in 25.7 has been moved to "Rules [new]" in 26.1. The idea is that this UI (regardless of whether you use automation or not) will eventually replace the legacy Rules UI. I think what we're talking about here will eventually affect everyone, but not for a while.
What I'm hearing from the responses so far is that nothing changes except for the ability to set Floating rules on a single, specific interface. That is a loss in flexibility with the new rules system, but I don't know if it will be a big deal or not. If that doesn't affect you then you can happily use the new system.
I don't think anything is changed in the old rules system so if you're still using that you're good for now. The concerns people had around NAT and rule order impacts were regarding the new rules system and those turned out to be incorrect as @meyergru explained to me.
I added a feature request: https://github.com/opnsense/core/issues/9652
If this gets rejected, so be it. I don't know what limitations or challenges there are to doing this with the new MVC approach.
Thanks @OPNenthu
Quote from: OPNenthu on January 27, 2026, 02:09:47 AMnothing changes except for the ability to set Floating rules on a single, specific interface.
Yep, this might be bad for me. I actually use quite a few of those.
Of course I could move them to the specific interface, but I used the floating rules UI for a reason. It is easier and more convenient to have an overview, especially if you want to clone a rule for a new interface. You don't have to click on every interface to find the rule.
The workaround to create groups with a single interface is a massive overhead in terms of administration. Why not support a single interface instead?
Anyway, I am sure I will adapt. I just hope it's not too much work and that the result won't be less intuitive and convenient.
@tessus sorry, pay attention to this note in the latest release notes also:
Quoteo Firewall: NAT: Port Forwarding is now called "Destination NAT". Firewall rule associations are no longer supported, but the old associated firewall rules remain in place with their last known configuration and can now be edited to suit future needs.
This was discussed in another thread too. If you have existing NAT association rules on your interfaces they'll still be there after the upgrade, but they're unlinked now from the NAT rules. You have to remember to manage them manually.
Quote from: OPNenthu on January 27, 2026, 06:20:59 AMThis was discussed in another thread too.
This is a bit strange though. Port forwarding is not the same as DNAT. It's true that DNAT is often used in combination with port forwarding, but that doesn't mean that port forwarding rules should be renamed to DNAT. Hmm, this is rather concerning.
Quote from: OPNenthu on January 27, 2026, 06:20:59 AMIf you have existing NAT association rules on your interfaces
I don't think I have NAT association rules on my interfaces. Afaik I always created rules manually.
Is there a way to find out?
Quote from: tessus on January 27, 2026, 09:00:22 AMPort forwarding is not the same as DNAT.
I'm not familiar with other platforms but in OPNsense (at least) DNAT allows to translate both the destination host and/or the destination port. Both functions in one.
Quote from: tessus on January 27, 2026, 09:00:22 AMI don't think I have NAT association rules on my interfaces. Afaik I always created rules manually.
Is there a way to find out?
In versions prior to 26.1, you can check the NAT rule itself. IIRC, there were three options. I don't remember their exact names but essentially one was to do nothing, one was to create an auto pass (without an associated rule), and one was to create an associated rule on the interface.
Quote from: OPNenthu on January 27, 2026, 09:10:52 AMI'm not familiar with other platforms but in OPNsense (at least) DNAT allows to translate both the destination host and/or the destination port. Both functions in one.
Well, port forwarding is a subset of DNAT functionality (1:1 static translation w/o hairpinning plus port translation), maybe that's why it is renamed and then there will be additional or less options in the interface. I guess I will see. ;-)
Quote from: OPNenthu on January 27, 2026, 09:10:52 AMn versions prior to 26.1, you can check the NAT rule itself. IIRC, there were three options. I don't remember their exact names but essentially one was to do nothing, one was to create an auto pass (without an associated rule), and one was to create an associated rule on the interface
Awesome, thanks. I checked my rules and all have the
Filter rule association set to
None. So I should be good.
This thread has proven very helpful in understanding the new UI and its implications. Thanks to all the contributors! I haven't upgraded to 26.1 yet but have found the automation filters inspect UI pleasant to use and insightful.
My current set up has some single interface floating rules (mostly WAN). Some are artifacts of a migration from pfsense/pfblocker where the auto-generated rules were floating with direction 'both'. Considering those, alongside my other existing rules, there is actually no need (either for priority or for bi-directional reasons) for them to be defined as floating. So I have now moved all single interface floating rules to their respective interfaces and ordered things appropriately.
For me, the only headache might be maintaining filter rules for port-forwards. I use these on internal interfaces as well as WAN. I'd considered changing my port forwards to pass. However AIUI from posts elsewhere on the forum, the new system may impact the way some have used the 'pass' option on port forwards. Or am I misunderstanding?
You are misunderstanding: Floating rules were never processed before a port forward with "PASS". We only assumed that this was the case - it never was.
Quote from: meyergru on January 27, 2026, 10:22:50 AMYou are misunderstanding: Floating rules were never processed before a port forward with "PASS". We only assumed that this was the case - it never was.
If you look at the rule processing order documentation:
https://docs.opnsense.org/manual/firewall.html#processing-order
there is this large warning:
QuoteNAT rules are always processed before filter rules! So for example, if you define a NAT : Destination NAT (Port Forwarding) rules without a associated rule, i.e. Filter rule association set to Pass, this has the consequence, that no other rules will apply!
But also at the top there is the general order with the "boxes":
System defined --> Floating --> Interface Groups --> Interfaces
@meyergru and myself based on this both assumed that the "NAT before filtering" applies inside each box, respectively. So:
Floating NAT --> Floating Filtering --> Interface Groups NAT --> Interface Groups Filtering --> ...
Unfortunately we were equally both mistaken. NAT rules are *globally* applied first and always were. That leaves the question in which situations the "Pass" mechanism might be useful at all.
Kind regards,
Patrick
I have switched those "PASS" settings out for associated rules. However, those will get disassociated during upgrade to 26.1. You will have to take care of their management manually further on (as indicated by the "MANUAL" setting in the NAT rule).
In regards of rule process order (other than in the docs its correct) there is as well a packer flow process diagram made by @Cedrik some time ago, but kept updated.
https://forum.opnsense.org/index.php?topic=36326.0
This helps if you need to visualize how a packet will be processed across the pipelines. And from what I have seen and tested its correct.
@Cedrik
Maybe it would be great to have this in the official docs as well, cause this is extremely helpful for understanding and T-shooting.
Regards,
S.
The packet diagram is a bit lossy, there are quite a few more invariants that would create a huge flow diagram. Not sure I can build that correctly in the docs, and a picture wouldn't be easy maintainable.
So for now I keep it in that forum post.
I thought reStructured supported flow diagrams (but maybe I am making things up).
It is bit lousy yes, but it as well says a lot.
Anyway got ya. But its something that sooner or later would be worth a while.
Regards,
S.
Thanks all for the pass clarification. That makes it clear and makes sense. I have been aware of the packet processing order but somehow got misled ;-)
If the source/destination criteria on the forwarding rule are sufficiently selective, then I suppose a 'pass' action is sufficient. In fact it now occurs to me that some of my associated rules may be redundant.
Quote from: keeka on January 27, 2026, 11:53:30 AMIf the source/destination criteria on the forwarding rule are sufficiently selective, then I suppose a 'pass' action is sufficient.
True, but there is a problem with it: Imagine you have some blocking rules. You can use them in the floating rules, but just for WAN. You can enable or disable each of them selectively and that combination works work all port forwarding and allow rules after that alike. I mean something like this:
2026-01-27 12_15_57-Floating _ Rules _ Firewall _ OPNsense.mgsoft — Mozilla Firefox.png
If you want to mimic that with separate source criteria for each port forwarding rule, you look at a lot of work. Also, some of the block rules cannot be combined in a single network group alias, because of their type (say, __qfeeds_malware_ip).
Therefore, you probably still need separate rules (I do) to be able to shift their priorities, but you must take care of them manually after 26.1, because they become disassociated from their respective NAT rules.
Quote from: Patrick M. Hausen on January 27, 2026, 10:30:34 AMThat leaves the question in which situations the "Pass" mechanism might be useful at all.
AISI pass may be useful when:
- source/destination criteria in the port forward rule will serve all needed filtering criteria.
- no egress filtering is needed.
- no tagging, policy routing, traffic shaping (or something else?) is needed.
Would that be about right?
@meyergru I have a couple of portforwards on the WAN where the pass action won't be satisfactory. However I also have some on the WAN and almost all those on the local interfaces, where I think it will be appropriate. Just that it never occurred to me use that option in the past and so I have, what I now think, may be redundant filtering.
EDIT Having said that, it may get confusing in the future having the cause of passed traffic not visible in the filter list. I'm sure that would catch me out especially with my memory these days. In fact I think this is a good enough reason for me not to use Pass and instead explicitly define filter rules to pass port forwards.
Quote from: keeka on January 27, 2026, 12:27:15 PM- source/destination criteria in the port forward rule will serve as the filtering criteria.
Sure. Only thing is this is getting increasingly difficult in a single rule - regardless of NAT or filtering. Picture on WAN:
block all known bad actors: free block lists, Q-Feeds, Crowdsec, ...
permit inbound from GeoIP Europe but block everyone else
In a single rule you can have either source invert or not. You cannot combine in this fashion e.g.
allow from (not (bad actors)) and (GeoIP Europe)
You can of course
block from (bad actors) and (GeoIP except Europe)
only that the second variant generates an alias with orders of magnitude more entries.
So for me essentially "pass" is dead and I need two rules, one block, one allow.
I take your point. If on the other hand you have only known ASNs or subnets that you wish to allow, Pass would seem OK. But I am now feeling cautious about mixing Pass forward rules with those requiring explicit filter rules. It starts to feel messy.
Quote from: tessus on January 27, 2026, 09:00:22 AMThis is a bit strange though. Port forwarding is not the same as DNAT.
It's true that DNAT is often used in combination with port forwarding, but that doesn't mean that port forwarding rules should be renamed to DNAT. Hmm, this is rather concerning.
Quote from: OPNenthu on January 27, 2026, 09:10:52 AMI'm not familiar with other platforms but in OPNsense (at least) DNAT allows to translate both the destination host and/or the destination port.
Both functions in one.
It's better for stuff like this : https://forum.opnsense.org/index.php?topic=9245.0
Because having to "Port Forward" for something like that was indeed a bit weird...
But then again indeed :
It might not be as straight forward as some might like it to be when you are just looking for something as simple as a Port Forward for some application ?!
Oh well...
"You have to break a few eggs to make an omelette!" ;)
The migration assistant produced one route in the CSV that the import complained about, because the interface does not exist:
660d1363-f0e0-4dac-985c-b963552f8e69,1,keep,,211,pass,1,0,enc0,in,inet,any,,,,,0,0,0,0,0,,,,,,,,,,,,,,,,,,,,,,,"allow all IPv4",0,any,,0,any,
Which is correct - I ran an IPsec tunnel once, but replaced it with WireGuard years ago. It's trivial to delete the rule from the CSV, then import, but how am I going to delete "all legacy rules", anyway? Do I really need to click on every single interface and remove every single rule? And how do I get at that enc0 rule?
If I have to edit the XML to remove that enc0 rule, anyway, I'm possibly better off using vi to remove everyting ;-)
What do you think/recommend?
Kind regards,
Patrick
EDIT: ah ... the "Remove all legacy rules" in the assistant is functional, not only documentation. OK, trying this first, then I can check the XML for leftovers.
EDIT^2: Looks good, no legacy rules.
EDIT^3: The migration turns an '&' in a rule description - a 7 bit ASCII character - into '&' Eager HTML escape.
Quote from: nero355 on January 27, 2026, 04:48:30 PMBecause having to "Port Forward" for something like that was indeed a bit weird...
Yep, I've thought about it for a while and I think the renaming makes sense in this case. The Port Forwarding UI in OPNsense always allowed to do things that are actually DNAT, so all is good.
My "outcry" came from the fact that I actually only used port forwarding rules, thus my previous opinion about the renaming of this item was wrong.