"
The Monitor IP doesn't need to be your VPN provider's internal DNS address specifically — it just needs to be *some* real host that actually responds to ICMP when routed through that particular tunnel. Mullvad's docs suggesting `10.64.0.1` is just a convenient, known-working example, not a requirement.
Since OPNsense won't let you reuse the same Monitor IP across multiple gateways, the simplest fix is to give each tunnel a different public target — for example:
- Gateway 1: `9.9.9.9` (Quad9)
- Gateway 2: `1.1.1.1` (Cloudflare)
- Gateway 3: `8.8.8.8` (Google)
- Gateway 4: `1.0.0.1` (Cloudflare secondary)
Any of these will work as long as it genuinely answers ping through that specific tunnel — don't just assume it does, confirm it (see below).
One thing worth double-checking based on some fairly extensive troubleshooting I went through recently with a similar multi-gateway WireGuard setup on ProtonVPN: **make sure it's actually the Monitor IP field throwing the duplicate error, and not the Gateway "IP Address" field** (the Far Gateway placeholder). Those are two separate fields on the same System Gateway config screen, and both need to be unique per gateway too — the placeholder "IP Address" also can't be reused across multiple WireGuard gateways on this same box. If you're getting a duplicate error on that field instead of (or in addition to) Monitor IP, you'll need a distinct placeholder value per tunnel as well (e.g. `10.64.1.1`, `10.64.2.1`, `10.64.3.1`, etc. — arbitrary, unused, just needs to be unique).
Also, whichever Monitor IP you land on per gateway, actually verify it before trusting it — this bit me hard on a recent project. Confirm with a packet capture that the ping genuinely traverses the tunnel interface (not silently falling through to WAN):
```
tcpdump -ni <tunnel-interface> icmp
```
while pinging the monitor IP sourced from that tunnel's local address in another window. If nothing shows up on the tunnel interface, the monitor IP isn't actually testing what you think it's testing — regardless of what the dashboard says.
Hope this helps.
I also recommend using Claude as you set it up to help answer questions and troubleshoot.
Since OPNsense won't let you reuse the same Monitor IP across multiple gateways, the simplest fix is to give each tunnel a different public target — for example:
- Gateway 1: `9.9.9.9` (Quad9)
- Gateway 2: `1.1.1.1` (Cloudflare)
- Gateway 3: `8.8.8.8` (Google)
- Gateway 4: `1.0.0.1` (Cloudflare secondary)
Any of these will work as long as it genuinely answers ping through that specific tunnel — don't just assume it does, confirm it (see below).
One thing worth double-checking based on some fairly extensive troubleshooting I went through recently with a similar multi-gateway WireGuard setup on ProtonVPN: **make sure it's actually the Monitor IP field throwing the duplicate error, and not the Gateway "IP Address" field** (the Far Gateway placeholder). Those are two separate fields on the same System Gateway config screen, and both need to be unique per gateway too — the placeholder "IP Address" also can't be reused across multiple WireGuard gateways on this same box. If you're getting a duplicate error on that field instead of (or in addition to) Monitor IP, you'll need a distinct placeholder value per tunnel as well (e.g. `10.64.1.1`, `10.64.2.1`, `10.64.3.1`, etc. — arbitrary, unused, just needs to be unique).
Also, whichever Monitor IP you land on per gateway, actually verify it before trusting it — this bit me hard on a recent project. Confirm with a packet capture that the ping genuinely traverses the tunnel interface (not silently falling through to WAN):
```
tcpdump -ni <tunnel-interface> icmp
```
while pinging the monitor IP sourced from that tunnel's local address in another window. If nothing shows up on the tunnel interface, the monitor IP isn't actually testing what you think it's testing — regardless of what the dashboard says.
Hope this helps.
I also recommend using Claude as you set it up to help answer questions and troubleshoot.
