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 192.168.2.0/24, the VPN subnet is 192.168.3.0/24, and the OpenVPN server is running on my DD-WRT router locally at 192.168.2.1.
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 comp-lzo server 192.168.3.0 255.255.255.0 keepalive 10 120 push "route 192.168.2.0 255.255.255.0" push "dhcp-option DNS 192.168.2.1" persist-key persist-tun verb 5
#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 comp-lzo tls-client resolv-retry infinite nobind persist-key persist-tun ns-cert-type server verb 3 #tells the OpenVPN client to accept all options pushed by the server pull #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
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 192.168.3.0/24 -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 192.168.3.1. 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!