Guides

Kill switch and leaks: DNS, WebRTC, IPv6

A kill switch blocks all internet traffic the moment a VPN tunnel drops, so apps cannot silently fall back to your regular connection. Without it, even a two-second disconnect exposes your real IP address. Even while the tunnel is up, DNS requests, WebRTC in the browser, and IPv6 traffic can leak around it. Each leak has a simple test and a fix.

🛡️

A dropped tunnel fails open

When a VPN connection breaks, the operating system quietly routes traffic through the normal interface. Apps keep working and nothing warns you. A kill switch turns fail-open into fail-closed: no tunnel, no traffic.

🌍

Leaks happen with the tunnel up

DNS queries can go to your ISP resolver outside the tunnel, WebRTC can hand websites your addresses, and IPv6 can bypass an IPv4-only tunnel — all while the VPN icon says connected.

🔑

Every leak is testable

You do not have to trust settings screens. A leak test shows which addresses and resolvers websites actually see, and breaking the tunnel on purpose shows whether the kill switch holds.

What happens the moment the tunnel drops

The connection fails open. A VPN adds routes that steer traffic into a virtual network interface. When the tunnel process dies or times out, those routes disappear, while the default route through Wi-Fi or Ethernet remains — so the system keeps delivering packets, now directly through your ISP. Apps reconnect their sockets within seconds, sending traffic from your real IP, with no error dialog anywhere.

Drops are routine. Switching from Wi-Fi to mobile data, a laptop waking from sleep, a flaky hotel network, or a VPN server restart all break the tunnel for a moment. What that moment costs depends on whether anything is allowed to leave your device while the tunnel is down.

What a kill switch actually does

A kill switch is a set of firewall rules, not magic. The strict version allows only two kinds of outbound traffic: packets entering the tunnel interface, and the VPN client's own encrypted packets to the server. If the tunnel goes down, application traffic simply has nowhere to go until it returns.

This changes the failure mode rather than preventing failures. With a kill switch, a drop becomes a paused connection you notice; without one, it becomes traffic on your real address that you do not notice. Networks are imperfect and the tunnel will still break — fail-closed makes those moments harmless.

System kill switch vs a switch inside the app

The difference is what happens when the app itself dies. An in-app kill switch is code inside the VPN client that watches the tunnel and blocks traffic when it drops. It only works while the client runs: if the client crashes or is killed by a battery optimizer, its protection dies with it — at exactly the moment the tunnel disappears.

A system-level kill switch installs rules in the operating system's own firewall, which inspects every outbound packet regardless of which apps are running. Android has this built in: always-on VPN plus blocking connections without VPN makes the OS itself refuse traffic outside the tunnel, even before the app starts after a reboot. The blunt way to tell the two apart: force-kill the VPN app while browsing — if pages still load, the switch lives in the app.

DNS leaks: requests that skip the tunnel

A DNS leak means your name lookups go to the resolver your local network assigned — usually your ISP's — even though the traffic itself rides the tunnel. Websites see the VPN address, but the resolver receives the name of every site you open, which amounts to a browsing log. Windows is the classic offender: with several active interfaces it can query all of them in parallel and use whichever answers first.

The fix has two parts, and a good client does both: point the system at the resolver inside the tunnel, and block DNS on every other interface so a stray query has nowhere to go. Then verify: run a leak test and check the resolvers it lists — if any belong to your ISP, lookups are leaking.

WebRTC leaks: the browser gives away addresses

WebRTC is the browser technology behind video calls, and any website can invoke it with a few lines of JavaScript. To set up direct connections it collects every address that might reach your machine: local addresses and, by asking a STUN server, your public one. A page can read those candidates without your involvement.

With a full-device tunnel the STUN request rides inside the tunnel, so it discovers the VPN's address. The dangerous setups are partial: a browser-only proxy or split tunneling that leaves the browser outside — there WebRTC's UDP packets go out directly and reveal your real IP.

Test it rather than reasoning about it: our free checker at /webrtc-leak-test/ shows which addresses your browser reveals right now. If the real one appears, move to a full-device tunnel or disable WebRTC in browser settings.

IPv6 leaks: the tunnel only covers IPv4

Many VPN configurations carry IPv4 only. If your ISP also provides IPv6 — most mobile networks do — the system keeps a working IPv6 route outside the tunnel, and modern systems prefer IPv6 when a site offers both. The result is selective exposure: sites without IPv6 see the VPN address, sites with it see your real one, and an IPv4-only test reports everything as fine.

There are two clean fixes. The better one is a VPN that handles IPv6 properly — tunneling it alongside IPv4 or installing a blocking route so IPv6 packets are dropped, not sent directly. The blunt fallback is disabling IPv6 on the device or router. Either way, verify: the leak test should show no IPv6 address that is not the VPN's.

How to test your setup properly

Run the checks in the conditions you actually use — home Wi-Fi, phone on mobile data, a café network — because leaks depend on each network's DNS setup and IPv6 availability. The routine takes about five minutes:

  • Note your real IP with the VPN off, connect, and confirm the visible IPv4 and IPv6 addresses both changed — our /data-leak-checker/ shows IP, DNS resolvers, and WebRTC in one pass
  • Check the resolver list: every DNS server shown should belong to the VPN, none to your ISP
  • Break the tunnel on purpose — toggle Wi-Fi or force-kill the app — and watch whether pages load before it reconnects
  • Repeat after OS or VPN app updates, since both can quietly reset network settings

Frequent questions

Do I need a kill switch if my connection is stable?
Yes — the drops that matter are the ones you do not anticipate: waking a laptop, switching between Wi-Fi and mobile data, a server-side restart. Stability reduces how often the tunnel breaks, not what happens when it does. The switch costs nothing while the tunnel is up and only acts on failure.
Why does a leak test show my VPN IP but my ISP's DNS servers?
That is a classic DNS leak: traffic goes through the tunnel, but name lookups still go to the resolver your local network assigned. Either the client failed to override the system resolver, or the OS queries several interfaces in parallel. Enable the client's DNS protection, reconnect, and retest.
Can WebRTC leak my address even while the VPN is connected?
With a full-device tunnel, generally no — WebRTC's discovery traffic rides inside the tunnel and finds the VPN address. Leaks appear in partial setups: browser proxies, extensions, or split tunneling that leaves the browser outside. A WebRTC test settles it in seconds.
Should I just disable IPv6 entirely?
It works as a blunt fix, and on networks where your VPN cannot manage IPv6 it is the pragmatic choice — virtually every service is still reachable over IPv4. The cleaner answer is a VPN that tunnels or blocks IPv6 itself, keeping protection without edits on every device.
Will a kill switch cut my internet when I disconnect on purpose?
A well-built client removes its blocking rules when you press disconnect, so normal traffic resumes immediately; the block is meant for unexpected drops. Some clients also offer a stricter mode where no traffic flows unless the tunnel is up, useful on a device that should never bypass it.
How often should I re-test for leaks?
Test after anything that touches networking: an OS upgrade, a VPN app update, a new browser, an unfamiliar network, changed router settings. Each can reset DNS behavior or re-enable IPv6. A full pass takes five minutes, so test on each new network and after updates rather than on a schedule.

Keep reading

Try Aurora

14-day money-back guarantee. Up to 7 devices on one subscription.

Protect my devices