No Internet After Uninstalling the VPN? Check Three Owners

The client is gone and the machine still cannot reach anything, which makes it tempting to flatten the firewall and start over. Do not. Blocking state can come from three different owners on the same machine, and each has its own removal path. Flushing everything at once removes the object you wanted gone along with protection you still need, and it also destroys the evidence of which owner caused the problem. Five checks, in order, keep that from happening.

Check 1: what is still there, and what it is for

Look for the three artifacts separately: a virtual adapter that still exists, a firewall filter or rule that still blocks, and a route or policy rule that still points at a tunnel that no longer exists. Their presence proves nothing on its own, because an intentional kill switch looks identical from the outside to an abandoned one.

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object Action -eq 'Block'
ip route show
ip -4 rule show

Write down the time connectivity stopped and whether the normal client can still start its tunnel. If the client can restore the tunnel and traffic returns, the block is doing its job and the problem is the client's state, not a leftover rule.

Check 2: which owner controls it

Each artifact has an owner. The virtual adapter belongs to the VPN client or its driver. The filter may belong to the client, to the platform's own firewall, or to a managed security product. The route may have been installed by the client at connect time and left behind.

On managed equipment, check the device policy before touching anything. A filter enforced by policy will be restored at the next check-in, so a local removal buys an hour and a compliance report. That conversation belongs with the administrator, not with the firewall UI.

Check 3: remove the narrowest thing that explains it

Start with the vendor's supported path: a repair install or a proper uninstall often cleans up generated state correctly, including filters a manual removal would miss. Read the recovery instructions for the installed version, because the sequence matters and an uninstall after a botched removal behaves differently.

If manual inspection is genuinely required, record the rule name, the interface and the stated purpose before changing anything, and remove that object by name. Removing every network adapter or flushing the entire rule set to target one client is how a support case becomes a rebuild.

Check 4: DNS and routes outlive adapters

Resolution state can survive the tunnel. A resolver still pointed at an address inside a tunnel that no longer exists produces timeouts that look exactly like a firewall drop, and the usual conclusion is the wrong one.

resolvectl status
ip route get 1.1.1.1
nslookup example.com

If the address resolves and a raw connection by IP works, DNS is the remaining problem rather than filtering. If both fail, go back to check one with the route and the filter in hand.

Check 5: retest both paths and put the diagnostics back

Verify ordinary connectivity first, then each remaining VPN profile through its own controls: connect, use it, disconnect, and confirm the host is back to plain connectivity. That round trip is the test that proves the abandoned block is gone rather than merely bypassed.

Finally, restore any diagnostic change you made along the way. A successful cleanup removes one abandoned dependency; it does not remove the host's general protection, and it should not leave a permanently relaxed firewall behind. Note which owner held the block, because the next uninstall will produce the same three candidates.