Culvert VPN

VPN kill switch on Android: why the OS should own it

Only the Android system can stop traffic leaving outside a VPN tunnel, so the real kill switch is Always-on VPN's block. Why in-app switches fall short.

Android how-tos · 4 min read · By Culvert VPN

A VPN kill switch stops your phone from sending traffic over the ordinary network whenever the VPN tunnel is not up. On Android, the only component that can actually do that is the operating system, through Block connections without VPN in the system VPN settings. A VPN app can control what goes into its own tunnel; it has no supported way to stop other apps going around it, and anything it does to try dies with it when the app is stopped. A kill switch that lives inside the app is therefore either a shortcut to the system setting or a weaker promise.

What the gap looks like

A VPN is not up all the time, even when you never turn it off. It is down for a moment in each of these:

  • After a restart, until the app starts and connects.
  • When the phone moves from Wi-Fi to mobile data or back, while the tunnel is rebuilt on the new network.
  • When the app crashes, or the battery optimiser stops it in the background.
  • When a session reaches its time limit and the app reconnects.

In every one of those moments, without a kill switch, apps carry on using whatever network is there. Messaging syncs, the browser finishes a page, a background update starts. Each of those connections leaves the phone with your real address and in view of the local network. It is usually seconds, but seconds is enough for the Wi-Fi's logs to record what you connected to. That is the leak a kill switch exists to close, and the IP leak post shows how to see it happening.

Why an app cannot close it

A VPN app on Android works through the VpnService API. When it connects, it asks Android to create a virtual network interface and to send every app's traffic into it; the app reads the packets from that interface, encrypts them, and sends them to the server. That is real control, but it is control over one interface. The moment that interface is gone, because the app disconnected, crashed or was killed, Android's routing simply goes back to the real Wi-Fi or mobile interface, and the app is not there to object.

There is no firewall API for ordinary apps. An app cannot say "drop everything that is not mine." It can hold the virtual interface open while it reconnects and quietly discard packets in the meantime, which is what the better in-app kill switches do, and that works for the reconnect case. It does nothing for the restart case, because the app is not running yet, and nothing for the killed-in-background case, because there is no app left to hold anything.

Android's own setting has none of these limits. It is enforced by the system underneath every app, it is in force from the moment the phone boots, and it does not care whether the VPN app is alive. Block connections without VPN walks through exactly what it blocks.

What an in-app "kill switch" toggle usually is

Read the description under the toggle. It is normally one of three things:

What it saysWhat it doesWhere it falls short
Opens Android's always-on settings for youNothing itself; you flip the system toggleNothing, if you actually flip it
Blocks traffic while reconnectingKeeps the tunnel interface open and drops packets in the gapReboot and app-killed gaps stay open
Blocks all traffic when the VPN is offSame as above, with a longer holdSame gaps; and a stale toggle can claim protection that ended when the app was stopped

None of these is dishonest as long as the app says which one it is. The problem is a toggle that says "kill switch" and lets you believe the phone is sealed when only the app's own process is. A cached "on" inside an app can outlive the state it describes: turn the system setting off in Settings and the app's toggle, unless it re-reads Android every time, still says on.

Setting the real one

  1. Open Settings > Network & internet > VPN. Samsung phones use Settings > Connections > More connection settings > VPN, Xiaomi phones Settings > Connection & sharing > VPN; on other brands, search Settings for "VPN".
  2. Tap the gear icon next to your VPN app.
  3. Turn on Always-on VPN, then Block connections without VPN.

That is the whole procedure. The always-on explainer covers what the first toggle changes, including the one side effect worth knowing in advance: with the block on, a new Wi-Fi network's sign-in page cannot load until you briefly turn it off.

What a good VPN app does instead

It tells the truth about the state. The useful version of a kill-switch screen on Android is one that reads Android's real setting every time the screen opens, says whether the block is on or off, and takes you to the system page to change it. It does not remember the answer, because a remembered answer eventually claims protection the user has since turned off. And it does not add a second toggle of its own, because two switches for one fact means one of them is wrong some of the time.

If the VPN keeps going down in the first place, the kill switch is doing its job by cutting your internet, but the underlying problem is elsewhere; VPN keeps disconnecting on Android lists the usual causes.

Culvert VPN ships no in-app kill switch on purpose, reports Android's actual block state on its Settings screen with a deep link to change it, and is on Google Play.

Questions people also ask

Is an in-app kill switch on Android useless?

Not useless, but weaker than it sounds. It can hold traffic while the app is alive and reconnecting, but it cannot survive the app being stopped, and it cannot cover the gap after a reboot. The system setting covers all three.

How do I know whether my kill switch is really on?

Open the system VPN settings, tap the gear next to the app and look at Block connections without VPN. That toggle is the ground truth; a toggle inside an app is only the app's claim.

Will the kill switch stop a DNS leak?

It closes the case where the VPN is down and DNS goes out unprotected. It does not fix a VPN that is up but sending DNS outside the tunnel, which is a separate problem covered by a DNS leak test.