VPN App Crashed: Is Your Kill Switch Still On?

Start where a user starts: the client window is gone, the tray icon disappeared, and the browser either loads or it does not. That observation alone cannot tell you whether the block survived. The answer depends on which component holds the rules, whether that component died with the window, and whether the platform keeps enforcement outside the application. Walk outward from the window to the process, then to the firewall, then to the actual path.

Do not reboot first; a reboot usually destroys the evidence.

Start From What Is Still Running

Open the process list before touching anything. A desktop client usually splits into a user-interface process and a service or daemon, and a crash in the first does not necessarily stop the second. On Windows the service may still be listed, on Linux the unit may still be active, and on Android the tunnel is owned by the system once consent is given. Read those three facts in that order.

If the daemon is alive, the tunnel probably is too, and the missing window is cosmetic.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Read the Block From the Enforcer, Not the App

If the client implements its kill switch by inserting firewall rules, those rules belong to the operating system and survive the process that created them. A crash then leaves you blocked with no interface to turn it off, which looks like a broken network rather than a protection. If instead the block lives inside the client's own packet path, killing the process removes the block at the same moment.

Android handles this differently again: always-on VPN with lockdown is a platform setting, so the block persists independently of the app process, and the system may restart the service. Consult the platform documentation for the exact behaviour rather than assuming it matches a desktop client.

Tell a Clean Exit From a Crash

A normal Quit usually runs the client's shutdown path, which removes rules and closes the tunnel on purpose. A crash skips that path and leaves whatever the enforcer already installed. The difference shows up in rule timestamps relative to the process exit, and in whether a stale tunnel interface still exists with no owner.

That distinction decides your recovery: a clean exit may need a fresh connect, while a crash may need the leftover rules removed through the client's supported repair action.

Recover Without Breaking Other Controls

Restart the client through its documented workflow, then check both halves of the requirement: the tunnel carries traffic, and the block still applies when it should. Flushing the whole firewall to regain connectivity also removes unrelated controls, and that trade is rarely worth it.

For a repeat crash, collect the client version, the platform build and the scoped logs the vendor asks for. A client profile, private key or full connection log for another account is not needed for a crash report, and including it turns a support case into a data-handling problem.

One crash is not evidence of a leak. Evidence is an observed packet leaving by a path that the policy was supposed to prevent, captured at the moment the client was down. Test that deliberately, with a harmless destination, and write down which enforcement layer held.