Disable force gateway setting

[mooh]

There this setting under Firewall -> Advanced -> Disable force gateway that's off by default, i.e. firewall rules are created that superseed the routing table. I recently wasted a lot of time because of this setting, trying to understand why I had what looked like a routing problem. Can anyone please explain what this automatic policy routing is good for?

[narubby_star]

I also would like to know more about this setting. To recap, it can be found under

Code Select Expand

Firewall -> Settings -> Advanced -> Multi-WAN -> Disable force gateway

Quotes from the docs

https://docs.opnsense.org/manual/firewall.html#direction

Traffic leaving the firewall is accepted by default (using a non-quick rule), when **Disable force gateway** in `Firewall ‣ Settings ‣ Advanced` is not checked, the connected gateway would be enforced as well.

https://docs.opnsense.org/manual/firewall_settings.html#disable-force-gateway

Disable force gateway

By default OPNsense enforces a gateway on "Wan" type interfaces (those with a gateway attached to it), although the default usually is the desired behaviour, it does influence the routing decisions made by the system (local traffic bound to an address will use the associated gateway).

**Note**
This rule is responsible for the `let out anything from firewall host itself (force gw)` rule visible in the floating section, it forces a route to (`route-to`) on all non local traffic for the "Wan" type interface.

Example
WAN interface with IP 192.168.1.2.
WAN has DHCP-configured gateway 192.168.1.1 - i.e. there is an entry in System -> Gateways -> Configuration.
"Disable force gateway" is *disabled* (default value).
Use case: Try to re-route certain packets on WAN to a WireGuard gateway (^1) based on destination IP, via policy-based routing or static routes.

My observations so far
a) Manually routing to WireGuard gateway with static routes does work.

b) Policy-based routing to different gateway does *not* work
- Still "Live view" shows this rule as matched for a packet.
- I tried to start "Packet Capture", but could not see any traffic on the WAN interface for packets.
- What seems confusing: Rule `let out anything from firewall host itself (force gw)` is marked as "last match" (see ^2 and attachment). But "last match" rules can be overwritten by "first match" rules, so it effectively would *not* enforce the gateway, right?

Questions
1. Is my understanding correct, that "Disable force gateway" is meant to always enforce and restrict interface to use the associated gateway, if existent (here IF 192.168.1.2 -> GW 192.168.1.1)?
2. Static routes still seem to work though?
3. Given  "Disable force gateway" is *enabled*: What does this option change in OPNsense configuration? I'd be interested to have this option enabled only for a specific interface, while keeping everything else same. So there is a bit of customization need.

I would highly appreciate, if someone more knowledgeable could provide some clarification (Sorry for the wall of text).

---

Related, old post: https://forum.opnsense.org/index.php?topic=6242.0

^1: To be more accurate, this is a Gateway group, not a single gateway. But did not want to make this more complicate here.
^2: See Firewall -> Rules -> WAN -> Expand "Automatically generated rules".

[narubby_star]

I'll try to provide an answer myself (please correct, if there's something wrong).

