New rule system

[Monviech (Cedrik)]

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.

[tessus]

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?

[OPNenthu]

@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.

[OPNenthu]

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.

[tessus]

Thanks @OPNenthu

nothing 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.

[OPNenthu]

@tessus sorry, pay attention to this note in the latest release notes also:

o 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.

[tessus]

This 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.

If 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?

[OPNenthu]

Port 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.

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?

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.

[tessus]

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.

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. ;-)

n 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.

[keeka]

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?

[meyergru]

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.

[Patrick M. Hausen]

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.

If you look at the rule processing order documentation:

https://docs.opnsense.org/manual/firewall.html#processing-order

there is this large warning:

NAT 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

[meyergru]

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).