OpenVPN precreated tun: compare the two ownership models

Someone precreated tun1, the profile says dev tun1, and the connection still will not attach. The name existing on the host says almost nothing, because attachment depends on the namespace, the device type, who owns the link and what the daemon is allowed to do. Reusing a device also forces a decision the default configuration hides: which component writes the addresses and routes. The failure modes of the two arrangements differ far more than the configuration lines do, so decide before editing a profile.

A name is not an attachment

dev tun1 asks OpenVPN for that named interface, and traditional userspace builds will try to open it. If the name does not follow the usual tun or tap pattern, the profile also needs a matching dev-type, because the type is never inferred from a string. A TAP device is not a TUN device with a different label: attaching the wrong one either fails outright or produces a link that carries frames nothing expects. Check the type before anything else, since every later check assumes the two sides agree about it. From there, confirm the process can actually open the device rather than merely see it.

dev tun1
dev-type tun

The network interface and /dev/net/tun are different objects: one is a link inside a namespace, the other is the character device a userspace program uses to attach. The Linux TUN/TAP documentation describes that attachment path and the ownership rules for persistent devices. A root shell that can run ip link proves only that the shell has privileges, not that the daemon has them. Ownership of the device node, the capability set of the service and the user it runs as all have to line up before the open succeeds.

A device that exists and cannot be opened is an ownership problem, not a routing problem. Treat it as one while debugging, or the afternoon goes into reading route tables that were never the issue.

Who configures the link: two ownership models

In the first model OpenVPN configures addresses and routes as part of bringing the connection up. That is the default behaviour and the easiest to reason about, because a single component creates the state and removes it again. In the second model an external manager owns the interface, and ifconfig-noexec stops OpenVPN from running its address-configuration commands and hands the parameters to scripts instead. The manager then has to apply the correct local and peer configuration itself, which is more work than the option name suggests. Choosing between the two is a question about who may change the link while it is up.

ifconfig-noexec covers addresses only: the routing table is untouched, and route configuration belongs to route-noexec. Treat the two directives as separate controls with separate owners, because setting one and assuming the other is a common source of half-configured links. Pick exactly one owner per layer, addresses in one place and routes in one place. A network manager and a VPN helper both writing addresses is how a disconnect deletes state the other side still depends on.

Inspect the device from the namespace that matters

Inspect the device from the namespace the VPN process runs in, not from the one your shell happens to be in. The two commands below answer different questions, and the difference shows up when a host sees an interface that a container cannot. Run them in the order given, because the second only makes sense once you know whether the link exists at all.

ip -details link show dev tun1
ip tuntap show

The first command prints the link as the kernel sees it, including flags and interface type, which is how you confirm this is the device you meant. The second lists persistent tun/tap entries, which exist without any process holding them. An interface waiting for its intended owner is a different situation from a live tunnel attached to another VPN, and only the second explains why your own attach fails. Find the process holding the device before changing anything, since a persistent entry and a busy interface have different fixes.

Multiqueue support is a specific driver arrangement with its own requirements, not permission for unrelated processes to share one interface. Another owner's live session is a coordination problem, and no profile edit solves it.

Two different kinds of persistence

Kernel persistence and persist-tun describe lifetimes that are easy to conflate and expensive to confuse. A persistent device exists independently of any process, so it survives a stop and can be reused by the next start. persist-tun keeps resources across supported soft resets inside one OpenVPN process, a much shorter horizon. Neither promises that stopping the service leaves routes and addresses in place, and an interface that remains visible is not evidence of a working encrypted session.

Confirm the backend as well, because a precreated interface says nothing about which implementation will open it. Community builds that carry the direct data path will try to use it unless the design says otherwise. Where a version supports the switch, disable-dco selects the userspace path instead; older engines and other clients have no such directive, so keep the version condition beside the option rather than assuming it applies.

What breaks when only startup is tested

An ownership agreement can pass the first test and fail the last one, which makes startup a poor check on its own. Watch two transitions instead: a soft reset, and a full stop followed by a start.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Startup is the easy case: the unit comes up, the link appears, and the status output names the profile that loaded. Attachment is the moment the daemon opens the device, so run the link check after the unit reports active rather than before it. If the link exists while the status is still activating, you are watching a persistent device nobody has attached to yet, not a working tunnel. Push real traffic through the link before moving on, because an attached interface with no usable route is still a failure.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

A soft reset should leave the session usable and the resources intact, which is the job persist-tun does. A full stop is where an external manager reveals itself: if the link or its addresses survive the stop, someone else owns them, and that is either the state you documented or the bug you just found. Record both observations beside the profile, so the next change starts from evidence rather than from a diagram.