Messages

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.

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

[security implications]

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?

[Quotes from the docs]

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