Tailscale + Mullvad Split Tunnel: What Still Leaks When You Stack Two Overlays

I started stacking Tailscale and Mullvad because I wanted two different jobs on one laptop. Tailscale is how I reach a subnet router in a relative’s house and a Mini PC that runs Immich. Mullvad is how I stop a hotel or a coffee shop from seeing every SNI I generate while I do that. The pitch is tidy. The routing table is not.

People call the combination a split tunnel and then treat the Mullvad app’s exclude list as a privacy control. It is an egress picker. Whatever you exclude still leaves the machine. It just leaves through Tailscale, through the raw Wi-Fi, or through whatever Windows decided was the next best default route that second. The leaks I keep finding are not “Mullvad was broken.” They are traffic I never put in the tunnel I thought I was using.

Two products, three topologies

There are at least three ways to stack these, and they leak differently.

The clean one is Tailscale’s Mullvad add-on. In the admin console you enable Mullvad as an exit node, pick a city, and the Tailscale client sends internet egress there. Your tailnet stays on Tailscale. You are not running two VPN adapters that both want 0.0.0.0/1. I use this on a travel laptop when I can stand the extra hop. What you are trusting is documented: Tailscale still runs the control plane and sees which devices exist. Mullvad sees a WireGuard peer that arrived via that partnership. Your hotel ISP sees a WireGuard session to Tailscale, not a session to Mullvad, because the Mullvad hop is inside the tailnet’s exit path.

The messy one is two clients on one OS. Mullvad’s Windows and macOS apps will split-tunnel by process. Tailscale’s client is a TUN plus a userspace bits. You exclude Tailscale.exe so the mesh does not die, or you exclude the browser so “only Firefox is private.” I have done both. Both produce a machine that is in three networks at once: the LAN, the tailnet, and Mullvad’s tunnel, with DNS following whichever adapter won the last race.

The third is Mullvad on a travel router (GL.iNet Slate / Beryl, or a cheap OpenWrt box) and Tailscale on the laptop. The router owns the coffee-shop hop. The laptop owns the mesh. This is the least surprising setup I run, and it still leaks if the laptop’s Tailscale exit node is enabled “just in case” and starts pulling internet back through a house that is not on Mullvad.

What split tunnel actually excludes

Mullvad’s split tunneling is an allow-list or deny-list of applications, depending on the OS build. It is not “send RFC1918 outside the VPN,” although some versions also have a local-network toggle. Tailscale’s own split-DNS and subnet routes are a different mechanism. When you stack them, you have two independent ideas of “this packet is local.”

Exclude the Tailscale client from Mullvad and peer traffic can go out the hotel Wi-Fi as ordinary Tailscale WireGuard. That traffic is still encrypted to the peer or to a DERP relay. The hotel sees Tailscale infrastructure IPs and UDP 41641 or the DERP HTTPS. That is the same visibility you already accepted by running Tailscale at all. It is not a Mullvad leak. It is you deciding the mesh is more important than hiding the fact that you have a mesh.

Exclude the browser from Mullvad and you have a privacy product that does not cover the only process you care about. I watch people do this so Netflix will pick a local CDN, then forget the exclude is still on when they open webmail. The Mullvad app will still say connected. The browser will still use the coffee-shop path, or Tailscale’s exit node if you left one selected.

Exclude nothing and run both clients at full tunnel, and you get the fight. On Windows I have seen Mullvad win the default route and Tailscale keep MagicDNS, so ping nas works and https://nas hangs while the browser uses Mullvad’s DNS, which has never heard of MagicDNS. On Android the “always-on VPN” slot is one process. The second client becomes a part-time guest. I stopped running both Android clients on the same phone. The official Mullvad-as-exit-node path is the one that survives a screen-off hour.

DNS is the leak that looks like a routing leak

Tailscale wants 100.100.100.100 for MagicDNS and for names you split-DNS to a Pi-hole at home. Mullvad wants its own resolvers, and it will fight you if you point the OS at something else. A stacked laptop often ends up with:

• OS adapter DNS on the Mullvad interface
• Tailscale still injecting 100.100.100.100 for *.ts.net and whatever you listed
• Firefox or Chrome DoH to Cloudflare or NextDNS, which ignores both
• iCloud Private Relay on a personal Apple ID, which ignores all of the above for Safari

The practical leak is not “Mullvad sent my query in clear.” Mullvad does encrypt DNS when you use their app as designed. The leak is a query that never entered their app. A DoH browser asks Cloudflare from whatever source address the split tunnel gave that process. If the browser is excluded, Cloudflare sees the hotel IP. If the browser is inside Mullvad but curl is not, your test and your real session disagree, and you will debug the wrong layer for an hour.

I test with a process I actually use, not with nslookup. On Windows, nslookup talks to the system resolver. Firefox might not. The Mullvad connection check page can be green while Safari is on Relay. That is not a dashboard bug. You asked three stacks the same question and they answered honestly about themselves.

IPv6, WebRTC, and the LAN toggle

If Mullvad’s IPv6 kill switch is off and the hotel has v6, a split-excluded app can source v6 on the raw Wi-Fi while v4 is in the tunnel. I still see this on guest networks that are proud of their IPv6. The fix is boring: turn IPv6 off on the laptop, or use a Mullvad setup that really does handle v6, and stop excluding the browser.

WebRTC is the other classic. A browser inside Mullvad can still STUN out and learn a host candidate you did not intend, especially if “allow LAN” is on and the candidate is a 192.168.x address you consider identifying, or if an excluded helper process is doing the ICE gathering. I disable WebRTC in the browsers I care about on travel machines. I do not pretend the VPN UI covers it.

