Ubuntu Has No Internet After Removing a VPN App

Uninstalling the VPN client, rebooting, and then finding the browser unable to load anything is a common Ubuntu sequence. The tunnel is gone, but the policy that pointed traffic at it is not, and on Ubuntu those leftovers usually live in NetworkManager rather than in the package. A connection profile and a dummy interface created at runtime belong to no package, so removing the package does not remove them.

The tunnel is gone, the policy is not

A kill switch works by making the network unusable without the tunnel. When the client is removed while that state is active, nothing is left to turn it off. The result looks exactly like a broken network adapter and is usually a profile holding a route.

That is why reinstalling sometimes restores connectivity: it recreates the process that knows how to undo its own policy. A client removed while its switch was active left a state nobody is left to clear.

Read the objects the package never owned

Read the state before changing it. List devices, active connections and both routing tables, then look for a dummy device that reports connected or a default route pointing at one. IPv4 and IPv6 fail separately, so a working ping to an address with broken name resolution points at a different object than a dead route. A dummy device holding a default route explains the whole outage on its own.

nmcli device status
nmcli connection show --active
ip -4 route
ip -6 route

Write down what you find, because the fix is to delete one specific object rather than to reset everything. Anything broader risks a second outage. That is the difference between a repair and a guess.

An empty routing table with a connected device is a different fault, and it points at DHCP rather than at a leftover profile. Read the lease before editing anything.

Delete the profile, not the keyfile

Delete the profile through NetworkManager rather than removing the keyfile. Deleting the file leaves the in-memory profile active until the next restart, which makes a correct repair look unreliable. Then restart the service and re-read the device list. The restart is what makes the deletion real.

sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManager

If a dummy link survives, remove that link too, then test an address and a name separately. Clean routing with a failed name points at DNS, while a failed address points at a route or a firewall.

Check the boot-time hook before it repeats

Some leftovers reinstall themselves at every boot. A hand-written unit or an if-up script that adds firewall rules keeps doing so after the package is gone, so the outage returns and the earlier repair looks like luck. Search the unit files and the network hooks before rebooting again. The unit name is usually the giveaway.

systemctl list-unit-files | grep -i vpn
grep -rl -i vpn /etc/systemd/system /etc/network/if-up.d

Remove or mask the specific file, then reboot once and confirm the tunnel-free state is what you want. That final reboot is the test, because a fix that only survives until the next boot is not a fix. Keep the note with the machine afterwards. The nmcli reference covers the device and connection commands used above.