What is a VPN kill switch?
A kill switch is a setting that blocks all network traffic not going through the VPN tunnel. If the tunnel fails, the device loses internet access instead of quietly falling back to the normal connection and your real address. It does not make the tunnel better; it decides what happens when the tunnel stops working.
What happens when a tunnel fails without one
A tunnel works by changing the operating system's routing table. It adds a route that sends traffic to the tunnel interface instead of the network adapter. When that interface goes away, its routes go with it and the old default route takes over again.
Open programs do not know anything happened. They reconnect on their own within seconds, and their requests leave through the normal network with your real address, name lookups included. These are the usual moments when that happens:
- The VPN client crashes, or the system closes it to save battery or memory.
- The client or the operating system updates while connected.
- The device switches networks, for example leaving Wi-Fi range for mobile data.
- The first seconds after the device starts, before the tunnel is up.
When it is the server that stops
Not every failure means traffic leaks. WireGuard has no "connected" state in the usual sense, so its interface stays up even if the server stops. Every packet entering the interface goes through the cryptokey routing table described in the WireGuard paper.
A packet is encrypted for the peer whose allowed IPs match its destination. If it matches no peer, it is dropped, and the sending program gets an ICMP message saying the destination is unreachable.
So with AllowedIPs = 0.0.0.0/0 and the server down, packets go out encrypted to a server that never answers. Nothing leaves in the clear. The real risk is when the interface itself is removed, or when another program rewrites the routing table.
How a kill switch is built
The first approach is firewall rules that block every outgoing packet except three kinds: traffic through the tunnel interface, encrypted packets to the server, and traffic inside the device itself. Here is an example from the wg-quick(8) manual page, added to the [Interface] section:
PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECTThe first line rejects a packet unless it uses the tunnel interface, carries WireGuard's mark for its encrypted packets, or is addressed locally. The second line removes the rule when you bring the interface down yourself. The manual notes that most DHCP traffic still gets through, and that IPv6 needs similar rules with ip6tables.
The second approach is full isolation with network namespaces on Linux. The physical adapters stay in one namespace, and programs run in another that holds only the WireGuard interface. The paper itself notes that this prevents any leakage of clear-text packets, because programs see no other route at all.
The third approach is a setting provided by the system or the official app. On Windows, the WireGuard app adds firewall rules when the tunnel has a single peer with a /0 allowed IP, as its documentation explains. On Android, the VPN settings have two options, Always-on VPN and Block connections without VPN, described in the Android developer documentation.
Other forms you may meet
Some apps offer an app-level kill switch: you pick certain programs, and the app closes them if the tunnel drops. This acts after the drop rather than before it, so the first packets may leave before the program closes. It also leaves every program you did not pick unprotected.
When the tunnel runs on a router, the kill switch becomes a forwarding rule in its firewall: traffic from devices at home reaches the internet only through the tunnel interface. If the tunnel drops, every device loses its connection at once, with no setup needed on any of them.
Comparing the approaches
| Approach | System | What it protects | What to watch |
|---|---|---|---|
| Rules added by the VPN client | Windows, Linux, macOS | All traffic while the rules exist | If the client removes them when it fails, protection goes too |
| PostUp and PreDown rules | Linux | IPv4 traffic while the interface is up | IPv6 needs extra rules, and DHCP gets through |
| Network namespaces | Linux | Full isolation for programs inside the namespace | Manual setup; does not cover what is deliberately run in the physical namespace |
| WireGuard for Windows option | Windows | All traffic except DHCP, NDP and DNS to the configured servers | Works with a single peer whose allowed IP is /0 |
| Block connections without VPN | Android | All apps, even before the tunnel connects | Apps that bind themselves to a specific network lose their connection |
How to test it yourself
- Connect the tunnel and open the address tool linked at the end of this page to note the exit address.
- Cut the path to the server without using the app's disconnect button. End the app's process in the task manager, or switch from Wi-Fi to mobile data.
- Reload the tool's page. The right result is a failed load, not your real address.
- Repeat the test with a DNS leak check and for IPv6, since a kill switch that covers only IPv4 leaves two gaps.
- Restart the device with the tunnel set to start automatically, and make sure nothing gets through before the tunnel connects.
If your real address appears in step three, the kill switch is off or does not cover that case. Check its settings, or use one of the system-level methods described above.
What to look for in any app
- Blocking at the system level. A firewall or system setting, not logic inside the app's process, so protection survives if the app crashes.
- Full coverage. IPv4, IPv6 and name lookups together.
- Active from boot. Protection that starts only after you open the app leaves a gap at the start.
- An optional local network exception. Printers and file sharing need it, and it should be off by default.
- Known behaviour when you disconnect. When you turn the tunnel off yourself, you should know whether the block stays in place or goes with it.
- A clear state. You should know the outage comes from the kill switch, not a fault on your network.
Kill switch with syriaproxy
Our Android app works with both system options above; its account screen has a Kill switch row that opens the system's VPN settings directly. WireGuard is available for iPhone, iPad, macOS and routers, and the protocol is explained in What is WireGuard. The SOCKS5 and HTTP proxy apply only to the program they are set in, leaving the rest of the device's routes alone.
FAQ
Does it cut off all internet on the device?
Yes, when the tunnel fails, and that is the point. The connection comes back when the tunnel does, or when you turn the kill switch off yourself.
Do I need one with a proxy set in a single program?
A proxy does not change the routing table, so there is nothing for a kill switch to cut. The program usually fails if it cannot reach the proxy, unless it is set to fall back to a direct connection.
Does a kill switch slow the connection down?
Not noticeably. Firewall rules are simple and checked quickly for each packet. What users notice is only the outage when the tunnel fails.
Check your address now, before and after cutting the tunnel, with the free What is my IP tool.