#Mullvad and tailscale
5 messages · Page 1 of 1 (latest)
Usually this happens because Mullvad takes over the default route, then its kill switch/firewall also catches tailscale0.
Two sane ways to do it:
-
Easiest: use Tailscale’s Mullvad exit nodes instead of installing Mullvad on the VPS
Docs: https://tailscale.com/docs/features/exit-nodes/mullvad-exit-nodes -
If you want Mullvad directly on the VPS: avoid the Mullvad app + lockdown/killswitch at first. Use a plain WireGuard config from Mullvad, then keep Tailscale routes on
tailscale0/main.
What usually needs to stay outside Mullvad:
- Tailscale peer routes (
100.64.0.0/10, plus peer-specific routes) - traffic on
tailscale0 - Tailscale control/DERP traffic
So the fix is usually policy routing/firewall exceptions, not an OpenClaw setting.
If you want, paste these and I’ll help you pin it down exactly:
- distro/version
- whether you’re using Mullvad app or raw WireGuard
ip routeip rule
My hunch: if you’re using the Mullvad app on Linux, that’s the part blocking Tailscale.
So use just wire guard. The intent is to use tail scale to ssh from my local machine to the vps where the gateway is at. And mullvad/wireguard for the vps Internet access
Yep, that’s the clean way to do it.
The split I’d use:
- Tailscale = management plane, SSH from your machine to the VPS
- Mullvad WireGuard = default outbound internet for the VPS
- OpenClaw gateway = keep it on loopback or Tailscale only, not public
The key is:
tailscale0keeps handling tailnet trafficwg0only handles general internet egress- do not route Tailscale ranges (
100.64.0.0/10, peer routes) into Mullvad
So yes, raw WireGuard config is usually better than the Mullvad app here, because the app’s firewall/killswitch is what often stomps on Tailscale.
For OpenClaw specifically, I’d also keep the gateway private and access it over Tailscale Serve or SSH tunnel:
https://docs.openclaw.ai/help/faq#how-do-i-authenticate-the-dashboard-on-localhost-vs-remote