This is a guest post from Timothy O’Connell.
I work mostly on Debian systems (workstations and servers). Recently, during a lull, I decided to throw caution to the wind and go ahead with a reasonably large (<= 1000MB worth of new and upgrade packages) dist upgrade on my personal workstation at the office. Everything went pretty well (as well as could be expected, anyway) and my post-upgrade reboot was mostly uneventful.
OpenVPN, however, did not start. And, not to besmirch the character of its developers or its package maintainers (“it’s not you; it’s me”), I wasn’t exactly surprised. OpenVPN is definitely on my “usual suspects” list. And if you run Debian testing or sid, it should be on yours as well.
And if it’s going to be on your “usual suspects” list and be one of the first apps that you expect to fail, you ought to have a trouble-shooting routine. Or at least an idea of where to start.
Generally speaking, when my OpenVPN fails to initialize and connect during boot, I see the following when I tail /var/log/openvpn.log:
Mon Jan 12 11:33:31 2009 Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2) Mon Jan 12 11:33:31 2009 Note: Attempting fallback to kernel 2.2 TUN/TAP interface Mon Jan 12 11:33:31 2009 Cannot allocate TUN/TAP dev dynamically Mon Jan 12 11:33:31 2009 Exiting
And, honestly, this is the error you’re most likely to receive following an kernel upgrade: something will go “kablooie” as the various new modules are initialized, your dev node won’t be created and you’ll end up without support for the virtual device that will allow you to create your tunnels.
First things first, stop and start OpenVPN with its init script and tail the logs, just to eliminate the possibility that cosmic rays struck your machine during boot and the failure was a fluke:
gonzo:/etc/openvpn# /etc/init.d/openvpn stop Stopping virtual private network daemon:/etc/init.d/openvpn: line 68: kill: (3047) - No such process client. gonzo:/etc/openvpn# /etc/init.d/openvpn start Starting virtual private network daemon: client.
If you wind up with the same failure message, it’s time to look for modules.Do one of these:
# lsmod |grep tun
If you don’t see something like the following, odds are good that your module just plain didn’t get initialized:
tun 8292 1
You’ll want to double-check that, of course, by grepping your dmesg. If you don’t see something like the following in your dmesg boot log, then it’s probably time to take the action recommended below:
gonzo:/etc/openvpn# dmesg |grep tun [ 19.292084] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 [ 19.292466] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4 [ 20.700088] hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4 [ 492.481978] tun: Universal TUN/TAP device driver, 1.6 [ 492.481989] tun: (C) 1999-2004 Max Krasnyansky
If this is the case, you might considering adding the string “tun” to your /etc/modules file and trying a manual initialization of the module:
# modprobe tun
If, however, module initialization isn’t your problem, you might be experiencing some shenanigans with the population of your /dev directory. If the “tun” module appears to have been initialized successfully, go ahead and ls -l for the node:
# ls -l /dev/net/tun
If this comes back “No such file or directory” your best bet for a quick fix is (assuming that /dev/net already exists) to handle the situation cowboy style and make the dev node yourself:
# mknod /dev/net/tun c 10 200
That should get you a node that looks like this:
crw-r--r-- 1 root root 10, 200 2009-01-12 11:37 /dev/net/tun
And once you’ve got that, issue a quick stop and start of OpenVPN via init script and tail that /var/log/openvpn.log file one more time; you should be past the tunnel creation process.
…and on to the next catastrophic failure.