Setting up a VPN based on OpenVPN requires setting up a few "groups" of configuration options. Each of them covers separate elements of a VPN tunnel. One part is the connection between server and clients. Next up is the encryption layer, then there is the authentication layer and at the end we cover the network inside the tunnel.

One nifty detail about OpenVPN configuration options. Almost all of these options can be used either on the command line directly or via a configuration file. The main difference is that on the command line you must use two leading dashes (--) for OpenVPN to understand what you mean. When using these options in the configuration file must not use any leading dashes at all.

When starting OpenVPN, you can either use the --config option to tell OpenVPN which configuration file to use. Or if you do not use any options at all, you can just provide the file name directly.

Notice that you can use --config multiple times, to merge several configuration files. Or you can use 'config' inside a configuration file to "include" another configuration file.

Using UDP requires just to add

in both client and server configurations. For TCP, the server requires

and the client requires

Then a port number is needed. The official OpenVPN port number is 1194, but any port number between 1 and 65535 will work. If you don't provide the 'port' option, 1194 will be used. An example using port 443

In the client configuration you need to tell where to connect. Both hostnames and IP addresses can be used.

For advanced setups, it is also possible to use <connection> blocks, read more about that in the [OpenVPN man page](/Openvpn24ManPage).

Please do note that the OpenVPN server **can not** listen to multiple incoming ports, neither multiple protocols. You need separate OpenVPN instances for tackling that.

The advantage of static encryption is that it is very easy to configure. The disadvantage of this type setup is that if your encryption key is compromised, all VPN data can easily be decrypted - even VPN data which has been captured in the past. It does not provide any type of perfect forward secrecy. And you need to ensure that the key is securely copied to both hosts. If you want to change the key, it must be changed on all clients. Last of all, static encryption also only allows a single connection to your server. How to configure static encryption can be found in the [Static Key Mini Howto](/StaticKeyMiniHowto).

The PKI mode resolves many of these issues static encryption has. It allows multiple clients to connect to the same server, each client and server have separate keys. But it is more complex to set up. A PKI setup requires a Certificate Authority (CA). There exists plenty of alternatives for CA management. You should NOT go any where to buy yourself new certificates as that will make the VPN tunnel much less secure (unless you add extra authentication layers). In addition to that, a commercial certificate for OpenVPN does not provide you with any additional benefits. You will need to control your own CA for optimal security.

https://github.com/OpenVPN/easy-rsa/blob/master/doc/EasyRSA-Readme.md