Mullvad’s local-network access is useful for a printer. It is also how a Chromecast on the hotel LAN, or a “smart” TV in a rental, becomes a peer you did not mean to talk to. Tailscale’s subnet routes make this worse: you may have 192.168.1.0/24 advertised from home. The laptop then has two 192.168.1.0/24s in its head — home via the subnet router, hotel via the Wi-Fi. I have watched Windows pick the hotel for a NAS IP that also exists at home. The leak in that story is not an IP to an adversary. It is a file you uploaded to a stranger’s printer because the prefix collided. Rename home to a boring 10.9.0.0/16 if you travel. I should have done that years earlier.

Control-plane traffic you will not hide

Tailscale has to talk to its coordination server. It has to renew certificates. It will use DERP when NAT is ugly. Stacking Mullvad can put that control traffic inside Mullvad if the Tailscale process is not excluded, or outside if it is. Neither choice makes you invisible to Tailscale Inc. The first choice hides Tailscale’s IPs from the hotel and shows them to Mullvad. The second choice shows Tailscale’s IPs to the hotel and keeps the mesh more reliable when Mullvad’s hop is sad.

I used to exclude Tailscale so a Mullvad outage would not take the subnet router with it. Then I watched a hotel captive portal plus excluded Tailscale mean the laptop phoned controlplane.tailscale.com on a network I did not trust, while I told myself I was “on Mullvad.” Now, on travel, I prefer Mullvad-as-exit-node inside Tailscale, or Mullvad on the router and Tailscale on the laptop with no exit node selected. Two full-tunnel clients is the setup I keep only on a desktop that never leaves the house, and even there I am not sure why I bother.

Mullvad the company does not log in the way a free VPN does. That is why I still pay them. It does not erase the fact that Tailscale already knows your identity, your device list, and which exit you picked. Stacking does not create a new anonymity set. It creates a second hop for the packets you actually put through it.

What a hotel packet capture still sees

Assume the two-client Windows setup, Tailscale excluded from Mullvad, browser inside Mullvad, exit node off.

The hotel sees: WireGuard or OpenVPN to Mullvad from the included apps; WireGuard or DERP to Tailscale from the excluded client; plus anything else you left out of the tunnel — Steam, a game launcher, OneDrive, the Windows store, a printer. Those excluded processes source from the hotel DHCP address. That is the leak the marketing page will not draw. Split tunnel is a list of exceptions. Every exception is an egress you decided was not worth hiding.

Assume the official add-on instead. The hotel sees Tailscale. Destinations you fetch via the Mullvad exit are not visible to the hotel. Tailscale’s infrastructure still is. Your home ISP, if you also have a subnet router, sees tailnet traffic arriving at that node, not your hotel browsing. That is usually what I wanted.

Assume Tailscale exit node set to a house Mini PC, and Mullvad running on that Mini PC. The laptop’s internet now exits the house already inside Mullvad. The hotel sees Tailscale. The house ISP sees Mullvad. This is the nicest privacy story of the three, and it dies if the Mini PC reboots and Tailscale fails over to “use my local LAN as internet” without you noticing. I keep a Mullvad kill switch on that node. I do not keep a second Mullvad client on the laptop at the same time. The laptop would then try to Mullvad to a node that is already Mullvading, which is how you get a loop or a silent fallback to the hotel default route when the inner tunnel fails.

Mobile is a different product

On iPhone, Tailscale and Mullvad are both Network Extension VPNs. iOS will not run them as two honest full tunnels. You pick one. The Mullvad-as-exit-node feature inside Tailscale is the only stack that behaves like one VPN from iOS’s point of view. Split tunneling on iOS is mostly “the OS let this app skip the VPN,” which is not a control I trust for anything I care about.

On Android, always-on plus lockdown is excellent for a single client and hostile to a second one. If I need both jobs on a phone, I use Tailscale with a Mullvad exit, or I use Mullvad and accept that I will not have MagicDNS until I am back on a laptop.

On a GL.iNet travel router, put Mullvad on the WAN side and let Tailscale live on the devices. Do not also enable the router’s Tailscale client as an exit unless you have a reason. I have seen a Beryl advertise itself as an exit while Mullvad was down, and every peer that selected it dumped traffic onto the hotel NAT. The badge still said Tailscale connected.

A setup I will defend

Travel laptop: Tailscale with Mullvad exit enabled, MagicDNS on, no extra Mullvad app, browser DoH off, iCloud Private Relay off, IPv6 off, WebRTC off in the browsers I actually use. Home Mini PC: subnet router, no exit node unless I am testing. House internet: whatever it is. I am not trying to hide a household from an ISP with this stack. I am trying to stop a hotel from seeing the destinations and to keep a 100.x address working.

Desktop at home: Tailscale only, unless I have a specific site I want to fetch through Mullvad. Then I use the add-on for an hour and turn it off. A permanent double overlay on a machine that already sits behind a residential IP is complexity I cannot explain to the person who will reboot it.

If you came here hoping two logos would cancel each other’s weaknesses, they do not. Tailscale is a mesh and a company identity. Mullvad is an egress hop with a better logging story. Split tunnel is how you choose which process gets which hop. The leak is whatever you did not choose, plus DNS, plus IPv6, plus the browser features that never asked the VPN for permission. Stack them on purpose, name the path for the browser you actually use, and treat every exclude as a decision you will forget on the next trip.