This post is part of my Explaining My Configs series where I explain the configuration files (and options) I use in detail.
This post could either be read as a whole, or as a reference (click on a line to jump to its explanation).
Usually I prefer explaining the client and the server configurations in separate posts, however, with OpenVPN, there is significant overlap between the two, and they need to match in order for it to work. Therefore, this post will explain both.
I have my configuration files in the system's OpenVpn directory (
/etc/openvpn/server for me), and for
each configuration file, I have a directory with its keys, so for example, this
is the layout for the server's config:
server.conf server/dh.pem server/ipp server/ta.key server/key.key server/cert.crt server/ca.crt
What is this config for?
I use my VPN to have remote access into my network, and sometimes also to route all traffic through it, in order to escape some forms of connection filtering. While my base configuration is hardened (strong encryption and secure settings), my route-all-traffic configuration is not. That requires some settings that are annoying to use and setting up a firewall to block mistakes.
The config file
Click on a line to jump to its explanation.
server 192.168.87.0 255.255.255.0 port 1194 proto udp6 dev tun0 client-to-client cipher AES-256-CBC auth SHA512 tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256 comp-lzo no keepalive 15 60 ping-timer-rem ifconfig-pool-persist server/ipp verb 3 persist-tun persist-key # Drop privs user nobody group nobody # Keys tls-auth server/ta.key 0 cert server/cert.crt key server/key.key ca server/ca.crt dh server/dh.pem
client remote vpn.stosb.com 1194 udp dev tun # Uncomment the next line to redirect all traffic through the VPN # redirect-gateway def1 remote-cert-tls server cipher AES-256-CBC auth SHA512 tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256 comp-lzo no verb 3 persist-tun persist-key # Keys key-direction 1 tls-auth client/ta.key cert client/cert.crt key client/key.key <ca> -----BEGIN CERTIFICATE----- ... SNIP ... -----END CERTIFICATE----- </ca>
Reviewing the config
server 192.168.87.0 255.255.255.0
server puts OpenVPN in server mode, and supplies it with a subnet of IPs to
allocate by specifying an address and a netmask. In the example above, OpenVPN
126.96.36.199 for itself, and allocate the rest of the subnet for
Choose a subnet that's unlikely to create clashes with your other networks.
This directive sets which port the server should listen on. I chose the standard OpenVPN port.
This sets the transport protocol to use. UDP is more efficient and will perform much better while using less data. However, if for some reason you can't use UDP, you can set this to TCP instead.
On the server I set it to
udp6 which tells it to listen to both IPv4 and IPv6
On the client I set it to
udp6 will force it to only try IPv6,
and made OpenVPN not work for me (I don't always have IPv6).
Sets the name of the virtual network device to use. On the server, I forced it
tun0, so I can more easily set firewall rules knowing it'll always be the
same device. On the client I let it choose the exact device on its own.
Since the device name starts with
tun, OpenVPN automatically sets the device
type to it. Otherwise I would have had to set
Normally, OpenVPN would pass all packets to the tun device on the server. This means that all packets, even between clients in the VPN network will be handled by the server's firewall, so if you want client to client traffic, you need to explicitly enable it in the firewall and add all the rules to do it.
Alternatively, you can set this directive that automatically does all of that for you. Be advised that with this enabled, the server's firewall will never get the packets, so don't enable it if you want fine-grained control.
cipher AES-256-CBC auth SHA512 tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
These statements harden the server with stronger crypto. However, some of them are only available from OpenVpn 2.3.3. If you are having trouble, choose different values.
cipher directive controls which cipher would be used for the data channel,
that is, all the data transferred through the VPN.
auth directive controls the HMAC algorithm used for the control channel.
More on that in the keys section.
tls-cipher directive controls the cipher suite used by the VPNs control
Disable compression. Most, if not all, of my traffic is either encrypted (e.g.
SSH and HTTPS) or already compressed (e.g. HTTP in most cases), so adding
compression on top will not add any benefits. If you think you may want
compression after all, set it to
adaptive which automatically decides if to
put compression on or not, though even when not compressing, this is not free.
keepalive 15 60
This is a helper directive that automatically sets the
values on both the client and the server (when set on the server). This is why
we don't have it in the client.
With this setting, a ping will be sent every 15 seconds (if no other data has been sent). This is useful to keep stateful firewalls will not drop or UDP connection after some time of inactivity.
The second part of this directive will try to restart the connection after 60 seconds of inactivity (on the client) and 60 * 2 = 120 seconds (on the server). This ensures that the client will detect the timeout before the server.
Note: be aware, that this setting can cause increased battery usage on mobile devices due to the radio being woken up to send data all the time.
This only runs the
ping-restart (previous) timeout timer when there is a client
connected to the server, so to prevent the server from timing out all the time
when there isn't even a client connected.
This makes the IP addresses given to clients persistent, and the persistence
file to be saved in the location
server/ipp relative to the main config file.
Increase the verbosity of OpenVPN. The default is 1, but 3 is the recommended value. Shows a bit more information in the logs.
These options persist the tun device and the authentication keys across restarts (either caused by user or ping-restarts). This makes it possible to drop privileges (see the next section) and regardless, I couldn't think of a good reason why not to have these.
# Drop privs user nobody group nobody
This drop the privileges of the daemon to the user and group
nobody, so if
there's ever a bug in OpenVPN, at least the hacker won't get root privileges.
You could further harden it as explained on the OpenVPN website,
however, it was too much of a hassle for not a lot of benefit.
Because of the lower privileges, the server can no longer clean up after itself by for example closing the tun device, or removing routes. It's a non-issue for a server config because OpenVPN should never be stopped, but it is for a client, and that's why I only have this setting on the client machine.
# Keys tls-auth server/ta.key 0 cert server/cert.crt key server/key.key ca server/ca.crt dh server/dh.pem
These tell OpenVPN to look for the keys (and dh params) in the noted locations.
Please note that the number at the end of
tls-auth is the
key-direction, and needs to be 0 for server and 1 for client.
You can also embed the keys/certificates in the file itself if you prefer (demonstrated in the next section), and if you do it for the
tls-auth directive too, you'd need to specify the
key-direction separately using the
Please look online to see how to manage your own PKI for OpenVPN, this is beyond the scope of this post. However, one note on
tls-auth as promised earlier. This is the key used for HMAC. While this is not essential, it adds another layer of security by adding an easy to verify authentication code to all the control messages. This protects against some kinds of DoS and could even protect against issues with TLS, like for example, the recently notorious
<ca> -----BEGIN CERTIFICATE----- ... SNIP ... -----END CERTIFICATE----- </ca>
I redacted my actual certificate for brevity, but this is how you embed a key or certificate in the config file. I found it very useful when providing the OpenVPN Android client with a config. When I did that, I embedded all of the keys.
This is a helper indicating that this is a client. This means that the client assumes the position of "client" in the TLS negotiation. It also sets the
pull directive, which allows the server to push some (white-listed) configurations to the client like setting the IP address and routing.
remote vpn.stosb.com 1194 udp
This tells OpenVPN where to connect to. In this example it's connecting to
vpn.stosb.com and port
1194 using UDP, which is what we have set on the server.
You can put multiple remote directives for redundancy. For example, you could have OpenVPN running on a list of ports you expect to be white-listed in networks, like udp:53 (DNS) or tcp:993 (POP3) and then have OpenVPN automatically try them. Alternatively you can use it for real redundancy, so if one server fails, the others are automatically tried.
# Uncomment the next line to redirect all traffic through the VPN # redirect-gateway def1
This directive redirects all of the client's traffic through the VPN by adding the needed routing rules. This is the bare minimum that's needed, but you could also append other flags to this command, for example
block-local to block traffic to the local (non-VPN) LAN in order to make sure no traffic leaks. This is another level of hardening, but as I said before, it's better handled by proper firewall rules.
One thing to remember when using
block-local, is that in many cases your DNS server would be in the local network and with
block-local it will no longer be reachable. To solve it you should either set an alternative DNS in the client, by using for example
dhcp-option DNS 188.8.131.52, or pushing it from the server.
This forces the certificate of the other end to be a server certificate. Before explaining what it does, I need to explain a bit about PKI and OpenVPN. When a client connects to the server using TLS, it checks to see if the certificate of the server is signed by the certificate authority and not revoked, and if everything is OK, it allows the connection. This sounds good, but because of how OpenVPN works client certificates are also signed by the certificate authority, so a client could potentially impersonate the server, which is unacceptable.
One way to solve it, is to use the
tls-verify directive. This directive lets you run a command to verify the server is who it says it is by checking the public key (public key pinning), CN and whatever else you may feel like. However, t's annoying to set-up because you need to create and deploy and extra script.
Another way to solve it, which is less secure but much simple, and can be used in addition to the first method is to mark server certificates as such and verify it in the client. When creating the server certificate you just need to mark it as a server certificate, and then in the client add the
remote-cert-tls server directive to enforce that. I find this solution sufficient, and it's what I use.