One common mistake when setting up a new CA is to place all the CA files on the OpenVPN server. [[span(style=background: #FFD0D0;padding-left: 6px; padding-right:6px;, DO ***NOT*** DO THAT! )] A CA requires a private key which is used for signing the certificates your clients and servers will use. If you loose control of your CA private key, you can no longer trust any certificates from this CA. Anyone with access to this CA private key can sign new certificates without your knowledge, which then can connect to your OpenVPN server without needing to modify anything on the VPN server. Place your CA files on a storage which can be offline as much as possible, only to be activated when you need to get a new certificate for a client or server.

* Private key (often a .key or .pem file)

The server in addition needs a DH parameters file. This can be generated by using the OpenSSL:

The 2048 indicates how many bits the DH prime number should consist of. The value of 2048 bits should in most cases be secure enough (as of October 2015), but it is ideal to have the DH prime number length to match the length of the RSA key. So if your key is 4096 bits, it is advisable to have 4096 bits DH parameters.

To better understand how PKI work, have a look at this introduction: https://github.com/OpenVPN/easy-rsa/blob/master/doc/Intro-To-PKI.md

Now we need to make use of these key and certificate files in the OpenVPN configuration files.

Server config:

The client config need to look something like this:

This provides a fairly good and secure starting point for an OpenVPN client and server to start talking to each other. And when certificates are used, the first level of authentication is already added. Only clients with a certificate signed by the CA identified in ca-crt.pem will be accepted on the server. And the client will also authenticate that the server certificate is signed by the CA the client has in its local ca-crt.pem file.

The --remote-cert-eku is optional, but highly recommended. It ensures that a server will verify that the client certificate provided is truly a client certificate, and vice versa for the client which checks that the server certificate truly aimed for a server. Otherwise, an OpenVPN server can use a client certificate acting as a server. We can add a few more hardening steps, but will come back to that later on.

And then there is the --tls-server and --tls-client options. They are just used to tell OpenVPN that it will act as a server or client with the TLS layers activated. Those options are needed for --key, --cert and --ca to be accepted.

With this in place, the certificates and private keys are actually just used to secure the exchange of a temporary encryption key for the OpenVPN session.

This temporary encryption key (which you will not see for yourself; it will be in RAM only) is used for encrypting the data which will be passed over the VPN connection, also known as the data channel. So all your network traffic between your server and client goes in the data channel and will be encrypted by this temporary key.

Those ciphers which are listed with '(variable)' in the output can have a variable key length, controlled by the --keysize option.

To use the preferred AES algorithm with 256 bits encryption, add this line to both client and server configs:

For most initial VPN setups, starting with Blowfish provides a fairly good security level. But remember that once you decide to upgrade your ciphers, you need to modify all server and client configs to the same --cipher value.

You can do another step to strengthen the encryption layer. The temporary session key was already mentioned, which is used for encrypting the tunnelled network data. This key will rotate by default every hour. But you can also tweak how often it gets rotated by adjusting --reneg-sec, --reneg-pkts and --reneg-bytes. See the [OpenVPN man page](/Openvpn24ManPage) for more information about these options.

To enable TLS authentication, first generate a static encryption key. This needs to be securely copied to all OpenVPN clients and servers.

The KEYDIR must be 0 on one of the sides and 1 on the other. So if you choose the KEYDIR value of 0 for the server, all clients must be 1, and vice versa.

If you are using OpenVPN v2.4 or later, you can make this even a bit stronger by replacing `--tls-auth` with `--tls-crypt`. Using tls-crypt also don't need to care about the KEYDIR - that is handled automatically.

Please note that you *cannot* use `--tls-crypt` and `--tls-auth` at the same time.

There exists many methods for adding username/password authentication. There exists plenty of plug-ins and scripts for PAM, LDAP, Radius and so on. There are also more advanced authentication and access controls available, such as

You can also provide a specific tun device, for example tun0 instead of tun. But if the 'tun0' device is already configured, OpenVPN will fail.

At this point, it should be possible to start up both the server and client. They should be able to connect and from the VPN client you should be able to ping 10.8.0.1 and from the server side you should be able to ping 10.8.0.2.

If you want to access particular network resources on other IP addresses via the VPN tunnel, you need to add network routes. A network route tells your operating system where it needs to send the network traffic when you want to access certain resources. An operating system can handle multiple routes via multiple gateways at the same time. So if you have a server on 192.168.1.10 behind your VPN server and you want to access this server via the VPN, you need to tell OpenVPN to configure a route for either a specific host or a network range to go via the tunnel.

This is a very basic setup. And when we now start on the routing part, the VPN setup is mostly done. All you need now is to add the needed routes you need, just like you would do for normal TCP/IP routing.

Remember that you also need to consider what is called "return routes". If your VPN client can access a host behind your VPN server, it does not mean that the host behind the VPN server will send the response via the same route. So you need to ensure that your hosts behind your VPN server also knows which gateway to use for your VPN. Nowadays this is most commonly fixed by adding a route on your existing default gateway. And if you run OpenVPN on an existing gateway, you have this return route already impllicitly configured.

You can either push such a "route everything over VPN" via the server, or you can add it explicitly in the client configuration. Do not use both at the same time.

OpenVPN v2.3 and later supports IPv6. To set up IPv6 in the tunnel is pretty much the same as for the IPv4 examples we already have covered. You need to use the --server-ipv6 and --route-ipv6 options to configure IPv6.

You can use the --route-ipv6 option, either pushing it from the server or using it directly in the client configuration, just as you can with the --route option. The syntax is similar too:

These values are reset upon boot, so they can also be stored in /etc/sysctl.conf to be enabled at boot.

Configuring firewall is so different between Linux and other Unix based OSes, in addition several Linux distributions have their own tools to manage iptables. So it is better to read the manuals for the firewall configuration on your operating system.