VPN Leaks and Kill Switches: When the Tunnel Isn't Carrying Everything

A VPN can be connected and still not be carrying all your traffic. The common failures are DNS queries going to your ISP’s resolver, IPv6 traffic bypassing an IPv4-only tunnel, and everything travelling unprotected for a few seconds while the connection drops and re-establishes.

Each has a specific cause and a specific check. None of them is exotic — they’re the standard failure modes, and they’re worth verifying rather than assuming.

DNS leaks

What happens. Before connecting to a site, your device asks a DNS resolver for its address. If that query goes to your ISP’s resolver rather than through the tunnel, your ISP learns every domain you visit — even though the actual traffic is encrypted and tunnelled.

This is the most consequential leak, because for most people the ISP is the observer they were trying to avoid. A DNS leak defeats a large part of the reason for running a VPN at all.

Why it happens. The operating system may have DNS settings that take precedence over the VPN’s. Some applications and browsers use their own resolver configuration. Split-tunnelling rules can route DNS outside the tunnel. On some systems, a secondary network interface supplies its own resolver.

How to check. Connect the VPN and use a DNS leak test service — search for one; several are run by security organisations and by VPN providers themselves. The result should show only resolvers associated with your VPN provider. If you see your ISP’s name, you have a leak.

IPv6 leaks

What happens. Your connection has both IPv4 and IPv6 addresses. If the VPN tunnels IPv4 only, and a site is reachable over IPv6, your device may connect directly over IPv6 — exposing your real address and bypassing the tunnel entirely.

Why it happens. Historically many VPN implementations handled IPv4 and treated IPv6 as an afterthought. Handling has improved considerably, but it’s still worth verifying rather than assuming, particularly with manual configurations.

How to check. An IP address test that reports both your IPv4 and IPv6 addresses. Neither should be your real one. Providers commonly handle this either by tunnelling IPv6 properly or by disabling it while connected — both are acceptable outcomes.

WebRTC leaks

What happens. WebRTC is a browser feature for real-time communication that can, in some configurations, reveal local and public IP addresses to a web page through mechanisms independent of your normal traffic routing.

Why it matters less than it used to. Browsers have tightened this substantially, and it was always browser-level rather than a VPN failure. Still worth a check if IP exposure specifically matters to you.

How to check. A WebRTC leak test page. Mitigations live in browser settings or extensions, not in the VPN.

Reconnection gaps — and the kill switch

What happens. VPN connections drop: the network changes, a server restarts, a device wakes from sleep. Between the drop and the reconnection, your device happily continues sending traffic over the ordinary connection. Applications don’t know anything changed. This can persist for seconds or, if reconnection fails silently, indefinitely.

What a kill switch does. It blocks traffic from leaving the device unless the tunnel is up. If the VPN drops, connectivity stops rather than falling back to the unprotected route. Whether this is desirable depends on you — some people would rather lose connectivity than leak; others find it disruptive. Know which you’ve chosen, and know which the default is.

Variations worth understanding as of writing:

• Application-level — blocks only specified applications. Narrower, and it can miss traffic from anything not on the list.
• System-level — blocks all traffic at the network layer. More thorough.
• Always-on / block-on-disconnect at the OS level — some operating systems offer their own equivalent, independent of the VPN client. Often the most robust option available.

The startup gap. A related and less discussed problem: between your device booting and the VPN client connecting, traffic may flow unprotected — background sync, update checks, mail clients. If this matters to you, look for a setting along the lines of “connect on startup” combined with blocking until connected.

Split tunnelling

Split tunnelling deliberately routes some traffic outside the VPN — useful for local network access or an application that misbehaves through a tunnel.

It’s a feature, not a leak. But it’s also the most common cause of unexpected unprotected traffic, because rules get set once and forgotten. If you use it, periodically re-read what’s excluded. The rule you added for a printer eighteen months ago is still there.

A practical verification routine

Worth doing when you first set up a provider, and again after any client or operating system update:

1. Note your real IP address with the VPN disconnected.
2. Connect, and check your IP again — both IPv4 and IPv6. Neither should match.
3. Run a DNS leak test. Only your provider’s resolvers should appear.
4. Run a WebRTC test if IP exposure specifically matters to you.
5. Test the kill switch deliberately — disconnect the VPN server or drop the network while watching whether traffic continues. This is the step people skip and it’s the one that tells you whether the feature actually works on your setup.
6. Review split-tunnelling rules and remove anything you no longer need.
7. Check the startup behaviour by rebooting and watching whether the client connects before anything else does.

If all of that passes, the tunnel is doing what the mechanism says it should. Whether that’s worth anything to you is a separate question, answered in what a VPN actually protects against.