[26.1] New rules UI: ability to have a floating rule on a single interface

[dstapa]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

The legacy rules UI allows for Floating rules on a single, specific interface. For example we can set a Floating rule just on WAN. This is done even in the OPNsense docs (example: https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html#step-11-add-a-kill-switch-optional).

It's also only possible to override a Floating rule with another Floating rule of higher priority, but we may want the override to apply on a single, specific interface.

The new rules UI (renamed from "Automation") in 26.1 doesn't allow this currently. Floating rules have to be either on multiple interfaces or on any interface (none specified), but not on a single interface.

Describe the solution you like

If possible with the new MVC rules system, add back the ability to specify a Floating rule for a single interface.

Describe alternatives you considered

Work-arounds have been discussed in the forum, but involve change in workflow or rule design (or faking the floating rules):

https://forum.opnsense.org/index.php?topic=50496.msg257894#msg257894
https://forum.opnsense.org/index.php?topic=50496.msg257895#msg257895

[AdSchellevis]

We discussed this internally, but at the moment we are not planning to add more toggles, the "floating" concept has been flawed from the beginning, adding more bells and whistles is probably not going to improve the situation.

It would be better to change the example documentation as the "floating" rule would do the same when just being installed as first outbound rule on the wan interface.

[dstapa]

Thanks @AdSchellevis .

In that case shall I close this? The workarounds are clear, if needed.

the "floating" concept has been flawed from the beginning

When you have time (no rush- I know you're preparing a release) could you expand on what the flaw is? If something's already been written about it please point me to where to find it. Would be good to understand.

[AdSchellevis]

@dstapa I don't mind much keeping it open for a while in case someone can explain a use-case that currently isn't possible to implement (which I don't expect). The floating "concept" only makes sense from an ordering perspective, which is also the way its implemented now (our documentation is updated to explain the rationale between option https://docs.opnsense.org/manual/firewall.html#processing-order).

[fichtner]

Floating should have been normal rules, but the per-interface rules GUI was probably there first so authors were looking for ways to not break interface rules. Much of this goes back to the old interface not being able to sort rules interface-agnostic and the floating rules fill that gap while keeping the other situation in place, also introduced out rules and other gimmicks there but with no clear separation concept.

To me "floating" would mean no interface selected, which would have been easy, but as I said the GUI was just copied from interface-bound rules and made more generic. Now there were two problems. Group rules added a third problem and now we have 3 implicit priorities because rule order wasn't able to be specified. You can just reorder the whole sequence in the new GUI.

Cheers,
Franco

[dstapa]

Thank you both for taking the time, especially right now.

I'll take a shot but this is not my example (I came up with it using an AI assistant). I think I would learn something even if it's wrong or contrived...

Assumption: Floating rules on WAN have the special property that they can filter egress traffic before NAT.

The scenario is we have two ISPs on interfaces WAN1 & WAN2 respectively, a LAN, and a VPN (e.g. site-to-site). We want any traffic leaving WAN1 with port 587 (SMTP) to get blocked or routed to a blackhole gateway based on the packet parameters, but only when it exits WAN1. The same traffic should be allowed to egress WAN2, VPN, and allowed internally. The business case is that this is a provider-specific compliance rule because ISP 1 forbids outbound SMTP except from approved hosts.

A WAN interface rule is too late and the source IP has already been rewritten, so cannot filter it.

A LAN interface rule is too early and doesn't know which egress interface will be used as the routing decision hasn't yet taken place.

A multi-interface Floating rule risks blocking other interfaces and return paths.

The solution is a Floating rule on WAN1 (only) with direction "out."

---

The AI gave me a number of work-arounds to this, but they were all added complexity and trade-offs in some way (e.g. mail proxy, multiple firewalls, policy routing = loses automatic failover, etc..)

[dstapa]

Replying to myself...

Upon further reading, it seems the assumption about the Floating behavior above is false.

[2tqkfqv2yy-cmyk]

Just as a FYI, I saw this as a potential issue after reading about the changes when I was manually migrating my rules from floating rules to the 25.7 Automation rules prior to upgrading. Although manual migration isnt a required step, I ended up doing this because I saw it as an opportunity to clean up the FW rules I had prior to migration and make sure there is no need for migrating rules since they would just be moved over.

My personal work-around was to move all floating rules to group rules and in one case I had to create a group with a single interface (which can still be done in 26.1) and apply the rules previously assigned to a single interface there. This ended up being a big win personally since it made rule inspection much better in the end.

Right now I am using floating rules for rules applying to ALL interfaces, general networking rules in Group rules for rules applying to logical groups of interfaces (1 or more) and individual catch-all rules on the interfaces themselves.

[dstapa]

Thanks @2tqkfqv2yy-cmyk for your thoughts on this.

I had some more time to think and what I realize is that my "concern" can possibly be ended with the answer to this question:

Are there any special features or powers of Floating rules that no other rules can do, and if so, would we ever have a need to put such a rule on a single interface (or group)?

If the answer is 'no' then I think there's no gap here with the new rules system.

[muchachagrande]

In my case, I did the migration just after updating to 26.1.1 and I had one floating rule to block unwanted IPs. Let say a black list.
That floating rule was only on WAN and for that reason it converted to an interface rule that left the rule on a different position on the filtering order.
Before the migration, it was the first rule processed and after migration it started to be the first of the interface rules. But interface rules seems to apply after floating ones.
To workaround this I added a second interface to the rule to convert it to "floating" and it was then that the rule was again the first rule of all.
The second interface could be anyone for this use case because I'm filtering source IP addresses that could connect only from Internet, so I used LAN for the test, but a more elegant way is to create a loopback interface exclusively for this purpose.
Honestly, I don't think that is so important to have the option of floating rules with only one interface just for this use case, but may be there are other use cases that worth it.

[bensmithurst]

Jumping on here for some general feedback on the floating rule changes. My use case for single interface floating rules was I had multi-interface rules to allow traffic to a given port to certain destinations and then disallow all other traffic to that port. I then needed single interface exceptions where some devices could bypass the block rule.
e.g. allow DNS to this firewall, then some per-host exceptions on single interface rules, then disallow all other DNS

I can easily workaround this with a dummy extra interface on the exception rules so I have no strong feelings about an explicit floating flag.

However - at the risk of going off topic for this issue, but as I say it seems a useful place to gather feedback - more broadly I wonder if the floating concept needs to exist any more, and I see some hints towards that idea above.

In the new rules UI we now have the 'all rules' view. Could the floating rule concept just be abolished, along with the restriction that you cannot put interface rules before floating rules? We could just order rules as needed within that all rules view whether they are single interface/group/multi interface rules? Obviously the migration tooling would put old floating rules before old other rules to preserve behaviour.

In such a world I also think that selecting an interface on the rules pages should show all rules which include that interface (i.e. floating/group rules) rather than just showing rules which are specific to that interface, but I could well be alone in that view. Would just be nice to get a 'simple' view of the rules applying to a certain interface. Such a view could still retain the visual indication of whether each rule is interface/group/floating but without the ordering restriction. I know we can use 'inspect' to kind of do that, but that reveals the autogenerated rules too, which I for one rarely need to look at, they 'just work' 99.99% of the time.

Overall though I think the concept of a single set of rules, which you can optionally filter to rules applying to a single interface, and then order freely in either view, would be great, and should reduce the confusion about which order rules are applied in.

Just some ideas anyway, maybe they're sensible, maybe they're not for reasons I haven't considered.

I should say on the whole having migrated to the new rules, I like it. Took a bit of getting used to but I've disabled all my old rules now, and I'm getting the hang of the new system. Looking forward to more improvements as 26.1 develops.

[somova]

Before upgrading to version 26.x, I had to extend floating rules with a single interface by adding a dummy interface to ensure the firewall's behavior remained consistent after the upgrade. At least with regard to the old rule scheme (Interfaces < Groups < Floating), I'm reliant on floating rules with a single interface.

I've installed a kill switch on the WAN interface as the first floating rule, which blocks all outgoing private network traffic according to RFC 1918. This is a security measure in case private network traffic takes the default route to the WAN in the event of a failure. Further floating rules with different interface combinations are following the kill switch rule.

The kill switch rule is followed by other floating rules. Example:

• Rule 1 (WAN Kill Switch): Interface A
• Rule 2: Interfaces B, C
• Rule 3: Interfaces C, D
• Rule 4: Interfaces B, C, E

With the removal of floating rules with only a single interface, I would have to move each of the above rules into its own interface group to maintain the order of all rules. This situation unnecessarily complicates firewall management. Therefore, in my opinion, it makes sense to retain floating rules with a single interface.

However, since all firewall rules ultimately end up in a common list (see pfctl), I can easily imagine that this discussion will be resolved in the future with the new rule schema. I would not preemptively disable floating rules with a single interface, however, as I currently see no urgent need for this.

[Greelan]

It would be better to change the example documentation as the "floating" rule would do the same when just being installed as first outbound rule on the wan interface.

Which is exactly what the migration assistant did for that "kill switch" floating rule for me xD

[g1t-out]

My use case is similar to @somova's. My rules are like:

• Allow from Interface B to Network A for traffic on port 123

• Block Traffic from Interface B, C, D, E to Network A

The problem is the second rule ends up being a float rule and the new interface won't let me create a float rule for the first rule, so this will never work. If I keep using OpnSense, I'll have to move away from float rules completely.

This seems like a basic thing. Most enterprise grade firewalls do something like this. In addition, I know for a fact, this can be done with nftables under Linux. Why can't we do this in the UI for OpnSense?

I'm open to hearing different ideas on how to create this rule, but I don't like the idea of having dummy interfaces to force the first rule through.

[fichtner]

Pseudo floating interface rule to top of the interface‘s rule. Floating isn’t needed. This is simple ordering.

Cheers,
Franco