At home I use a router flashed with DD-WRT v.24 SP1 with OpenVPN support to connect to the office private network. I upgraded from v.23 SP2 a few months ago. When I did so, I discovered that OpenVPN doesn’t seem to start automatically. Let’s fix it.
Enabling syslog and collecting it at my laptop, I discovered that OpenVPN actually seems to crash or be killed.
Feb 4 08:00:41 192.168.0.1 openvpn[1238]: Re-using SSL/TLS context Feb 4 08:00:41 192.168.0.1 openvpn[1238]: LZO compression initialized
After this point it would just hang. Normally you’d see more:
Feb 4 08:47:07 192.168.0.1 openvpn[3906]: UDPv4 link local: [undef] Feb 4 08:47:07 192.168.0.1 openvpn[3906]: UDPv4 link remote: 10.0.0.1:1194 Feb 4 08:47:12 192.168.0.1 openvpn[3906]: [aegir] Peer Connection Initiated with 10.0.0.1:1194 Feb 4 08:47:14 192.168.0.1 openvpn[3906]: TUN/TAP device tun0 opened Feb 4 08:47:14 192.168.0.1 openvpn[3906]: /sbin/ifconfig tun0 10.1.0.30 pointopoint 10.1.0.29 mtu 1500 Feb 4 08:47:15 192.168.0.1 openvpn[3906]: Initialization Sequence Completed
DD-WRT v.24 seems to have some new features that allow you to apply changes from the web frontend without rebooting the entire OS, but the networking layer restarts. I’m guessing that when this happens OpenVPN is not invited to restart. I hope the devs fix this, but in the mean time I have my own solution.
Login to the web interface and go to Administration -> Commands. Save this as your new Firewall command list (which is run each time you restart networking):
# start openvpn again if failed (sleep 30 && (ps | grep openvpn | grep -v grep || openvpn --config /tmp/openvpncl/openvpn.conf --route-up /tmp/openvpncl/route-up.sh --down /tmp/openvpncl/route-down.sh --daemon))&
This command waits 30 seconds after restarting networking and checks for the existence of an openvpn process. If it does not find one, it starts it using the same command line as DD-WRT would normally use if the VPN were working. The VPN will now connect within the first minute after rebooting the router.
Leave a Reply