VPN Says Connected but Nothing Routes: Two Places to Look

A tunnel can report connected while nothing reaches it, and the two facts live in different places. One is the route table, which may still send packets at a device nobody owns. The other is the resolver, which may still list a server on a link that has gone. The network change did not damage the profile, it orphaned the state belonging to the previous connection, and the repair depends on which of the two you are actually looking at.

First, Ask the Kernel Which Device It Would Use

A route listing shows what exists; a route lookup shows what would happen. Ask about a public address and read the device name in the answer, because that one field decides whether the packet goes anywhere useful. When the answer names a tunnel device, the kernel will hand packets to it even if no client process is still running behind that interface. When the answer names the physical adapter while the client claims to be connected, the tunnel is up and merely is not the chosen path.

The second case is the usual one after a cable replaces wireless, and it presents itself as a broken VPN.

ip route show default
ip route get 203.0.113.9

Read the default entries next, since a route added by the previous base connection can outlive a link change and sit in front of the new one. A default route through a device that is down is worse than no default route, because the kernel still prefers it. Note the metric beside each entry, as that ordering explains the preference faster than the interface names do.

Then Read the Resolver per Link, Not per File

Name resolution carries its own state and its own staleness. A resolver listing DNS servers per link keeps the servers of a tunnel link that is down but still registered, and every lookup then waits on a server that will not answer. The symptom is a network that feels dead while the route table looks perfect.

Inspect the per-link state rather than the file, because on many distributions that file is a symlink into the resolver and editing it either does nothing or is quickly overwritten. Look at which link owns which servers and which search domain, then ask whether the tunnel link should still be registered at all. If it should not, deactivate the connection that owns it instead of editing generated state by hand. A name that resolves while the route lookup sends packets elsewhere is a third and separate fault.

resolvectl status
resolvectl query app.internal.example

If addresses resolve and connections fail, the resolver is fine and the route is not. If addresses do not resolve at all, this is the right place to start.

How a Stale Route Survives the Change

The client does not own the network by itself. On a NetworkManager host a VPN profile is activated on top of a base connection, and the connection settings let that base name the VPN which should follow it. When the base changes because another profile becomes preferred, the tunnel follows onto the new base or is left without one.

A VPN profile does not bring itself up, so the pairing matters far more than the profile's own autoconnect preference.

Read the active list and note which base is up before touching the tunnel. If the base is listed and the tunnel is not, the route is missing rather than stale and the fix is activation. If activating the tunnel complains that no source connection exists, the base it was paired with has gone, so bring that up first or repair the pairing instead of retrying the tunnel. Retrying a profile whose parent is absent produces the same error every time, which is a useful signal rather than a nuisance.

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

Tell Stale State Apart From a Missing Parent

Three states explain almost every report, and each one needs a different repair. A default route through a device that still exists but no longer carries the tunnel is stale state, cleared either by deleting the entry or by cycling the profile responsible for it. A tunnel device whose client process has vanished is a cleanup failure, so the disconnect path deserves the attention rather than the routing table. No tunnel device at all means the parent or the pairing is missing and the route table was never involved.

Rebooting hides which of the three you had, which is exactly why it feels like a fix.

After the repair, ask the kernel for one public and one internal address, then query an internal name. When the address works and the name does not, you have found a domain-scope problem in the resolver rather than a routing one. Record which state you found, because the next network change will reproduce whichever one you left alone.