Why apt-cache Shows Installed (none) for Your VPN Package

A VPN package that reports Installed: (none) is not missing; it is simply not installed. The line that decides whether you can install it is Candidate, which APT derives from the indexes, the suite name, the architecture and any pinning rules in effect. Most reports of a vanished VPN package turn out to be a candidate problem rather than a packaging problem. Read both lines before you touch a single source entry.

I check the candidate first because it costs one command and rules out half the usual guesses.

What the policy output is telling you

apt-cache policy reads the local package cache, not the network. It prints the installed version, the candidate version, and a table of every index that offers the package with the priority attached to it.

apt-cache policy openvpn
apt-cache madison openvpn
apt list -a network-manager-openvpn

The candidate is the version APT would pick right now. madison lists what each source offers with its priority, which is how you spot a package that exists in an index but loses the pin contest. The apt-cache manual documents both as cache reads, so neither one proves the mirror is reachable at this moment.

If the candidate line is empty or reads (none), nothing in the configured sources is eligible for this system as configured.

Four reasons a candidate disappears

In practice the cause is almost always one of four things, and each has a different fix.

The suite name in your sources has to match the distribution the package was built for. A Debian bookworm system pointed at a trixie mirror, or an Ubuntu release that was renamed in a sources.list.d file during an upgrade, resolves nothing for packages that exist only in the other suite. Compare lsb_release -cs with the suite field in each entry.

APT only sees packages built for the architectures dpkg knows about. A 32-bit container, an arm64 image or a Raspberry Pi install asking for a package that ships only for amd64 gets an empty candidate rather than an error message. dpkg --print-architecture and dpkg --print-foreign-architectures tell you which set you are actually in.

Components matter too. A package in contrib or non-free is invisible when only main is enabled, and Ubuntu's universe behaves the same way. The index exists and the package is in it; your enabled component list just does not include it.

Pinning is the quiet one. A file in /etc/apt/preferences.d can cap a package below the install threshold, and then a perfectly good candidate vanishes from the output while the index still lists it. Because policy prints the priorities next to each source, a package whose every source carries a low pin number is the giveaway.

Stale indexes look like missing packages

The cache is a snapshot. If the last apt update failed on one index, queries keep answering from the older copy, and the package you expect may not be in that copy.

apt update prints per-index errors, so read them instead of scrolling straight to the last line.

A refresh that fails on a signature error, an expired release file or an unreachable mirror leaves the previous index in place. That is a sensible design, because it keeps a working cache when a mirror is briefly down. The side effect is that a search can succeed while the repository is offline. It also means the absence of a package proves nothing until you know when the index was last fetched. Check the file dates under /var/lib/apt/lists before you blame the package name.

Name the package you actually need

OpenVPN is a daemon, and the pieces people usually want are separate packages.

The engine, the NetworkManager plugin and the desktop editor are three packages with three names, and the plugin has a GTK variant whose name differs between distributions. apt-cache search --names-only openvpn matches names and provided names instead of descriptions, which is what you want when you roughly know what the thing is called.

If the name is genuinely unknown, search descriptions once, then go back to exact names. Do not append a -gui suffix borrowed from another distribution and conclude the package no longer exists.

Change sources last, then verify the transaction

Adding a repository changes who supplies your updates, so it belongs at the end of the investigation, not the start.

Before that, confirm release, architecture, component and pin state. Write down which of the four you checked, so the next person does not repeat the sweep. If all four are right and the candidate is still missing, the honest conclusion is that this release does not ship that package. The remaining options are a backport, a vendor package or a different supported release, and each of those is a deliberate choice rather than a guess.

When the candidate does appear, simulate before you commit: apt-get install --simulate with the package name shows what would be pulled in and what would be removed. Package availability, installation and a working tunnel remain three separate stages, and the tunnel still needs its profile, credentials, routes and DNS before it carries traffic.