Kill switch: what it does, when it is missing, and why ‘allow local network’ turns it off.
State of things on 19 October 2026: Pevnost is in private beta. The first server, prg1 in Hluboká nad Vltavou (WEDOS data centre), has been live since 18 October; a first short test measured around 300 Mbit/s. Every new account gets two free hours (one trial per connection, one device), then 120 CZK / €5 for 30 days or 1 200 CZK / €50 a year. Pay with Bitcoin on-chain (preferred), by card through Stripe or by bank transfer; Lightning is planned and Monero is coming. Windows app 0.3.1 beta, Android app 0.1.0 beta. Last reviewed 19 October 2026.
A kill switch is the part of a VPN that stops your traffic from leaving outside the tunnel when the tunnel cannot carry it. It is not a reaction that fires when something breaks; it is a firewall rule that is in place all the time the VPN is on: traffic into the tunnel and to the VPN server is allowed, everything else is blocked. That is why it works, and why some settings, including one in our own app, quietly remove it.
WireGuard has none of its own
WireGuard encrypts and routes. With AllowedIPs = 0.0.0.0/0, ::/0 all traffic is routed into the tunnel, and if the server stops answering, packets still go into the tunnel and die there. Leaks happen when the tunnel interface disappears: the app crashes or restarts, the network changes, the system boots before the tunnel is up, or an app picks a network interface itself. Covering those cases is the job of the platform or the app.
Windows: only with a /0 route
The official WireGuard for Windows, and the tunnel code inside our Windows app, install firewall rules that block untunneled traffic and DNS to other resolvers. They do so only when the configuration routes everything: a peer whose AllowedIPs contains 0.0.0.0/0 or ::/0. Write 0.0.0.0/1, 128.0.0.0/1 instead and you get the same routing with no kill switch. The rules exist while the tunnel is active; deactivate the tunnel and normal traffic flows again. They also block the local network, so the printer, the NAS and the TV disappear while you are connected.
What “Allow local network” does in our app
That last point is why our Windows app has a setting labelled Allow local network, with the caption “Turns off the kill switch: traffic can leave outside the tunnel when the server is unreachable”. It is off by default. When you turn it on, the app routes everything except private and local ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, multicast, and their IPv6 equivalents) into the tunnel. There is no longer a /0 route, so the tunnel code does not arm its firewall rules, and DNS leak protection goes with them. Your LAN works; if the tunnel drops, everything else can leave over the normal network until the app brings the tunnel back.
Other VPNs write their own firewall rules that allow the LAN and block the rest. We build on the official WireGuard tunnel code, which offers all or nothing, and for now we prefer that to a home-made firewall layer. Our advice: leave the setting off; when you need to print, turn it on briefly or disconnect for a minute; on public Wi‑Fi never turn it on, because the “local network” there is strangers.
Android: the system setting
Android has the strongest kill switch of any phone platform, and it is in system settings: Settings → Network & internet → VPN → gear next to the app → Always-on VPN and Block connections without VPN. It applies to every app, including at boot before the VPN app starts. Our Android app relies on it and does not reimplement it. Published research from 2022 showed Android still sends some connectivity checks outside the VPN in this mode; Google described that as intended. A captive portal may also fail to load until you switch the block off for the login.
iPhone, iPad and Mac
The official WireGuard app offers On-demand activation, which brings the tunnel back on every network. It does not expose a full block of non-VPN traffic, so short gaps when switching between Wi‑Fi and mobile data are possible. Published findings also say iOS does not close connections that were already open when the VPN starts. Turn on the tunnel before you open the apps that matter.
Linux
With wg-quick and a /0 route, traffic stays in the tunnel while the interface exists. To stop applications sending around it, the wg-quick manual suggests:
PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -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 REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
These rules go away with wg-quick down. For protection while the tunnel is down, use permanent nftables rules.
How to test it
Start a continuous ping (ping -t 9.9.9.9 on Windows), then switch networks, for example from Wi‑Fi to your phone’s hotspot. With a working kill switch the pings fail until the tunnel is back, and an IP check page never shows your own address. On Android, with both system options on, switch the tunnel off in the app: the phone should lose the internet. Then run the full leak test. Why this matters on hotel and café networks is in VPN on public Wi‑Fi.