VPN Says Connected but the Default Route Is Dead

The client reports connected, the tray icon looks normal, and nothing loads. It started right after you moved from Wi-Fi to a cable, or right after a distribution upgrade finished. What broke is not the profile but the state that was built for the previous base connection. The kernel still has a default route pointing at a tunnel device nobody owns, or the resolver still lists servers on a link that has gone away. Both failures look like a dead network and both are repairable in place.

The stale pieces were already wrong before you noticed. Unplugging a cable just made them visible.

Ask the kernel where a packet would go

Route listings are difficult to read because they enumerate everything the system knows, including entries that no longer apply. A route lookup answers the only question worth asking: which device carries this particular packet right now. If the answer names a tunnel device, the kernel will use it even though no client process is alive behind it, and the packet falls into an interface nothing maintains. If the answer names the Ethernet adapter while the client insists it is up, the tunnel exists but lost the selection, which is the usual outcome of switching from wireless to wired.

Run the lookup twice, once for a public address and once for an internal one, because a split-tunnel policy can route one honestly and drop the other.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

The resolver keeps the dead link as well

On a systemd-resolved host, DNS servers belong to links rather than to one global list. A VPN link that has gone down can stay registered with its servers for a while, and every lookup then waits on an address that will never answer. That delay feels like a dead network, and it sends people looking at routes when the route is fine.

resolvectl status
resolvectl query intranet.example.com

Read the per-link blocks and identify which link owns the domain in question. A tunnel that is up but not the owner of the internal domain forwards internal names to the public resolver, and the symptom is indistinguishable from a routing fault.

Repair the registration rather than /etc/resolv.conf. On current Ubuntu and Fedora installs that path is a symlink into the resolver's runtime state, so an edit is either ignored or overwritten at the next network event.

A VPN never starts on its own

NetworkManager brings a VPN up on top of a base connection, and it learns which one to follow from connection.secondaries on that base. The connection settings reference is explicit that autoconnect is not implemented for VPN profiles. That is the whole mechanism behind this class of failure: change the base, and the VPN has to be re-paired or reactivated by hand.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

When the active list shows the base without the VPN, the tunnel is not active at all and the route was never installed rather than left stale. When activation complains that no source connection exists, the base it was paired with has disappeared, so fix the base or the pairing first and stop retrying the VPN.

An upgrade can drop settings without a message

Upgrading a distribution replaces the client and often its NetworkManager plugin, while the saved profile keeps whatever property names it was written with. Anything the new plugin no longer recognises is skipped in silence. The profile still activates and the device still appears, but the route that used to arrive with it never does.

Hand-written hooks move as well. A script that installed a route at a predictable moment in the old sequence may now run before the interface exists, or after the client has already timed out.

Compare the live profile against the plugin you actually have instead of against the behaviour you remember. If a key is gone from the documentation, move the work into a dispatcher script or a supported replacement rather than restoring the old property.

Three states, three different repairs

Decide which state you are in before touching anything, because a reboot destroys the evidence and the fault returns at the next network change.

Finish with one lookup for a public address, one for an internal address and one name query. If the addresses work and the name does not, the remaining fault is domain scope in the resolver, and the route table was never the problem.