VPNSpotter

Kill switches, DNS leaks, and split tunneling explained

What a VPN really does, how protocols and encryption work, and what "no logs" actually means — the ground floor before you spend a euro.

10 min read

Why these features matter more than marketing promises

Most VPN marketing screams about "military-grade encryption" and "anonymous browsing." But when your connection drops for half a second, does your real IP address leak to every website you have open? When you query a domain name, does your ISP see exactly which sites you're visiting despite the encrypted tunnel? Can you route only your torrent client through the VPN while your banking app uses your normal connection?

These aren't edge cases. They're daily realities that separate a tool that actually protects your privacy from one that just looks like it does in screenshots.

This chapter covers three features that determine whether your VPN works when it matters: kill switches (what happens when the tunnel fails), DNS leak protection (whether your domain queries bypass encryption), and split tunneling (selective routing for specific apps or sites). Understanding these isn't optional if you care about the privacy you're paying for.

Kill switches: the emergency brake you hope never triggers

A kill switch blocks all internet traffic the moment your VPN connection drops. No tunnel, no internet. That's the entire job.

What happens without one

You're torrenting a Linux ISO through Mullvad. Your VPN reconnects after a brief drop. For those three seconds, every peer in the swarm saw your actual IP address. Your ISP logged the BitTorrent traffic. The copyright monitor noted your participation in the swarm.

Or you're researching a sensitive topic through Proton VPN. The connection hiccups. Your browser instantly re-queries that domain using your ISP's DNS servers, associating your real IP with the search query before the VPN reconnects.

The failure doesn't need to last long. Modern operating systems are extremely aggressive about restoring internet connectivity. Windows, macOS, and most Linux distributions will immediately fall back to your default network interface the instant they detect the VPN adapter has dropped. This happens in milliseconds, often before you notice the disconnection notification.

How kill switches actually work

Software kill switches use firewall rules. When you enable the VPN, the client adds rules that:

1. Block all traffic except through the VPN's virtual network interface 2. Allow connections only to the VPN server's IP address(es) 3. Permit local network traffic (optional, usually configurable)

If the VPN tunnel drops, traffic simply stops. The firewall rules remain active until you disable the kill switch or reboot (depending on implementation quality).

Network-level kill switches go further. Some routers running custom firmware (DD-WRT, Tomato) can enforce VPN-only routing for all connected devices. If the tunnel fails, the router blocks internet access for everything downstream. This protects phones, tablets, smart TVs—any device that can't run VPN client software with its own kill switch.

The variants you'll encounter

System-level kill switches (sometimes called "always-on" or "permanent") survive VPN client crashes and restarts. Mullvad offers this on Windows, Linux, and macOS. Even if you force-quit the VPN app, the firewall rules persist until you explicitly disable them in the client or remove them manually from your OS firewall.

App-level kill switches only work while the VPN client is running. Close the app, and protection ends. This is common in mobile VPN clients where OS restrictions limit firewall access.

Per-app kill switches let you specify which applications get blocked if the VPN drops. ProtonVPN's Windows client offers this. You can protect your torrent client and browser while allowing your email client to maintain connection through your regular network if the VPN fails. Useful but requires careful thought about which apps handle sensitive data.

Testing your kill switch

Don't assume it works. Verify:

1. Enable the kill switch in your VPN client 2. Connect to a VPN server 3. Open a browser and confirm your IP shows the VPN server's location (use whoer.net or ipleak.net) 4. Force-disconnect: either kill the VPN client process entirely or block its traffic through your OS firewall 5. Attempt to load a new webpage or ping an external server

If you can reach anything outside your local network, your kill switch failed. This happens more often than VPN companies admit, especially after OS updates that reset firewall priorities or on mobile platforms with aggressive battery optimization that suspends VPN processes.

DNS leaks: the silent privacy destroyer

DNS (Domain Name System) translates human-readable addresses like "vpnspotter.co" into IP addresses that computers actually use. Every time you visit a website, your device sends a DNS query. If those queries bypass your VPN tunnel, your ISP sees a complete log of every domain you access, even though they can't see the encrypted content of your HTTPS connections.

