[solved] Dual-stack failover group monitors with Mullvad?

Started by OPNenthu, June 13, 2026, 03:13:00 PM

Previous topic - Next topic
June 13, 2026, 03:13:00 PM Last Edit: June 13, 2026, 11:37:59 PM by OPNenthu Reason: marking resolved
Hopefully I either missed the solution, or someone can inform me that it won't work and put me out of my misery :)  The trouble is with dpinger on the IPv6 gateways.

The setup:

- Two Mullvad instances (wg1, wg1) assigned to interfaces WAN_VPN1 & WAN_VPN2.  The WG instances have "Disable routes" checked.  Requisite NAT and f/w rules are in place.

- Four static gateways configured in two failover groups, per IP protocol:

  VPN_GPOUP_4:
    * WAN_VPN1_GW (Tier1)
    * WAN_VPN2_GW (Tier2)

  VPN_GROUP_6:
    * WAN_VPN1_GW6 (Tier1)
    * WAN_VPN2_GW6 (Tier2)

- The failover groups are referenced in firewall rules on local interfaces for policy routing.


Routing to the respective gateway groups is working and traffic is flowing fine.

Failover for the IPv4 group is straight forward because Mullvad has several in-tunnel IPv4 addresses for DNS, e.g. 100.64.0.1, 100.64.0.2, etc., and dpinger has no problem with those as monitor IPs.

Failover for the IPv6 group seems impossible (?) because there aren't published IPv6 in-tunnel addresses that can be used, and because the tunnel endpoint is /128 dpinger also fails when public IPs (such as Google DNS) are used.  It works initially but once the tunnel/gateway are bounced then it returns 100% packet loss indefinitely.  There's probably a routing or source address selection issue there.

Has anyone cracked how to monitor independent IPv6 gateways on Mullvad, or how to have the V6 gateway status follow the V4 gateway status automatically?

--

P.S. there is one known IPv6 in-tunnel address that all Mullvad instances seem to have (fc00:bbbb:bbbb:bb01::1) and this is reachable by dpinger, but the issue is that gateway monitors in OPNsense require unique IPs, I guess due to the static route created.  Can't use the same monitor IP on both IPv6 gateways.
N5105 | 8/250GB | 4xi226-V | Community

Got it working after re-visting the section on configuring IPv6 in the OPNsense documentation for selective routing.

If you're following other sources, such as a pfSense tutorial on YouTube which uses the same IPs for both the tunnel and gateway, just know that this doesn't work here.  It's not just a preference; it's a requirement for the monitor to work at all.  OPNsense (at least 26.1) I think treats the WG tunnels as routed point-to-point links when configuring gateways even though they really aren't so we have to use those semantics.

Mullvad configs are using /128 so I had to do the trick mentioned in the docs to manually set the config to /127 and use the other matching IP in that range for the IPv6 gateway.  I left the IPv4 tunnel address as /32 but used IP-1 for the IPv4 gateway.  Now both in-tunnel IPs and external (public) IPs can be pinged by the monitor.

This works but it does also produce some noise in the WireGuard logs:

Notice
wireguard
/usr/local/opnsense/scripts/wireguard/wg-service-control.php: Chose to bind WAN_VPN2_GW on 10.xx.xxx.198 since we could not find a proper match.

I'm assuming this is expected and safe to ignore since .198 is the interface address.  Maybe it's seeing the gateway address (.197) as well and realizing that it's bogus.  Not sure.

One more observation: the trick of using traceroute to find the next-hop tunnel address to use as a monitor IP doesn't work for all Mullvad peers, or it only turns up the aforementioned gateway (fc00:bbbb:bbbb:bb01::1) that is common to all tunnels.  I switched to using public DNS IPs.  Hopefully Mullvad will some day provide IPv6 versions of their in-tunnel name servers.
N5105 | 8/250GB | 4xi226-V | Community