What Actually Happens When You Start a VPN on Linux

Press connect and three things change on a Linux machine: an interface appears, routes are installed, and the resolver starts answering differently. Most setup failures come from one of those three happening without the others, or from two programs disagreeing about who owns them. Understanding the sequence explains the failure faster than reading a client's log output.

An interface appears before anything works

A tunnel client opens a virtual interface and hands packets to it. A TUN device carries IP packets, which is what a routed VPN needs; a TAP device carries Ethernet frames, which is what a bridged design needs. The kernel module provides the device, and the client owns it for as long as the session lasts.

The interface coming up is not the same as the tunnel working. It can exist with an address while the peer is unreachable, which is why the interface list is the first check rather than the last. A device that reports itself up is describing the kernel's view of a virtual link, not the peer's willingness to answer.

Leave the supplied interface mode alone. Changing a TUN profile to TAP does not turn a routed server into a bridged one, and it usually produces a connection that establishes and forwards nothing.

Routes are installed by whoever owns the tunnel

Routes are the second change, and their ownership matters more than their content. A NetworkManager profile, a systemd unit and a hand-run client can all install routes, and two of them doing it at once produces a table that nobody can explain later.

ip -br addr show
ip route show
ip -6 route show

A full-tunnel profile replaces the default route; a split-tunnel profile adds more specific routes and leaves the default alone. Both are normal, and the second is why deleting a default route is a poor first test on a machine you administer remotely. Removing it is also the fastest way to lose the session you are using to fix the problem.

Read the table rather than assuming. A more specific route or a policy rule can send traffic into the tunnel while the default route still points at the physical interface, which looks contradictory until you read the whole table. That combination is normal for split tunnel and confusing for anyone expecting one line to describe the design. Look for the route that matches your actual destination, not the one that matches the diagram.

The resolver changes hands

DNS is the third change and the one most likely to be managed somewhere you did not look. On a desktop, NetworkManager may push resolver settings per connection. On a system using systemd-resolved, the settings are applied per link and /etc/resolv.conf may be a stub or a symlink rather than a file you should edit.

resolvectl status
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

If a manual edit to the resolver file disappears after a reconnect, that is the signal to find the component maintaining it and change the profile instead. Editing the generated file is a change that a reconnect will erase.

Private names usually need the internal resolver and the search domains the operator supplied. Substituting a public resolver can break the very resource the VPN exists to reach, and the symptom looks like a routing failure rather than a DNS one. Test the name and the address separately, because one working and the other failing tells you exactly where to look. That single comparison saves an hour of route debugging.

One manager per connection

The profile format decides which program can use it. An OpenVPN profile needs OpenVPN or a compatible plugin, and a WireGuard configuration has its own format with peer keys and allowed prefixes. An import dialog does not translate one into the other, whatever the file extension suggests.

Pick one manager and let it own the connection. Bringing the same tunnel up through two tools makes the route table and the reconnect behaviour ambiguous, and the second one to start usually wins in ways that are hard to reproduce.

Install the packages your distribution supports and obtain the profile from the operator. Treat it as a credential, because it usually contains a private key or equivalent material, and store it where the rest of your secrets live. A profile left in a downloads folder is a key left on a desk.

What to check when it is up but not working

With the interface up and the client reporting success, work outward: does the route table select the tunnel for the destination, does the resolver answer for the private name, and does the far side have a return path. Each has a separate command and a separate owner.

nmcli connection show --active
nmcli device status
wg show

The nmcli reference documents the status and connection commands if you need the full set. What matters here is the distinction between a profile being active and a device carrying traffic, because the two can disagree.

Reconnect once through the same manager before you call the setup finished, and check that DNS still works after a disconnect. A configuration that only works until the first network change is not finished, it is merely working at the moment.