Why this matters even with HTTPS

Yes, HTTPS encrypts the content of your web traffic. But DNS queries typically happen in plain text over UDP port 53. Your ISP can't read your messages on Signal's website, but they absolutely know you visited signal.org if your DNS query leaked.

Worse, DNS queries often reveal more than just the domain. Some content delivery networks use unique subdomains for specific content. Visit a news article, and the DNS query might reveal the exact CDN subdomain that corresponds to that article's images or videos. Correlate enough of these, and browsing patterns emerge even without decrypting the actual traffic.

How DNS leaks happen

Split DNS configurations: Your OS maintains a list of DNS servers. Even with a VPN active, Windows and macOS might send queries to all configured DNS servers simultaneously and use whichever responds fastest. If your ISP's DNS server is in that list and responds before the VPN's DNS server, your query leaked.

IPv6 DNS queries: Your VPN might route IPv4 traffic perfectly but ignore IPv6. If your ISP provides IPv6 connectivity and your OS prefers it, DNS queries could bypass the VPN tunnel entirely through the IPv6 interface.

DNS rebinding and local network exceptions: Some VPNs exclude local network traffic from the tunnel (intentionally, for printer access and LAN devices). Attackers or poorly configured local network devices can exploit this to leak DNS queries through your regular network interface.

Transparent DNS proxies: Some ISPs intercept all DNS traffic on port 53 regardless of destination. You configure your device to use 1.1.1.1 (Cloudflare), but your ISP silently redirects those queries to their own DNS servers. Your VPN tries to send encrypted DNS requests through the tunnel, but the ISP's proxy catches them first.

DNS leak protection mechanisms

Good VPN clients implement multiple layers:

Forced DNS configuration: The VPN client replaces your system's DNS servers with the VPN provider's DNS servers when connecting. When you disconnect, it restores your original settings.

DNS query routing through the tunnel: All DNS traffic gets wrapped in the VPN tunnel alongside your regular internet traffic. Even if your OS thinks it's querying 8.8.8.8, the actual packet goes through the encrypted tunnel to the VPN server, which then performs the query.

DNS filtering at the firewall level: Block all DNS traffic on port 53 except through the VPN interface. This prevents even misconfigured applications from leaking queries.

DNS over HTTPS (DoH) or DNS over TLS (DoT): Encrypt DNS queries themselves, independent of the VPN tunnel. NextDNS and Cloudflare offer this. It's defense-in-depth: even if queries somehow leak out of the VPN tunnel, they're still encrypted.

Testing for DNS leaks

Go to dnsleaktest.com while connected to your VPN. Click "Extended test."

