VPN Disconnected, Internet Still Blocked: Switch or Stale Rule?

The tunnel closes, the browser stops, and every other device on the same Wi-Fi still works, which rules out the router. That pattern has three plausible owners: a kill switch that was told to block, state left behind by a client that was removed, and a resolver or route that never got restored. They look identical from a browser window and need different repairs. Decide which one you have before running a network reset.

Two Very Different Blocked Internets

A deliberate block is a feature: while no tunnel is active, the client drops traffic so nothing leaks outside the protected path. An accidental block is a leftover rule, device or resolver setting that survived the client's exit. One is repaired by connecting or by disabling the policy on purpose, the other by cleaning up what was left behind.

The distinction shows up in the error rather than in the browser. A deliberate block usually produces an immediate refusal or a silent hang, while a leftover resolver produces a name-resolution failure that persists even when a ping to a literal address works. Neither is the same as a broken Wi-Fi connection, which would affect the other devices too. Order the checks by that difference: a literal address first, then a name.

What the Client Promised on Disconnect

Read the client's own settings for the meaning of disconnect, because several products separate a pause from a full stop. A pause keeps the block in place by design, while a stop may remove it. Some mobile platforms express the same idea as an always-on rule that blocks traffic whenever no VPN is connected.

Where the organisation requires protection, reconnecting the correct profile is the repair rather than bypassing the block. Check that the server name still resolves and that the endpoint can be reached through the exceptions the deployment documents, since a failed reconnect looks exactly like a persistent block.

Stale State From an Interrupted Removal

An uninstall that was interrupted, or a package removed while the tunnel was up, can leave a firewall chain, a routing rule, a resolver entry or a virtual adapter behind. The process is gone and the effects are not.

Start with the application's supported cleanup and repair path, then identify which component installed each remaining object before deleting it. Turning off the host firewall restores browsing and removes unrelated protection at the same time. A global network reset is worse, because it discards working office or Wi-Fi settings without naming the cause.

If two clients were installed, decide which one owns the policy. Two owners is how a block survives the removal of both.

Verify the Disconnected State, Not Just Browsing

Browsing working again is a weak acceptance test. Verify that the required policy is intact and that nothing else was silently weakened.

ip rule show
ip route show table all | grep -v '^default'
resolvectl status | head -n 20
sudo nft list ruleset | grep -A 6 'chain output'

Compare the routing rules, the resolver and the firewall policy with what a clean disconnected machine looks like. Then reconnect and disconnect through the normal workflow and repeat the reads, so the expected state is written down rather than remembered.

Keep that before-and-after pair in the ticket. The next person to see a blocked browser will need it more than another opinion about which client is best.