A VPN is a promise with a failure mode. The promise is that your traffic leaves your device inside an encrypted tunnel and surfaces somewhere else, so your ISP and the networks between you and the destination see the tunnel, not the contents. The failure mode is that tunnels are software, software crashes, laptops sleep, Wi-Fi flickers, and the operating system will happily keep sending your packets the normal way the instant the tunnel is gone. A kill switch and split tunneling are the two controls that decide what your device does in those seconds. Most people turn them on based on a feature checklist without knowing which risk each one addresses.
What a Kill Switch Actually Does
A kill switch is a firewall rule, nothing more exotic than that. When the VPN connects, the client installs rules that block all outbound traffic except through the tunnel interface. If the tunnel process dies, the interface disappears, and the block stays in place. Your applications keep trying to send, the packets hit a wall, and nothing reaches the open internet until the tunnel comes back. The name is dramatic. The mechanism is a default-deny rule with one exception.
The reason this matters is timing. A dropped VPN does not announce itself. Your torrent client, your email app, or a background sync keeps running, and for the window between the drop and the reconnect, every packet carries your real IP address to whatever it was talking to. On a residential connection that might be a few seconds a month. On a flaky mobile network, or a laptop that suspends and resumes a dozen times a day, that window is constant. Without a kill switch, the leak is not hypothetical, it is scheduled.
A kill switch protects you during the transition, not during normal operation. Its entire job is the handful of seconds when the tunnel is down but your apps do not know it yet. If your VPN never dropped, you would never need one.
Application vs system level
Kill switches come in two strengths. An application-level kill switch only closes specific apps you nominate, so if the VPN drops it kills your torrent client but leaves your browser online. A system-level kill switch blocks everything at the network layer. The application version is a convenience feature dressed as a security one. If you are relying on a kill switch for anything that matters, you want the system-level version, enforced by the OS firewall rather than by the VPN app politely asking processes to stop.
There is also the question of what happens at boot. A well-built kill switch fails closed on startup: until the VPN connects, nothing gets out. A weaker one only arms after the first successful connection, which means the moments right after you power on, before the client is running, are wide open. That gap is exactly when auto-launching apps phone home.
What Split Tunneling Actually Does
Split tunneling is the opposite instinct. Instead of forcing everything through the tunnel, it lets you carve out exceptions. You decide that your banking app, your printer on the local network, or a latency-sensitive video call bypasses the VPN and goes straight out your normal connection, while everything else stays tunneled. It exists because routing all traffic through a distant server has costs: added latency, blocked access to local devices, and websites that treat the VPN exit IP as suspicious.
There are two ways to configure it. Inclusive split tunneling means only the apps or destinations you list go through the VPN and everything else is normal. Exclusive split tunneling is the reverse: everything goes through the VPN except the specific things you exclude. The difference is not cosmetic. With inclusive routing, you are opting individual things in, so anything you forget to add leaks by default. That is a fail-open posture, and it is the wrong default for a privacy tool.
Every app you exclude from the tunnel is an app whose real IP address and DNS lookups are exposed. The convenience is real, but so is the leak. Split tunneling trades protection for performance on a per-app basis, and it is easy to exclude more than you meant to.
How the Two Interact
A kill switch and split tunneling can undercut each other if you are not careful. A kill switch says "block everything that is not the tunnel." Split tunneling says "some traffic is deliberately not the tunnel." A naive implementation will let the kill switch block the split-tunneled apps when the VPN drops, or, worse, let the split-tunneled apps keep running while you believe the kill switch has sealed the device. Good clients handle the overlap explicitly. It is worth testing yours rather than assuming.
Testing is simpler than it sounds. Connect the VPN, confirm your exit IP on any IP-checking page, then kill the VPN process from your task manager rather than the app's disconnect button (that simulates a crash, not a clean exit). Reload the page. If it times out, your kill switch works. If your real IP appears, it does not, no matter what the settings screen claims.
The Leaks Neither Setting Fixes
A kill switch and split tunneling both operate on where your packets go. They do nothing about what those packets reveal, and there are two classic leaks that slip past both.
The first is DNS leaks. Your device asks a DNS server to turn domain names into IP addresses, and if those queries go to your ISP's resolver instead of through the tunnel, your ISP has a complete log of every site you visited even though the traffic itself was encrypted. A kill switch protects the route; it does not guarantee the resolver. You have to check that DNS is tunneled separately.
The second is WebRTC leaks. Browsers implement a real-time communication API that can discover and expose your local and public IP addresses directly, bypassing the routing table the VPN controls. This is a browser behavior, not a network one, so no amount of firewall rule at the VPN layer touches it. You handle WebRTC in the browser, with an extension or a configuration flag.
| Setting | Protects against | Does nothing for |
|---|---|---|
| Kill switch | IP exposure during a tunnel drop | DNS choice, WebRTC, what you excluded on purpose |
| Split tunneling | Latency, local-device access, VPN-blocked services | The privacy of every app you excluded |
| DNS in-tunnel | Your ISP logging your lookups | Routing, IP exposure |
What This Means in Practice
If your goal is to keep your ISP and the local network from seeing your traffic, turn on a system-level kill switch that fails closed at boot, confirm DNS is tunneled, and be sparing with split tunneling. Every exclusion is a deliberate hole, so exclude only things you have a concrete reason to exclude, and prefer inclusive rules only when you can enumerate everything that should be protected.
It also helps to be clear about what a VPN is for. A VPN moves the point where your traffic becomes visible from your ISP to the VPN provider. That is a real change if your threat model is a hostile local network, a censoring ISP, or a landlord router. It is not anonymity, and it does not encrypt anything end to end. The site you visit still sees a connection, the VPN provider still sees which sites you reach, and the content is only as private as the underlying protocol makes it. For an honest accounting of that boundary, see our piece on what a VPN does not protect, and for the protocol layer, WireGuard versus OpenVPN.
Where Haven Fits
Haven is not a VPN, and this is one of the places the distinction is worth stating plainly. A VPN protects the transport between your device and a server. Haven protects the message itself: your email and group chat are encrypted end to end, so the content stays private regardless of which network it crosses or whether a tunnel is up. The two solve different problems, and running both is reasonable. A VPN hides that you are connecting; end-to-end encryption makes it so that what you send stays yours even when the network is watching.