Over the years, I’ve toyed with various methods of remotely accessing my home network. The easiest method that I’ve employed has always been SSH. Unfortunately, while it is a versatile protocol, it is significantly more difficult to access multiple machines or services once you’re logged in. You have to set up tunnels for every service you want to connect to, which can be a hassle. OpenVPN solves a lot of these problems by behaving as a virtual NIC, which connects you to a remote network in a more seamless fashion. While I’ve had limited experience with this, it is supposedly effective at escaping the scrutiny of firewalls (you can use any port, TCP or UDP). The initial setup sucks compared to OpenSSH, but it is awesome once it works. I decomm’ed my Sunblade server (my old VPN endpoint) and took out its HDD, so I’m posting my config file. Hopefully it’ll be useful to someone.
server 10.8.123.0 255.255.255.0
# 1st push:
# Lets the client know that it should route
# traffic for the 192.168.2.0 network to
# my home gateway.
# 2nd push:
# I wanted to use my home internet connection
# in order to encrypt my web traffic. So I made
# all other traffic (default route), go through
# my home router.
push “route 192.168.2.0 255.255.255.0 192.168.2.1″
push “route 0.0.0.0 0.0.0.0 192.168.2.1″
# NOTE: The following push never actually worked for me
# That’s why I had to do the 2nd push above.
# It’s just here for reference, along with the original comment.
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
push “redirect-gateway def1″
# Supposedly Windows-specific
# Allows you to tell your client what DNS to use.
push “dhcp-option DNS 192.168.2.1″
keepalive 10 120
As you could probably tell, this config file is fairly vanilla. I made good use of OpenVPN’s semi-decent documentation with a couple of notable differences. I wanted to originally go with a bridged TAP interface, but I couldn’t get it to work for one reason or another (can’t remember, it was months ago). So I opted for TUN instead, which means I couldn’t use broadcasting. Whatever. 10.8.123.0 is the subnet I made up for the VPN. I figured that wouldn’t come into conflict with anything (you can’t use the same subnet a local or remote, or routing gets messed up). 192.168.2.0 refers to my subnet at home (in this case, the “remote” network). I described the rationale behind my push statements in the comments above. I’m particularly proud of the second push statement, because I learned a little about routing I didn’t know before. There wasn’t anything in the OpenVPN docs covering it, so I had to do a little bit of research to get that working. I can also manually create routes in case the push fails, and that’s important.
Here are a couple of other important tidbits which a lot of docs gloss over. IP forwarding should be enabled on your VPN server, or else routing traffic won’t work. Also, I had to make a routing rule on my home (remote) router (192.168.2.1). The destination is 10.8.123.0, gateway is 192.168.2.3 (VPN server), subnet mask is 255.255.255.0. This was intended for anything being sent back to my VPN client (like replies from remote machines). The traffic would be sent to the VPN server, which would then be sent to the client. Otherwise any outside traffic coming back to the client would get discarded, since the remote router would have no idea where to send it.
One obvious benefit of this setup is being able to easily reach my home network without actually being on it. Speed is a benefit, since OpenVPN can use UDP to communicate quicker than TCP (SSH). Security is another: OpenVPN allows you to easily set up a PKI for authentication and encryption. A big disadvantage is the convoluted setup. Another is the fact that OpenVPN doesn’t behave the same way from platform to platform. A configuration that works in Windows may not in Linux. While Windows and Linux are pretty easy to get working as clients, I had a bit of trouble with mobile platforms. WebOS and Android (stock phone ROM), had no native support for OpenVPN. I had to use a homebrew solution on webOS. I have yet to get things going on Android, though Cyanogenmod advertises compatibility.
I also want to try L2TP/IPSec at some point, since it looks like it enjoys better compatibility. If I do it, you’ll be the first to know. If you see anything here that is wrong or could be done/explained better, PUH-LEEEEASE comment.