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
You are aware of the implications of doing that w/r to firewall rule priorities, especially when you use NAT?
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.
Quote from: meyergru on September 25, 2025, 12:46:29 PMYou 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?
Quote from: Monviech (Cedrik) on September 25, 2025, 12:54:04 PMin 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.
It is not preferred yet, its a work in progress and a roadmap item. But it works pretty well already. :)
https://opnsense.org/roadmap/
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.
Quote from: Monviech (Cedrik) on September 25, 2025, 01:27:03 PMhttps://opnsense.org/roadmap/
One of the most well-arranged roadmaps I've seen so far - great job!
Quote from: Patrick M. Hausen on September 25, 2025, 01:29:37 PMNAT 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.
Quote from: Patrick M. Hausen on September 25, 2025, 01:29:37 PMSo 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)?
Quote from: narubby_star on September 25, 2025, 05:40:53 PMIt'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.
Quote from: meyergru on September 25, 2025, 07:50:23 PMThey 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
Correct, Patrick.
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 (https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html) - specifically, do I still need floating rules for tag/match or to block outgoing connections e.g. on WAN/SNAT (https://docs.netgate.com/pfsense/en/latest/nat/process-order.html#firewall-nat-processing-order-example)? 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.
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.
Quote from: meyergru on September 26, 2025, 08:42:05 AMYou 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 (https://docs.netgate.com/pfsense/en/latest/nat/process-order.html#firewall-nat-processing-order-example) 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.
I never worked with tags, so IDK...
Quote from: narubby_star on September 26, 2025, 10:59:44 AMDo 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.
You're welcome, let me know, if you found something out!
I will also test this (+ WAN restricting via interface OUT rule) later on, after having re-organized some of my other setup.
Good convo here.
I understood the point that NAT rules with filter rule association set to "Pass" will override interface-level blocks. But I'm confused about why floating rule blocks would still work.
As Patrick said:
Quote from: Patrick M. Hausen on September 25, 2025, 08:06:23 PMFloating > Groups > Interface
But at every single stage:
NAT > filter
If NAT always comes before Floating, then wouldn't the same issue be there as with interface rules?
Sorry for rehashing. I think it's important to understand this. Thanks!
NAT on an interface comes before filter on an interface. Floating comes before interface. So floating filter - interface NAT - interface filter ...
Quote from: Patrick M. Hausen on October 01, 2025, 08:51:16 AMSo floating filter - interface NAT - interface filter ...
I'm putting that on a sticky note above my monitor!
Perfect, thanks!