Wireguard Selective Routing - Why Step 9?

Started by xternal`, January 26, 2023, 08:58:20 AM

Previous topic - Next topic
January 26, 2023, 08:58:20 AM Last Edit: January 26, 2023, 09:08:21 AM by xternal`
Hi,
I have setup my wireguard to connect to mullvad and route all LAN traffic through it.
My original setup was a little different to the guide for selective routing to an external vpn in the opnsense wiki.

As it was the only wireguard connection I didn't have 'disable routes' enabled. This way I just had:
1. an interface assigned to wg0
2. A gateway for the interface GWwg0
3. A Nat outbound rule for wireguard interface set to take a LAN traffic out GWwg0

This worked great as i didn't have to set a specific outbound firewall rule for the LAN interface. It just took all traffic to the default gateway. This was GWwg0 when it was up, but if it failed it just went out the wan interface (something i'm happy with, not concerned with leakage).

Now if you have 2 wireguard instances, they don't seem to work unless one of the instances has 'disable routes'  as per the wiki instructions. You then setup the routing in the firewall rules, manually set the gateway address in the wireguard local peer, and also set the gateway monitor ip in the gateway. All things you understandably don't have to do if 'disable routes' is unchecked.
In this instance you have to use gateway groups (and set a lan interface rule to use the grouped gateway) in order to get failover. You also need to add an extra rule which uses the default * gateway for any LAN addresses which sits above the other rule, otherwise you can get locked out of the GUI (weird because the floating anti lockout rule should stop this, but it doesn't seem to.)

Anyway, one of the setups it asks for is adding this floating rule https://wiki.opnsense.org/manual/how-tos/wireguard-selective-routing.html#step-9-configure-routing

What is the point of this? If i disable it, everything still works fine.

Am i missing something, it seems like a rather strange floating rule


I have the exact same question... why step#9?

Basically it's replicating the force gateway rule for WAN, to ensure that packets coming from the WG interface IP go out the right gateway. See this (lengthy) discussion: https://github.com/opnsense/core/issues/5329.

Should really only be an issue for services on OPNsense itself that are intended to use the tunnel (eg unbound in the issue linked above).

Okay... So it's basically like a catch all, just in case (for whatever reason) anything bypasses by accident.

Not really. Routing doesn't happen by accident.

So what is this rule saying exactly?

Anything that is from the Wireguard address that is not going to the Wireguard network should be routed through the Wireguard gateway?

Doesn't seem to make sense...

Why? Anything trying to go somewhere else than the VPN is forced to use the VPN. As outlined above this basically is relevant for services running on OPNsense itself, like unbound (ntp? updates? what else is running on the sense?).
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

Okay, I'm still a bit confused. does this rule cover requests for the local network at all? I think it doesn't because of the rule in step #8 right —
Action: Pass
Quick: Checked
Interface: Whatever interface you are configuring the rule on
Direction: in
TCP/IP Version: IPv4
Protoco: any
Source / Invert: Unchecked
Source: Select the relevant hosts Alias you created above in the dropdown (eg WG_VPN_Hosts )
Destination / Invert: Checked
Destination: Select the RFC1918_Networks Alias you created above in the dropdown
Destination port range: any
Description: Add one if you wish to
Gateway: Select the gateway you created above (eg WAN_VPNProviderName )


But it's a floating rule... so it's processed before the rule above. So does that mean it prevents any clients from accessing the local network?

And also doesn't the rule above (in Step #8) also cover services like Unbound etc, running on the machine because Gateway is specified already.

...rule created according to step 9 is NOT quick...
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

Based on the thread, it appears that Unbound cannot use the wireguard gateway since there is no IP address in the wireguard interface. As a result, some outbound queries use the wireguard address as the source (root domains as the target) but are routed through the WAN interface using the default route. The rule in step 9 forces these packets to be routed through the wireguard gateway.

Is the description above correct?

February 28, 2023, 06:01:23 AM #10 Last Edit: February 28, 2023, 08:41:53 AM by wotcha
Quote from: Salty72 on February 27, 2023, 02:59:42 PM
Based on the thread, it appears that Unbound cannot use the wireguard gateway since there is no IP address in the wireguard interface. As a result, some outbound queries use the wireguard address as the source (root domains as the target) but are routed through the WAN interface using the default route. The rule in step 9 forces these packets to be routed through the wireguard gateway.

Is the description above correct?

In my VPN's setup documentation, to prevent DNS leaks:

1. Go to Services: Unbound: General

2. Scroll to Outgoing Network Interfaces and select the VPN Interface (e.g. OPENVPN_Gateway). Please note that this setting is very important as it prevents DNS leaks.

3. You must disable DNSSEC support (optional based on suggestion from your VPN provider)

4. Save & Apply

So now all DNS requests from interfaces checked in  Services: Unbound: General > Network Interfaces, will be routed through the VPN.

So, I think it covers that case (?) probably?
(But without the steps above, I would therefore assume that one would need rule 9 as well.)

February 28, 2023, 06:49:31 AM #11 Last Edit: March 02, 2023, 04:48:58 AM by wotcha
Quote from: chemlud on February 26, 2023, 08:20:09 PM
...rule created according to step 9 is NOT quick...

okay, thanks for the tip. I have read the OPNsense documentation and a few articles and videos on this to understand... so I just want to make sure I understand correctly..

So the non-quick rules are processed last. Therefore now FLOATING rules have the effect of being processed last?

Therefore, is this amended graphic about right?

March 02, 2023, 04:47:14 AM #12 Last Edit: March 02, 2023, 07:06:37 AM by wotcha
I just got this double checked, and the graphic above I had posted previously is NOT correct.

THIS IS CORRECT in how the processing rules are applied:



Hope this is useful to somebody, image can be re-used anywhere.

Sorry I am only just coming back to this as I haven't had my VPN on for the last year. Thank you all for replies and responses.