OpenVPN: Setup and Configuration

This blog entry doesn't cover the creation of keys, which is something you really need to do before you get here. It's NOT simple (even with the help of OpenVPN's easy-rsa package), so it has its own blog entry. This entry assumes you've moved your keys and certs into position as outlined in the previous entry. And I finally get to the point where it may matter that OpenVPN operates on UDP port 1194. Punch a hole through your firewall if you have one (you do have one, right?) for both clients and servers(?).

Needed Files

Having moved the appropriate keys and certificates to the server and clients, we need to get those files into the proper folders and do the setup. Example config files are (on Debian, anyway) to be found in /usr/share/doc/openvpn/examples/sample-config-files/ ... which has multiple examples for various networking setups. I'm working on the idea of having one server and a couple clients, with no bridging, proxying, or anything else (simple setup - still hard to create an OpenVPN). For this setup, the needed files are server.conf.gz and client.conf. I'm copying server.conf.gz (and gunzipping it) to /etc/openvpn/.

Server Configuration

First, open the server config and look for "ca " at the beginning of the line so we can set the "ca," "cert," and "key" params:

ca /etc/openvpn/priv/ca.crt
cert /etc/openvpn/priv/server.crt
key /etc/openvpn/priv/server.key
dh /etc/openvpn/priv/dh4096.pem

Technically, the "key" is the only one that needs to be secured/hidden.

Look for another line:


As the comments in the file explain, the server will take and assign other values in the range to the clients. You can also choose another number if you prefer, keeping in mind that would be particularly bad because you've got a very good chance of it conflicting with a home router. You're looking for Private Network values that won't conflict with any of your existing networks. The value is probably a good choice (but I changed it anyway). I uncommented client-to-client so that the clients can talk to each other rather than just to the server, but this is a matter of personal taste.

There's a rather interesting option in the configuration I haven't seen mentioned in the HOWTO, called duplicate-cn which would appear to allow clients to share the same certificates and keys (rather than generating separate ones for each client). I haven't tried this: it would be convenient, but it would seem to open you up to the possibility of anyone's machine being able to join your VPN if they can get a copy of the key, whereas that's harder (although not impossible) with individualized keys.

Uncomment these lines:

user nobody
group nogroup

This should be the default, but appears to be commented out because of Windows, where it doesn't work. Similarly, you should uncomment this line (again, commented out to support Windows clients):

topology subnet

Something to investigate later is the tls-auth ta-key 0 setting: more key generation for more security, not worth it for my initial testing, but possibly worthwhile later on.

Client Configuration

Start by copying /usr/share/doc/openvpn/examples/sample-config-files/client.conf to /etc/openvpn/. "ca," "cert," and "key" settings are updated in the same way as the server (although the cert and key have numbered values, you get the idea), but no "dh" setting.

Look for a line starting with "remote" that holds the name or IP of the server (this is its real-world IP, not the VPN address).

Search for the following settings in server and client configs, and make sure they match: "dev " (set to "tun" in the default configuration), "proto " (default is "udp"), "comp-lzo" - this is a singleton, either commented or uncommented, but has to match across clients and servers: default is uncommented, compression is good - and finally "fragment" ... which isn't in any of my configs, so they match.

Running Stuff

On the server:

# openvpn /etc/openvpn/server.conf

Likewise, on each client:

# openvpn /etc/openvpn/client.conf

If all goes well, you should see a relatively short startup message on the server, and then a relatively short startup message on each client (each of which will trigger a bit of a response on the server). And then you'll find that ifconfig will show you not only your normal eth0 and lo, but also tun0 as a new device. Your routing table (the output of the route command) will also show that will now "Use Iface tun0". I immediately tried ssh-ing from one client to the other over the VPN, and it worked fine (hey, it's encryption on top of encryption, but it's also the easiest way to test).

Note that it did NOT "go well" the first time: I'd messed up the key generation, and I thought I'd sorted it out, but the connection wasn't established properly. In the end, I went back to the beginning and made a completely new set of keys for all the machines involved. It was a pain, but it fixed the problem. I'm sure there are many more ways for this to fail: this is the only one I can tell you about as it's the only way I've broken it so far.

Production Use

Honestly, I put this section here so I could tell you "I have no idea." I think this is a fairly secure and correct way to set up OpenVPN, what it's mainly lacking is a good way to start and background the openvpn client/server when the machine comes up. This should be fairly easy compared to the rest of the setup - but again, I'm not sure: I just wanted to get the damn thing running for testing.