"Road Warrior" Configuration with OpenVPN on DD-WRT

07 Sep 2008

For a long time, I've wanted to get an OpenVPN server / client up and running. This way if I'm at work, traveling, or sitting on a HotSpot I can not only create a secure tunnel for browsing the web, but also so I can access my file server back home. I've tried SSH tunnels before and they never end up giving me exactly what I want. So, after many, many attempts, a rainy and lazy Saturday gave me just the time I needed to get everything up and running. I have to say, DD-WRT (and probably the many other linux firmwares), really really do an awesome job at turning the usual home cable / DSL NAT router into a complete powerhouse.

I started by following a HOWTO for v24 SP1 posted on the DD-WRT forum here, yet I found myself running into confusion when it came time for configuration of the server and client. The configs in the forum worked but not the way I wanted them to, so I decided to post my completed config files here on my blog in case someone else would like to take a look at them and figure things out for their own application. If you're interesting in doing this yourself, begin with the HOWTO mentioned above. I ended up using Ubuntu under VMWare (I'm using a Mac) in order to create my certificates and keys.

Just a bit of background, the LAN subnet is, the VPN subnet is, and the OpenVPN server is running on my DD-WRT router locally at

Server Configuration

port 1194
proto udp
dev-type tun
dev vpn-user
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
tls-auth /tmp/openvpn/ta.key 0
keepalive 10 120
push "route"
push "dhcp-option DNS"
verb 5

Client Configuration

#change to the IP for your server, or WAN IP / DynDNS address of your DD-WRT
remote *OpenVPN Server Address*
port 1194
proto udp
dev tun0
resolv-retry infinite
ns-cert-type server
verb 3

#tells the OpenVPN client to accept all options pushed by the server

#sets up the proper routes to direct all traffic through the VPN tunnel
#comment this out if by chance this isn't desired, i.e. slow upload rates
redirect-gateway def1

ca      ca.crt
cert        rory.crt
key         rory.key
tls-auth    ta.key 1
ping 10
ping-restart 60

Firewall Settings

iptables -I INPUT 1 -p tcp --dport 1194 -j ACCEPT
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
iptables -I FORWARD 1 --source -j ACCEPT

I don't entirely understand iptable commands yet but I believe the first two accept TCP/UDP traffic in to the router on port 1194 thus allowing OpenVPN clients to connect to the OpenVPN server. The last command allows traffic to flow in and out of the VPN subnet.

Now, try hopping on an open Wi-Fi access point and connecting to your server. If the connection went smoothly, try pinging your server's address. In my case, it is If you are able to ping your server that means everything went well. Now time to tweak your config files to exactly what you want.

If for some reason connection failed, there are two commands that proved to be very very useful for troubleshooting, "ps | grep openvpn" and "tail -f /var/log/messages". "ps | grep openvpn" will tell you if OpenVPN is actually running. If you don't see it listed after running the command, it is most likely that your OpenVPN failed to start on boot / WAN UP because of invalid certs or an invalid server configuration. "tail -f /var/log/messages" will give you a real-time, detailed log of your router. Specifically, it will tell you if openvpn has started, error messages if openvpn fails to start, and details on all openvpn connections. Syslogd will need to be turned on for this command to work. You can turn it on under Services > System Log.

Lastly, one issue that really stumped me was an error on the server end saying something to the effect of 'unable to connect because your certificate is not yet valid'. I followed everyone's instructions to configuration all my computers with NTP along with the proper timezone but still no connection. However, I stumbled upon an entry on the DD-WRT wiki that fixed the problem. Apparently by setting my clock to UTC, it took care of the issue. No idea why that worked because now I have the incorrect time on my router, but who cares... it's working!