VPN Kill Switch: How It Works on iPhone and Desktop

What a kill switch actually does

A VPN encrypts the path between your device and the VPN server. As long as the tunnel is up, your traffic flows through it. The interesting question is: what happens the moment the tunnel goes down?

Without a kill switch, the answer is "your traffic falls back to the regular internet connection." The OS routes packets through whatever interface is available — your home Wi-Fi, your cellular link, the hotel network — and your real IP is exposed for every connection your apps make in that window. Streaming apps, email clients, background sync, push notifications: all of them keep talking, just without the protection you thought you had.

A kill switch changes that default: when the tunnel drops, all non-VPN traffic is blocked until the tunnel comes back up. The user sees apps stop loading; nothing leaks.

When the tunnel actually drops

A kill switch sounds like an edge-case feature, but the underlying event happens more often than people realize:

• Server-side restart. VPN servers get patched and rebooted. WireGuard reconnects in under a second, but during that second every app on your phone might try to send something.
• Network handoff. You walk out of Wi-Fi range and your iPhone switches to LTE. The tunnel has to renegotiate over the new IP. Brief gap.
• Sleep/wake. Your laptop closes; your phone screen turns off. The OS suspends network activity. On wake, there's a window before the VPN client realizes it needs to reconnect.
• Throttled or blocked UDP. Some networks rate-limit or drop UDP. The tunnel survives most of the time, but every now and then a packet loss spike causes a brief disconnect.

Each of these is short — usually under a second — but a second is plenty of time for:

• A push notification to fetch from a server, revealing your IP.
• A streaming app to send a heartbeat to its analytics endpoint.
• A messenger to register your "online" status from your real IP.
• Background sync (iCloud, Dropbox) to phone home.

Whether these tiny leaks matter depends on your threat model. For someone using a VPN just to bypass a content geo-block, they're irrelevant. For someone whose VPN is part of a privacy posture, they're the whole point of the kill switch existing.

How a kill switch is implemented (on iOS)

iOS doesn't have a user-facing setting called "kill switch." It has something closer to it called Always-on VPN and the includeAllNetworks flag in the Network Extension framework.

There are two layers worth understanding:

Layer 1: On-Demand Rules

Configured per-VPN-profile in iOS Settings. They tell the OS: "automatically connect this VPN whenever the device is on certain networks." The simplest useful rule is connect on every Wi-Fi network that isn't my home network. This is not a kill switch — it's an automatic-connect rule. It can also include disconnect on cellular, connect on a specific SSID, etc.

Layer 2: includeAllNetworks

A flag the VPN app sets when configuring its Network Extension tunnel. When true, the OS routes all traffic through the tunnel — including system-level connections that would normally bypass the VPN (Apple Push Notification Service, system updates, certain Apple services). And critically: when the tunnel is down, those connections are blocked instead of falling through.

This is the closest thing iOS has to a true kill switch. It's stronger than the desktop equivalent on Windows or macOS, because it also covers paths that other OSes leave open.

The combination "On-Demand rule to auto-connect + includeAllNetworks=true" is what gives you the experience of: "the moment my VPN drops, the internet stops working until it comes back."

What iOS does NOT have

iOS does not have a "block all non-VPN traffic if VPN is disabled" toggle that survives a manual disconnect. If the user actively turns off the VPN, the kill switch is gone with it. This is by design — Apple won't let an app permanently take over networking against the user's intent.

There's also no per-app kill switch on iOS (Android has this in some forms). It's all-or-nothing: either the tunnel is up and traffic flows through it, or the tunnel is down and traffic is blocked.

How a kill switch is implemented (on macOS, Windows, Linux)

On desktop, a kill switch is usually implemented as a firewall rule that the VPN client installs on top of the system firewall:

• macOS: PF (Packet Filter) rules that allow traffic only through the utun tunnel interface.
• Windows: WFP (Windows Filtering Platform) rules at the kernel level.
• Linux: iptables or nftables rules that drop any traffic not destined for the tunnel.

The principle is the same: the firewall denies all egress traffic by default; the VPN client adds an exception for the tunnel interface. If the tunnel goes down, no exception applies, and all traffic gets dropped.

The quality difference between VPN clients is largely about how robust these rules are: do they survive a network change? a sleep/wake cycle? a forced quit of the VPN app?

What makes a kill switch good vs broken

The patterns to look for:

Survives sleep/wake. Many low-quality VPN clients install kill-switch firewall rules at connect time and remove them at disconnect time. If the OS suspends the VPN process during sleep, the firewall rules can disappear silently. A good client installs rules at the OS level that survive process restart.

Survives network change. When you move between networks, the routing table changes. A good kill switch is interface-based ("only allow traffic through utun0"), not IP-based ("only allow traffic to VPN-server-IP"). The IP-based variant breaks the moment the routing changes.

Boot-time enforcement. The strongest kill switch is enabled before any user app starts after boot. On iOS, includeAllNetworks + On-Demand achieves this. On desktop, this requires the VPN client to start as a system service before user processes.

Covers IPv6. A surprising number of kill switches block IPv4 traffic but leak IPv6. If your network has IPv6 and the kill switch doesn't handle it, you're leaking.

Covers DNS. Some kill switches block IP traffic but allow DNS to pass through. This is a partial kill switch and arguably a misfeature — it lets DNS lookups continue going to your ISP's resolver during outages.

When you don't need a kill switch

If your only reason for using a VPN is to make a specific app work (region-locked streaming, sometimes-blocked websites), a kill switch is overhead you'll feel as "apps mysteriously stop working." Most of the time you'll just want to reconnect.

The strong case for a kill switch is when the VPN is part of an always-on privacy posture: you don't want your real IP exposed at all, and you'd rather have brief network outages than brief leaks. For that use case, the kill switch isn't optional — it's the whole point.

What VeilTun does

VeilTun's iOS client uses Apple's Network Extension with includeAllNetworks enabled by default. Combined with the default On-Demand rule (auto-connect on any untrusted Wi-Fi), the user experience is: the tunnel comes up before any app traffic flows, and during any brief reconnect the OS-level firewall holds. We expose this in the UI as a single "Always-on protection" toggle so users aren't navigating Apple's terminology.

If you want to verify the kill switch is working: connect to the VPN, then go to Settings → VPN, manually disconnect, and immediately try to load a webpage. With kill switch active, the page should fail until you reconnect.

The bottom line

A kill switch is a small piece of plumbing that addresses a real failure mode: the few seconds of leakage when a VPN tunnel drops. Whether you need it depends on what you're using the VPN for. If privacy is the actual goal — and not just unblocking content — you want one, and you want one that handles sleep, network change, IPv6, and DNS correctly. Most consumer VPNs ship something they call a kill switch; not all of them ship one that actually works.