Convert between floating and interface (group) rules?

[narubby_star]

Hi,
I am in the process of migrating 30+ floating rules back to interface rules - they only have one interface assigned.
Cloning on a floating rule doesn't  allow to convert this rule back to an interface (group) rule.
So how might I do this efficiently without manual, error-prone re-creation of rules?
Not interesting to me, but probably the other way round interface rule -> floating rule would also be a good idea to enhance compatibility.

Kind regards

[meyergru]

You are aware of the implications of doing that w/r to firewall rule priorities, especially when you use NAT?

[Monviech (Cedrik)]

Just as hint

in the new Firewall - Automation - Filter all of this works already as Floating is determined differently.

So its unlikely cloning rules in the legacy component between floatinh and interfaces will be added.

[narubby_star]

You are aware of the implications of doing that w/r to firewall rule priorities, especially when you use NAT?

To my knowledge System > Floating > Interface group > Interface rules.
So afaik I should be able to convert floating to an interface rules (all first match), if
- rule is placed at the top of interface-specific table, to have higher priority than existing rules
- there is no interfering interface group rule
But your comment about NAT made me curious. Can you clarify?

in the new Firewall - Automation - Filter all of this works already as Floating is determined differently.

Oh, thanks. Honestly I totally missed this new feature.
If I got you right, this is the new preferred rule processing component, side-by-side to legacy rules  - will look into it.

[Monviech (Cedrik)]

It is not preferred yet, its a work in progress and a roadmap item. But it works pretty well already. :)

https://opnsense.org/roadmap/

[Patrick M. Hausen]

NAT is always processed before filtering. So if you have a NAT rule on e.g. WAN for inbound access of $some_service and you do not use a separate associated filter rule, but instead set the rule association to "Pass" - this will take precedence over any filtering you might have defined for that interface.

So e.g. if you use global blocklists like FIREHOL and friends, but still want easy inbound NAT, best place those blocklists in the floating category and not on the interface.

[narubby_star]

https://opnsense.org/roadmap/

One of the most well-arranged roadmaps I've seen so far - great job!

NAT is always processed before filtering.

Thanks for your answer. I should write that on a paper - netfilter/iptables/nftables first does dnat, then filtering/routing, then snat. So coming from that tool, this order is slightly confusing.

So e.g. if you use global blocklists like FIREHOL and friends, but still want easy inbound NAT, best place those blocklists in the floating category and not on the interface.

Yeah, it definitely makes sense to add global rules to Floating. But you also could define an interface group - or firewall group, as called in the GUI - for global rules and probably have more flexibility, as you can define multiple of those.
(Btw: This is why I have the feeling, floating rules seem redundant from user-facing perspective)

It's still my impression I can use interface and floating rules interchangeably. Or doe floating rules change anything fundamentally regarding NAT (like processing order)?

[meyergru]

It's still my impression I can use interface and floating rules interchangeably. Or doe floating rules change anything fundamentally regarding NAT (like processing order)?

Yes, they do - that is why I hinted at this and Patrick explained it. To put it short: If you have port forwards (aka SNAT) and try to use block rules in the WAN interface rules, they will not block. They will only block if you put them in floating rules - but also, only if you use "associated firewall rules", and not "pass" there.

The only other way that this could be made to work was with negated source ranges in the NAT rules, but that gets ugly fast once you have multiple ranges.

So, to answer my initial question: You were not aware. Now you have been warned about it.

With the new means @Monviech explained, you can do this even more elegantly.

[Patrick M. Hausen]

They will only block if you put them in floating rules - but also, only if you use "associated firewall rules", and not "pass" there.

Not quite sure about your implied hierarchy of these rules. You weren't very explicit.

If you have a NAT port forward with "Pass" on an interface you cannot block it with an interface rule. But you can block it with a floating rule.

Floating > Groups > Interface

But at every single stage:

NAT > filter

HTH,
Patrick

[meyergru]

Correct, Patrick.

[narubby_star]

Hence, if migrating floating to interface-specific rules, one consideration is to check, whether you still need its higher priority with regards to DNAT - understood.

What about other potential uses - specifically, do I still need floating rules for tag/match or to block outgoing connections e.g. on WAN/SNAT? I only found these docs for pfsense, not sure if that's still a thing for OPNsense as a fork.

In other words: Can I equally create a WAN interface rule with OUT direction for this purpose? Note that pfSense originally solely had IN direction for interface rules, so there naturally was need to create special type floating rules for outbound connections. According to OPNsense interface rule creation form, OUT for interface can be chosen.

[meyergru]

Not with the same effect, because at this point, the packets that you want blocked from outside have already entered the firewall and reached the destination if SNAT rules exist. You could only block outbound connections with that, which is usually not what you want.

For some blocklists, you may want to block both incoming and outgoing connections, then, a "in" floating rule for both LAN and WAN might be the best choice.

As with pfSense, "in" rules are the most preferable choice.

[narubby_star]

You could only block outbound connections with that, which is usually not what you want.

Yeah, I see. But sometimes there is still need for blocking of OUT traffic on WAN. An example is a VPN "killswitch" via NO_WAN_EGRESS tag or similar, which prevents data leaks as last barrier. If I am not mistaken, the guide even is in this forum. Two remaining questions:

1. Do I need a floating rule for this tagging case, or is it sufficient to use a plain OUT interface rule on WAN with the same rule content: block on "Match local tag = NO_WAN_EGRESS"?

2. Does an interface-specific rule with OUT direction on WAN also see the Post-SNAT IP address/public IP, like floating rules? Or is it still the internal address for rule matches? If former, then both floating and interface rule should be interchangeable here. Looking at pfSense docs that is still not quite clear to me (happily take an updated one from OPNsense, if there is one!). Described LAN-to-WAN traffic flow in their docs seem to only include outbound floating rules on WAN, no OUT WAN interface rules at all.

[meyergru]

I never worked with tags, so IDK...

[keeka]

Do I need a floating rule for this tagging case, or is it sufficient to use a plain OUT interface rule on WAN with the same rule content: block on "Match local tag = NO_WAN_EGRESS"?

I have a similar match-tag and drop rule defined as a floating rule. I tested it ages ago, and it worked. It does seem a foolproof approach to preventing VPN leaks and it is independent of any NAT addressing.
Looking at my floating rules, few if any of them would seem vulnerable to unintended outcome due to a misunderstanding on my part regarding when NAT occurs WRT rules.
I was not familiar with the option to define out rules on interface prior to coming to opnsense. Therefore, I've stuck with defining them in floating only.
I think I will revisit floating rules having come across this thread.
Thanks.