openvpn setup

general = { about, articles, links, projects } meta = { date-posted: 2006-08-19 }

This document outlines the setup of a routed vpn, over a tun interface. This is a layer 3 vpn, not a bridging vpn (layer 2). Openvpn does support bridging vpns, but I prefer to use routed vpns.

Download and install open vpn on your server.

Copy the easy-rsa directory to the openvpn etc folder.

$ cp -R /usr/share/doc/openvpn/examples/easy-rsa/ /etc/openvpn/
$ cd /etc/openvpn/easy-rsa

Edit your vars file. Modify the KEY_SIZE value if you want. Modify the values at the bottom of the file.
Export the values in vars to the current shell.
```
$ source vars
```
Do the clean all operation.
```
$ ./clean-all
```
Build a Certificate Authority
```
$ ./build-ca
```

Answer the questions as needed.

Now create the server keys (public and private).
```
$ ./build-key-server server
```

Answer the questions as needed.

Now we need to create the diffie-hellman parameters.
```
$ ./build-dh
```

Answer the questions as needed.

We are also going to create a tls-auth key. This adds a signature to the handshake packets. This provides additional protection against port scans and attacks. For more info on this, see the openvpn documentation on tls-auth.
```
$ openvpn --genkey --secret ta.key
```

Answer questions as needed.

We can now setup the server configuration file.The server configuration file should reside in /etc/openvpn.

dev tun
server 10.0.0.0 255.255.255.0
push "route 10.50.0.0 255.255.255.0"
tls-server
# Diffie-Hellman Parameters (tls-server only)
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
# Certificate Authority file
ca /etc/openvpn/easy-rsa/keys/ca.crt
# Our certificate/public key
cert /etc/openvpn/easy-rsa/keys/server.crt
# Our private key
key /etc/openvpn/easy-rsa/keys/server.key
# tls-auth
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
## which port and protocol we will use
port 1149
proto udp
# Downgrade UID and GID to
# "nobody" after initialization
# for extra security.
user nobody
group nogroup
# If you built OpenVPN with
# LZO compression, uncomment
# out the following line.
comp-lzo
## misc settings
persist-tun
persist-key
keepalive 10 120
# maximum number of simultaneously connected clients
max-clients 10
# logging settings
verb 3
mute 20
# log locations
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log

The 'server' line tells opevpn to dynamically hand out addresses in the range to connected clients. Make sure this range does not appear anywhere on your internal network.

The 'push' command, specifies a route that is pushed to the clients when they connect. If you have more than one internal network that you want them to reach, add additional routes.

As with ipsec vpn's, make sure that the routes your push to your client do not conflict with any of their existing network settings. This can cause the client to be unable to reach your internal network through the vpn. An example of which, would be if the client was connected via a coffee shop, and the coffee shop just happened to be using a network of 10.50.0.0/24.

Now we need to create the client keys. Each client has its own set of ssl certs. So, you will need to repeat this step for each client account that you want to allow. Many users can use the same cert, but I would not recommend this. If one of your clients it compromised, you can revoke their cert without effecting others. Key management is important. So lets create one for user 'remoteCactus'.
```
$ cd easy-rsa
$ ./build-key remoteCactus
```

Answer questions as needed.

We need to create a configuration file for the clients now. Name it remoteCactus.ovpn, so that windows clients can use it easily.

## specifies we are the client
tls-client
# device type
dev tun
# specify the protocol. This must match what the server uses.
proto udp
# the remote directive specifies the ip of the vpn server, and the port to connect to
remote 1.2.3.4 1149
# keep trying to resolve  the domain name, if a domain name is used above
resolv-retry infinite
# do not bind to any local ports
# since we are not doing client-2-client
nobind
#misc settings to make the client more performant for renegotiations
persist-key
persist-tun
# server cert authority
ca ca.crt
# client cert
cert remoteCactus.crt
#client key
key remoteCactus.key
# use only if your server defines it as well
comp-lzo
# check to make sure we are talking to a server with a server cert
ns-cert-type serrver
# client tls-auth config
tls-auth ta.key 1
# log settings
verb 3
mute 20

Who gets what? The following table is taken from the openvpn how-to guide.

Filename	Needed By	Purpose	Secret
ca.crt	server + all clients	Root CA certificate	NO
ta.key	server + all clients	tls-auth HMAC signature	YES
ca.key	key signing machine only	Root CA key	YES
dh{n}.pem	server only	Diffie Hellman parameters	NO
server.crt	server only	Server Certificate	NO
server.key	server only	Server Key	YES
client1.crt	client1 only	Client1 Certificate	NO
client1.key	client1 only	Client1 Key	YES

So, we need to distribut the following files to our remoteCactus user:

remoteCactus.ovpn
remoteCactus.crt
remoteCactus.key
ca.crt
ta.key

I generally put them in a zip file, or tarball, and encrypt them with a throwaway secret key, that is given in verbal exchange. This throwaway key is used only for transmission/receival of the files.

$ gpg -o remoteCactus.tar.gz.encrypted -ce  remoteCactus.tar.gz

The user can decrypt the file with.

$ gpg -o remoteCactus.tar.gz -cd remoteCactus.tar.gz.encrypted

Windows client install.

On a windows client, download and install the Openvpn windows Client. During the install, I prefer to choose the option for 'hide tun/tap interface'. This prevents the virtual network interface from showing up on the system.

Extract the contents of the tarball into the openvpn configuration file folder, and restart the openvpn client. Right click on the system tray icon, and select the tunnel.
Final considerations.

Make sure you enable ip_forwarding on your openvpn server. This allows the server to forward packets from the virtual lan to the lan, and back. I use iptables rules on the openvpn server as well, so make sure you provide needed forwarding rules (or masquerade, depending on how you want to handle it).

If you just use forward rules, be sure to specify a return route for the traffic, and put the openvpn server as the gateway for that traffic. I created a route in my internal network's default gateway (my internet facing firewall), back to the openvpn server, for the virtual network (in the example above, it was 10.0.0.0/24).

Enjoy openvpn. It rocks.

See the openvpn site for more information.
Thanks to this site for a nice how to that got me kick started.