Fix “Cannot open TUN/TAP dev /dev/net/tun”

arstech

If you run VPN software, WireGuard, OpenVPN, or any tunneling-based network service on Linux, you will eventually encounter this error:

Cannot open TUN/TAP dev /dev/net/tun: Operation not permitted

This message commonly appears on VPS servers, inside Docker containers, or in Proxmox LXC environments. It usually shows up when everything looks correctly installed, yet the service refuses to start.

This guide explains exactly what the error means, why it happens in real-world environments, and how to fix it step by step on Ubuntu, Debian, VPS, Docker, LXC, and Proxmox systems.

What does this error mean

The /dev/net/tun device is a virtual network interface used by the Linux kernel to create tunnel interfaces (TUN) and virtual Ethernet devices (TAP).

VPN software such as WireGuard and OpenVPN relies on this device to:

  • Create encrypted network tunnels
  • Route packets between virtual interfaces
  • Attach virtual networks to real interfaces

The error indicates one of three things:

  1. The TUN kernel module is not loaded
  2. The /dev/net/tun device does not exist
  3. The process does not have permission to access it

The key point: this is not a VPN configuration error. It is a system-level problem.

Why it happens

This issue almost always comes down to environment restrictions. Below are the real causes seen in production.

Kernel module not loaded

On bare-metal or full VPS systems, the tun kernel module may not be loaded automatically.

Without it:

  • /dev/net/tun will not exist
  • Any VPN service will fail immediately

Unprivileged containers

In LXC or Docker containers:

  • Access to /dev/net/tun is blocked by default
  • The kernel may support TUN, but the container is sandboxed

This is extremely common on:

  • Proxmox LXC (unprivileged containers)
  • Shared VPS platforms
  • Docker containers without NET_ADMIN

VPS provider restrictions

Some VPS providers disable TUN/TAP entirely for security reasons. In this case:

  • The device cannot be created
  • No workaround exists inside the VM
  • Only the provider can enable it

Incorrect permissions or missing device node

In rare cases:

  • /dev/net/tun exists but has wrong permissions
  • The device node is missing due to misconfiguration

Step-by-step fix

Follow these steps in order. Do not skip ahead.

Step 1: Check if /dev/net/tun exists

Run:

ls -l /dev/net/tun

Expected output:

crw-rw-rw- 1 root root 10, 200 /dev/net/tun

If the file does not exist, continue to Step 2.

Step 2: Load the TUN kernel module

Check if the module is loaded:

lsmod | grep tun

If there is no output, load it manually:

modprobe tun

Verify again:

ls -l /dev/net/tun

To make it persistent across reboots:

echo tun | tee /etc/modules-load.d/tun.conf

This fixes the issue on:

  • Ubuntu
  • Debian
  • Most full VPS environments

If modprobe tun fails, skip to Step 6.

Step 3: Verify permissions

Check permissions:

stat /dev/net/tun

Permissions should allow read/write. If they do not:

chmod 666 /dev/net/tun

This is safe and standard for the TUN device.

Step 4: Fix Docker containers

If you are running inside Docker, the container must have network admin capabilities.

Run the container with:

docker run --cap-add=NET_ADMIN --device /dev/net/tun ...

Or in docker-compose.yml:

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

Without these flags, Docker blocks access even if the host supports TUN.

Step 5: Fix Proxmox LXC containers

This is the most common failure case.

Unprivileged LXC (default)

Unprivileged containers cannot access /dev/net/tun.

You have two options:

Option A: Convert to privileged container (recommended)

Edit container config:

/etc/pve/lxc/<CTID>.conf

Add or ensure:

lxc.apparmor.profile: unconfined
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.auto: proc:rw sys:rw

Then bind mount TUN:

lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file

Restart container.

Option B: Stay unprivileged (not reliable)

Unprivileged containers may appear to work temporarily but often break after reboot or updates. Do not rely on this for VPN services.

Step 6: VPS provider check

If all previous steps fail, your VPS provider likely disables TUN/TAP.

Test on host:

cat /proc/modules | grep tun

If unavailable and modprobe tun fails, contact the provider and ask:

Is TUN/TAP enabled for my VPS?

If they say no, there is no software fix. You must:

  • Switch provider
  • Upgrade plan
  • Use a different environment

Common mistakes

Installing VPN software first

Installing WireGuard or OpenVPN without verifying TUN support wastes time. Always check /dev/net/tun first.

Assuming Docker supports VPN by default

Docker blocks network devices unless explicitly allowed. This is intentional.

Using unprivileged LXC for VPNs

This is the #1 mistake on Proxmox. VPN software requires kernel-level access.

Changing VPN configs instead of fixing the system

This error is never caused by:

  • WireGuard config
  • OpenVPN certificates
  • Firewall rules

Fix the system, not the app.

FAQ

Can I create /dev/net/tun manually?

No. It must be created by the kernel module. Manual mknod is not sufficient.

Does this affect WireGuard and OpenVPN equally?

Yes. Both rely on TUN. WireGuard may show different logs, but the root cause is identical.

Is this a security issue?

No. It is a permission and capability restriction, not a vulnerability.

Will this work on cloud providers like AWS or DigitalOcean?

Yes. Major cloud providers support TUN by default on standard VPS instances.

Can I fix this inside a shared hosting environment?

No. Shared hosting does not allow kernel-level devices.

Final checklist

Before restarting your VPN service, verify:

  • /dev/net/tun exists
  • tun kernel module is loaded
  • Permissions allow access
  • Container has NET_ADMIN capability
  • LXC container is privileged (if using Proxmox)
  • VPS provider allows TUN/TAP

If all boxes are checked, the error will be resolved permanently.

arstech

More Posts