1. Does unchecked value (default) for "Disable force gateway" always enforce WAN-type interface to use its associated gateway?
Yes. This setting creates a policy-based, auto-generated rule for each WAN-type interface (like let's say `WAN`), which enforces redirection to `WAN` and effectively overrides other policy-based rules and omits static routes.

2. Static routes still seem to work though?
No. But my case was different: A local process created packets, so static routing table was consulted first, before this packet was forwarded to WAN interface. And "Disable force gateway" only kicks in at the point of packet being associated with a WAN-type interface.

3. Given "Disable force gateway" is *enabled*: What does this option change in OPNsense configuration?
It only removes the auto-generated policy rule, everything else should be kept same and system should work as usual (could not test myself yet, as no testing system). A WAN-type interface now can have (multiple) gateways different from its configured gateway, and system routing table and other policy-based rules are respected again for routing decisions.

4. Rule `let out anything from firewall host itself (force gw)` is marked as "last match". But "last match" rules can be overwritten by "first match" rules, so it effectively would *not* enforce the gateway?
My bad. "Last match" rules are evaluated per section (system-defined/auto-generated, floating, interface group, interface). `let out anything from firewall host itself (force gw)` resides in the auto-generated section, which has highest priority. If there is no "first match" in this section, and above rule is last, it will always matched first.

---

That been said:
How do you assess security implications of enabling "Disable force gateway" setting?

[EricPerl]

#4: I don't think so.
Otherwise, the default deny/state violation rule would override all custom rules. 😉

This said, I agree that the force GW might be one of the most obscure rules.
In particular, it's after another last match rule that's more generic thus should fire first. I suspect a non-visible element.
The source parameter is fairly unique too and I'm not positive on its interpretation.

[Patrick M. Hausen]

Force gateway and reply-to are the two "features" I like the least. Not so much the fact that they exist but the fact that they default to active.

A firewall is first and foremost a router with filtering capabilities on top. It runs on a single IP stack with locally connected interfaces and a routing table. And that should be all that is taken into consideration by default when forwarding packets.

Policy routing is of course a nice and frequently necessary feature but there should be no policies active on a newly installed system, IMHO.

OPNsense delivers a (or two) big POLA violations in the default setup. Specifically to people who are experienced in networking and familiar with how routers in general work.

After almost 3 decades of managing an ISP including an OSPF managed backbone and BGP with full tables and everything I encountered the very first project where I ever needed policy routing a couple of weeks ago. Hosting environment at Hetzner and they insist we use a separate vSwitch for every additional IPv4 prefix we order. So suddenly we are multi WAN and need reply-to. OK. But as a default - just no.

Count the posts of people setting up OPNsense in a lab environment with Ethernet based broadcast networks for both WAN and LAN and you get what I mean.

Just default both to off and revert the UI so a ticked checkbox means "special feature only necessary in rare situations explicitly enabled".

My 2ct.
Patrick

[narubby_star]

#4: I don't think so.
Otherwise, the default deny/state violation rule would override all custom rules. 😉

First, thanks for the correction.
Docs in https://docs.opnsense.org/manual/firewall.html#processing-order are not too clear on this topic.
In desperation I also asked an AI, and it answered with " 'last match' means the last matched rule within the specific section (such as floating or interface) of the firewall rules being evaluated."  Apparently this wasn't a good idea 😉.

This said, I agree that the force GW might be one of the most obscure rules.
In particular, it's after another last match rule that's more generic thus should fire first. I suspect a non-visible element.

What does not make sense to me is:
Since system-defined rule induced by "Disable force gateway" is last match, and given last match is evaluated globally and not per section, it can't really enforce the gateway, right?
I then might just create a first (or even last) match rule in Floating or Interface section, and it should take higher priority.

A firewall is first and foremost a router with filtering capabilities on top. It runs on a single IP stack with locally connected interfaces and a routing table. And that should be all that is taken into consideration by default when forwarding packets.

[...]

Just default both to off and revert the UI so a ticked checkbox means "special feature only necessary in rare situations explicitly enabled".

Yeah, I am also inclined to *enable* the "Disable forced gateway" setting (what a boolean nightmare term lol).
So from security perspective, there should be no harm to do so, given you did not set up policy-based rules, that redirect to unintended other gateways?

[Patrick M. Hausen]

So from security perspective, there should be no harm to do so,

Of course not - this is not a security feature.

[Seimus]

What does not make sense to me is:
Since system-defined rule induced by "Disable force gateway" is last match, and given last match is evaluated globally and not per section, it can't really enforce the gateway, right?
I then might just create a first (or even last) match rule in Floating or Interface section, and it should take higher priority.

Its last match so will be applied only if other rule is not matching, and its global cause its configured as Floating on "all interfaces".

Keep in mind the order of Rules:
Floating > Group > Interface

Basically if you have rules on all 3 of these. From Interface rule view point, its created as a single list starting with rules from Floating at the top followed by Group rules Followed by Interface rules. In case a Floating rule is "last match" If any rule from this combined list is hit, the "last match rule" will not be preferred.

In regards of PBR,
PBR is not a security feature, its a routing feature. Its main purpose is basically to manipulate routing decisions without affecting the routing table. This way you can adjust and manipulate forwarding of a packet on a local level without affecting the network routing controlled by routing protocols.

Regards,
S.

[narubby_star]

Basically if you have rules on all 3 of these. From Interface rule view point, its created as a single list starting with rules from Floating at the top followed by Group rules Followed by Interface rules. In case a Floating rule is "last match" If any rule from this combined list is hit, the "last match rule" will not be preferred.

Thanks.
1. And system-defined/auto-generated rules are on the very top, right? This is the section, where rule related to "Disable force gateway" is in.
2. I guess, by "any rule from this combined list is hit" you are referring to  "first match" rules. I was wondering about priority in case of multiple "last match" rules - and  if I am not mistaken, here the rule located more at bottom of this combined list wins (given no "first match" rule can be applied).
3. So basically, there is an effective rule list built from System-defined > Floating > Group > Interface. And scope of system-generated + floating rules can further be limited to one or more interfaces.

(just curious about internal functioning of OPNsense, don't want to be nit-picky)

PBR is not a security feature, its a routing feature.

But what is the purpose of "Disable force gateway" then - firewall admins are responsible for proper setup and maintenance of routing table/firewall rules anyway.
Can it be seen as some kind of additional aid against accidental configuration?
At least from what I've learned about rule organization and precedence here, it cannot accomplish its purpose of enforcing used gateway for WAN-type interfaces.

[Patrick M. Hausen]

But what is the purpose of "Disable force gateway" then

No idea. No firewall I used in the almost three decades prior to switching to OPNsense did this. I mean policy routing by default. The "Disable" setting exists to turn OPNsense into a normal router/firewall from my point of view.

Then again I also never had multiple gateways. I managed data centres with redundant BGP uplinks and the firewalls were behind the redundant routers which did all the heavy lifting.

[EricPerl]

The auto-generated rules are mostly floating rules (you can actually check the list).
At least one exception are the DHCP rules (if the FW is configured as DHCP server for that interface).
These rules are inserted in the middle of the auto-generated floating rules...
The end result is that auto-generated rules are first, then custom rules in the floating > group > interface order.

The effective result is pretty clear for first match rules.

As mentioned previously, it's less obvious for last match rules.
The system itself is configured with 2 overlapping out last match rules, and the top one in the list is more generic.
So, I just did a little test, adding a last match rule blocking ICMP to 8.8.8.8. And it fired.
This tells me that last match rules are evaluated bottom to top. No hidden "priority".

Anyway, beyond the fact that force GW is a blind spot for me (I don't feel bad if Patrick himself doesn't get it either), I have not suffered ill effects from it.
I can't say the same with reply-to (on my lab OPN deployed within my main network).
I second disabling this by default on clean installs and adding it to the multi-WAN guide (and possibly other use cases).