[HOWTO]: Mullvad Selective Routing guide for dummies

[colourcode]

Do you know if there's a way to keep this working while simultaneously running a home VPN for my own devices?  I had a road warrior wireguard setup for my devices, but every configuration for Mullvad seems incompatible with it.  I'm not entirely sure why, but I think it's because the outbound NAT rule for the road warrior setup interferes with the outbound NAT rule for the Mullvad setup.  I'm not entirely sure how to work around this though.

I am running this and my own roadwarrior setup side by side.

Not sure how the NAT rules could collide TBH. They won't be running on the same source interfaces.
The NAT rule for road warrior setup to access other internal networks doesn't seem to be needed if you assigned it an interface. My rule below is disabled for WGHOME and I can still access my internal resources.

Code Select Expand

Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description    
WAN WGHOME net udp/ * * udp/ * Interface address         * NO NAT wgHome Internal     
WGSTO1 selectiveRoute          * * * Interface address          * NO NAT wgSTO-1 SelectiveRoute 


[Arby]

Perhaps I had some firewall rules misconfigured then.  I was able to get the Mullvad connection working perfectly when I followed your guide, but only after I disabled everything for my road warrior setup.  I'm going to try again today with a fresh OPNsense build (I opted to do a factory reset after I ended up breaking some things), and I'll try and be a little bit more well-informed about what each step is doing along the way.  The road warrior setup that I did was pretty much identical with the OPNsense documentation; I'm not entirely sure yet if there's anything I'd need to change for it.

[Arby]

Hmm, okay, this is interesting.  This time, I encountered the opposite issue.  After setting up a home wireguard system, I successfully got Mullvad working simultaneously with my road warrior setup (wg0).  But devices in the Mullvad alias made in step 6 of this guide become unable to communicate with one another.  This is in spite of the fact that I'm using wg0 as interface for this alias.  So the devices are definitely still part of my home VPN (and a quick look at the WireGuard status page confirms this), but I can't, e.g., SSH into my NAS from my main PC, unless it's over LAN.

I think I understand why this is happening, at least.  I think the floating rule in place directs ALL traffic sourced from my Mullvad alias through the Mullvad gateway, which means that if I ping 10.0.0.3, that ping is first going to bounce over to Mullvad's server, and then from there, bounce to local IP 10.0.0.3 -- which is a nonsense IP at that point, so there's no response.  So now the question is how to exclude wg0 traffic from the Mullvad gateway.  I tried changing the "Destination" on the floating rule to "WAN net" and/or "WAN address", but doing this seems to disable Mullvad connectivity for either case.

[Arby]

Eureka!  I figured it out.

Here's what I did: I created a new Floating rule:

Interface	The one used to make the alias in step 6
Source	The alias in step 6
Destination	wg0 net
Gateway	default
Description	(if you want one)

Then after hitting "Save," I clicked the check mark on the left next to this new rule, and then clicked on the left arrow on the right of the Mullvad floating rule (the one that says "Move selected rules before this rule" when you hover over it).

This rule captures packets running over wg0.  Since packets only ever get handled by one firewall rule [citation needed], the Mullvad Gateway rule gets bypassed.

[swunggg]

Just came here to say that if you're following the guide and looking to get more than 1 wireguard instance set up (I spent hours troubleshooting a few days ago only to realize a Mullvad peer was replying to pings but down), you can use gateway groups. Just modify your selective routing rules to target the new gateway group. The one hiccup for me was that I followed this tip to make certain RFC 1918 addresses route over wireguard according to step 8 of their selective routing docs...

Note

The rule below will mean that no local (private) IPs can be accessed over the tunnel. You may have a need however to access certain IPs or networks at the VPN endpoint, such as a DNS server or monitor IP. In that case, you will need to create an additional firewall rule in OPNsense to ensure that requests to those IPs/networks use the tunnel gateway rather than the normal WAN gateway. This rule would be similar to that created below, except that the destination would be the relevant IPs/networks (or a new Alias for them) and the destination invert box would be unchecked. This rule would also need to be placed above the rule created below

... so I needed to make a rule for each gateway, instead of adding the second gateway to the rule I originally created. Now the failover is pretty much seamless!