VPN client uninstalled, but the tunnel still starts at boot

Your distro removes the package, your menu loses its entry, and the tunnel still comes up after the next reboot. A commercial VPN client leaves pieces the package manager never tracked, so a clean removal is not the same thing as a clean machine. Four of those pieces account for almost every ghost connection: a unit, a connection profile, a privileged helper and a vendor repository. Read all four before deleting anything, then remove each one through the component that owns it.

What the uninstaller never recorded

A package manager removes the files it wrote down and nothing else. It has no record of a connection profile that the client created at runtime, of a unit enabled after installation, or of a helper that registered itself while running with elevated rights. Each of those belongs to a different subsystem, and each can outlive the package by a reboot or several. That gap explains why a tunnel can be healthy while the software that produced it is gone.

The leftover always has an owner, whether that is systemd, NetworkManager, the repository configuration or a per-user autostart entry. Locating the owner first is what keeps a cleanup from becoming a half-configured machine. Deleting files directly usually works until the owner regenerates them, which is why the commands below begin with queries.

Four owners, read-only first

Begin with queries rather than deletions, and note the exact names that come back. Vendors often ship a versioned payload beside a meta-package, so one product can appear under two names. A name that shows up in both lists is a single product with two owners, and both of them need removing. The first batch covers packages and units, which is where most leftovers become visible.

dpkg -l | grep -i acmevpn
systemctl list-unit-files | grep -i acmevpn
systemctl list-units --type=service --state=running | grep -i acmevpn

The second batch covers the two components that survive a purge most often, namely the connection profile and the vendor repository. Read the UUID column rather than the name, because duplicate names are common and the delete command expects the identifier. The repository line is worth reading even when you do not remove it today, since a dead vendor host can break an unrelated installation months later. Neither list changes anything, which is the point of running them first.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show --active
grep -ril acmevpn /etc/apt/sources.list.d/ /etc/apt/sources.list

A process still alive after the purge is either an active unit or another program's child. Read the process table and its parent chain before blaming a service that no longer exists. Per-user autostart entries need the same pass, and they appear only in a fresh login shell rather than in a root session.

Three verbs that are not interchangeable

Stopping ends the current run, disabling removes the boot-time links, and masking points the unit at /dev/null. Only the third also blocks activation through a socket, a timer or a dependency, which makes it the strongest of the three. The order matters while you are still deciding what to do with the machine. Masking is the right state during that decision, because it fails loudly instead of starting quietly at the next boot.

Unmask before reinstalling, or the new package will look broken for a reason nobody wrote down. The same caution applies to packaging differences: one build ships a unit that can be stopped, while another leaves no service at all. Establish which packaging you have before choosing a verb, because the cleanup path differs between them.

Wildcards are how you delete the wrong profile

Delete the profile with the UUID you recorded, and never with a wildcard. The keyfile directory also holds every Wi-Fi and Ethernet profile on the machine, so a broad match removes things you still need. A keyfile deleted by hand may also be regenerated by whichever policy owns it, which makes the deletion look ineffective.

nmcli connection delete uuid <uuid>

Export the gateway and identity first if that profile is the only copy you still have, since a local delete revokes nothing on the server. The repository follows the same rule: remove the single vendor file and its keyring, then refresh the package lists and retry the installation you actually wanted. Leaving a stale third-party entry in place can pin an old dependency or fail to answer at all. Both removals are small, and either one can be undone from the copy you keep.

What still runs after the reboot

Reboot before declaring victory, then look for artefacts rather than for the application. A tunnel interface, a stale split route and per-link DNS left behind by the old client each need their own command. All three can outlive a purge that removed every package successfully.

ip link
ip route
resolvectl status

Open a fresh login shell as well, because an autostart entry only fires there. Then read /etc/NetworkManager/dispatcher.d/ for a script that brings a connection up whenever an interface changes state, which explains a tunnel returning with no service behind it. If something still dials out, trace the process to its parent instead of deleting files until the symptom stops. Cleaning the machine and revoking the account remain separate jobs, and only one of them is finished when the reboot looks quiet.