OpenVPN on a VPS: no /dev/net/tun device to open

The first start fails with a message about /dev/net/tun or a TUN/TAP device that cannot be opened. Certificates have not been read yet, so nothing in the profile is implicated. The daemon is asking the kernel for an object that this guest does not have.

That object is a character device backed by the tun module. Whether you can create it depends on who owns the kernel.

What the daemon asks the kernel for

OpenVPN opens /dev/net/tun and asks the driver for an interface. The driver is the tun module, and the device node is the handle userspace uses to reach it. If the module is not loaded, the node may be missing or the open may fail. Neither condition is fixed by editing server.conf.

Read the error as a platform question first. A configuration error appears after the device opens, not before.

VM or shared-kernel guest

On KVM, Xen or another full virtual machine you control the kernel. You can load modules and create the node. On OpenVZ, Virtuozzo or an LXC-style container, the guest shares the host kernel, so root inside it cannot load a module the host has not loaded.

The same failure therefore has two very different owners. In the first case you can fix it from inside the instance. In the second you are asking the host, or the provider, to expose something.

Run ls -l /dev/net/tun, lsmod | grep tun and ip -brief link show before deciding which case you are in.

On a VM, load the module at boot

On a virtual machine, modprobe tun usually creates the device node. Check that it appears, then persist the load through the distribution's modules configuration instead of relying on a command typed once. A node that vanishes after a reboot turns into the same ticket next month.

Also check that the kernel you booted has the module available at all. A stripped-down vendor kernel can lack it.

If the node exists but the open still fails, permissions and the device's major/minor numbers are the next suspects. Those are local fixes, not provider requests.

In a container, the host owns the device

In a container, the device and the capability are two separate requirements. The runtime must pass /dev/net/tun through, and the container needs the network capability to create an interface. A rootless runtime that grants neither will keep producing the same open error however the profile is written. Many OpenVZ hosts expose a TUN/TAP toggle in the customer panel, and enabling it plus a restart is often the whole fix.

Ask the provider two precise questions: is the tun module loaded on the host, and is the device available inside this instance? A vague ticket gets a vague answer.

Why rebuilding the module rarely helps

Building a module inside the guest rarely helps. Compiling needs the configuration of the exact running kernel, and /proc/config.gz is optional and often absent on minimal images. Even a working module cannot be inserted into a kernel the container does not own.

After the device appears, restart the service and confirm the interface before testing traffic. Seeing tun0 shows that the daemon opened the device. It says nothing yet about forwarding, firewall rules or the routes clients receive.

Those are separate questions with separate evidence. A missing device is a prerequisite failure; a tunnel that exists but carries nothing is a policy failure.