You should see only DNS servers belonging to your VPN provider or the DNS service they use (often shown with the VPN server's location). If you see your ISP's name, your city, or IP addresses registered to your local internet provider, you have a DNS leak.

IPv6 leak testing: Use test-ipv6.com and ipleak.net. Many VPN clients still handle IPv6 poorly. If these sites show an IPv6 address that isn't from your VPN provider, disable IPv6 entirely on your device (not ideal, but more private than leaking queries).

Run these tests:

  • Immediately after connecting
  • After switching VPN servers
  • After putting your device to sleep and waking it
  • After switching WiFi networks while the VPN is active
Leaks often appear during connection transitions, not steady-state operation.

Split tunneling: selective routing for the real world

Split tunneling lets you route some traffic through the VPN while other traffic uses your normal internet connection.

Why you might actually want this

Banking apps that block VPNs: Some financial institutions flag VPN connections as suspicious and lock accounts. Rather than disconnect your VPN entirely, route only your banking app outside the tunnel.

Local network access: You're working remotely and need to access a printer, NAS, or local server while maintaining VPN protection for internet traffic. Split tunneling can exclude local network ranges (192.168.x.x, 10.x.x.x) from the tunnel.

Speed-sensitive applications: Video calls already struggle with latency. Routing them through a VPN server adds another hop. If you're not concerned about your employer seeing that you're on a Zoom call (they scheduled it), exclude the video conferencing app to reduce lag.

Geo-restrictions within a single session: You want US Netflix in your browser but need to access a local banking site simultaneously. Split tunneling can route browser traffic through the VPN while your banking app uses your real location.

The privacy tradeoffs

Every exception is a potential leak. That banking app you excluded? It might share analytics data that includes your real IP address, device identifiers, and location with third-party trackers. Those local network exceptions? They can be exploited by malicious JavaScript to probe your LAN and fingerprint your real location.

Split tunneling makes sense for convenience, not for maximum privacy. If you're trying to avoid surveillance or protect genuinely sensitive research, avoid it. Route everything through the VPN or use nothing at all.

Implementation approaches

App-based split tunneling: Specify which applications bypass the VPN. ExpressVPN and NordVPN offer this on Windows and Android. Your torrent client routes through the VPN, but your banking app doesn't.

Domain-based split tunneling: Route specific domains or IP ranges outside the tunnel. More granular but requires manually specifying exceptions. Common in enterprise VPN clients but rare in consumer tools.

Inverse split tunneling: Everything bypasses the VPN except the apps or domains you specify. Useful if you only want protection for a torrent client or specific browser while leaving everything else on your regular connection.

Configuration risks

WebRTC leaks in browsers: Even with split tunneling configured correctly at the OS level, WebRTC can leak your real IP address through browser APIs. If you're routing your browser through the VPN but have split tunneling enabled for other apps, test for WebRTC leaks at browserleaks.com/webrtc. Disable WebRTC in browser settings or use an extension like uBlock Origin to block it.

DNS still leaks if not configured properly: Split tunneling routes traffic selectively, but doesn't automatically handle DNS separately. If your banking app is excluded from the VPN tunnel, its DNS queries might still leak through your ISP unless you've configured separate DNS protection.

Testing split tunneling

1. Configure split tunneling to exclude a specific app (use a simple tool like curl or a secondary browser) 2. Connect to your VPN 3. Check your IP address in the included app (your primary browser): should show VPN server location 4. Check your IP address in the excluded app: should show your real location 5. Verify DNS isn't leaking from either app using dnsleaktest.com in both

If both show VPN or both show your real IP, split tunneling isn't working as configured.

What to look for when comparing VPN providers

When evaluating VPNs, ask these questions directly:

Kill switch: Does it persist if the client crashes? Can you test it without risking real leaks? Is it available on all platforms you use, or just desktop?

DNS leak protection: Does the client force its own DNS servers? Does it handle IPv6 DNS queries or just disable IPv6 entirely? Can you verify DNS server ownership during connection?

Split tunneling: Can you exclude apps, domains, or both? Does it work reliably across network changes (WiFi to cellular)? Does the interface make it obvious what's protected and what isn't?

Check user reports in subreddits like r/VPN and privacy forums. DNS leaks and kill switch failures generate complaints quickly. If you see multiple recent reports of leaks after a VPN client update, that's a red flag about development quality and testing rigor.

Key takeaways

  • Kill switches are mandatory if you handle sensitive traffic—test yours by force-killing the VPN client and attempting to reach the internet; if you can, it failed
  • DNS leaks expose your browsing history even with HTTPS—run extended leak tests at dnsleaktest.com after connecting, after switching servers, and after network changes
  • IPv6 leaks are still common in 2024—disable IPv6 system-wide if your VPN client doesn't handle it properly, or verify with test-ipv6.com
  • Split tunneling trades convenience for privacy—exclude only non-sensitive apps and verify with IP checks in both included and excluded applications
  • These features fail during edge cases—test after OS updates, network transitions, and sleep/wake cycles, not just during initial steady-state connection
  • Marketing claims mean nothing—providers that publish technical documentation about kill switch implementation and DNS handling are more trustworthy than those that just say "full protection"