There are lots of questions pertaining this error, and there is a suggested manual fix which works well, but there's no permanent solution. How can i permanently solve this? Im having this issue on a debian wheezy server, using OpenVPN client to connect to an OpenVPN server.

The suggested fix is the one below. Seems like, /dev/net is not automatically created and of course disappears on each reboot.

mkdir -p /dev/net
mknod /dev/net/tun c 10 200
chmod 600 /dev/net/tun

debian wheezy has been out of support since may 2018 (https://www.debian.org/releases/wheezy/), you should not be using it in 2020 any more for production.

Now, with that out of the way, you could add the commands that temporarily fix your issue adding those commands a bash script that you add to your root crontab with the @reboot nickname (man 5 crontab).

So create a bash script somewhere in your file system with something like this:


mkdir -p /dev/net
mknod /dev/net/tun c 10 200
chmod 600 /dev/net/tun

/etc/init.d/openvpn restart

Save it with 755 permissions and modify the root crontab:

# crontab -e

with this content at least

@reboot /path/to/where/you/saved/the/script

And after rebooting it should have started openvpn successfully.

|improve this answer|||||
  • 1
    As an alternative, the code snippet can be be written into /etc/default/openvpn file, which is sourced by /etc/init.d/openvpn script. – Anderson Medeiros Gomes Feb 15 at 2:05
  • nice, I do not have a debian wheezy handy to test, but this should be the preferred option if it works – natxo asenjo Feb 15 at 10:04

I think that a possible solution is to configure the system to load the tun kernel module during startup. In order to do so, list the tun module name in /etc/modules file:

# echo tun >> /etc/modules

udev is the system component that creates and maintains device nodes in /dev folder according to loaded kernel modules and connected hardware devices. I believe that by loading tun kernel module at boot time, the system will create the /dev/net/tun device node on every startup.

I hope it helps.

EDIT: I am a bit outdated. After launching a Debian Wheezy image published in Vagrant Cloud website, I figured out that udev in fact handles permissions, ownerships and symlinks regarding already existing device nodes. Device nodes are actually created by the kernel itself and are exposed to userspace through the devtmpfs pseudo-filesystem.

devtmpfs filesystem is mounted at initramfs time. The file /usr/share/initramfs-tools/init, which gets executed once grub extracts initramfs to memory, presents code that mounts a devtmpfs filesystem into /dev, falling back to a standard tmpfs filesystem if unsuccessful.

In addition, to have devtmpfs filesystem available, Debian Wheezy kernel is shipped with CONFIG_DEVTMPFS=y enabled.

|improve this answer|||||
  • On Busybox systems I have experienced that tun.o or tun.ko does exist in the default modules directory. In that case insmod /path/to/tun.o will be the way to go? – Lasse Michael Mølgaard Feb 14 at 6:11
  • Anderson, i tried the suggested solution, but it doesn't work – Joe Feb 14 at 16:39
  • @LasseMichaelMølgaard It depends on how the Busybox system is implemented. I am not sure on how device nodes are maintained in such systems. Anyway, modprobe and insmod are to kernel modules as apt-get and dpkg are to software packages, so insmod may work. – Anderson Medeiros Gomes Feb 15 at 1:52
  • @Joe Interesting. So I think that the only option is to automate the manual fix at boot time, as @natxo asenjo's answer. – Anderson Medeiros Gomes Feb 15 at 2:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.