OpenVPN Tutorial: Installation, VPN Server Configuration and Connection

What is it?

OpenVPN is a software based on free software that allows us to build a virtual private network (VPN), to connect remotely to the server. This software allows us to configure two types of VPN architectures:

• Remote Access VPN: We have a central VPN server, and several VPN clients with the software installed on your computer, smartphone, tablet or other device, and they all connect centrally to the VPN server.
• Site-to-Site VPN: this architecture allows us to intercommunicate between different sites to share resources through a secure network, protected with end-to-end encryption. This type of VPN allows us to intercommunicate offices, company headquarters, etc.

Some very important features of OpenVPN are that it supports extensive configuration, both to improve performance as well as security. It is based on SSL / TLS, therefore, we can create digital certificates for the authentication of VPN clients, in addition, we could also authenticate with certificates plus a username / password that we add to the system. OpenVPN is much easier to configure than IPsec, and thanks to the great support from the community, we will be able to find OpenVPN on all desktop operating systems, servers and even on smartphones and tablets.

What is it for?

If we create an OpenVPN server in our home, it can help us to connect to the Internet in a secure way from any network, be it wired or WiFi, with WEP / WPA encryption or without encryption. All traffic will be encrypted through a tunnel from our computer where we connect to our home and from there it will go to the Internet, it is like being connected to the Internet at home. We must take into account several factors, such as having a good upload speed (30Mbps or higher), and having a public IP address in our home, since if we have CG-NAT we will not be able to connect because we will not be able to do port forwarding in the router.

By mounting an OpenVPN server in our home, we can also access each and every one of the shared resources we have, such as Samba servers, FTP and even access the printer, IP cameras that we have connected, etc. All access permits would be just as if we were physically in our home. OpenVPN is a solution for VPN that implements layer 2 or 3 connections, depending on the chosen connection mode, it will work in one way or another, in addition, an important detail is that the vast majority of operating systems today support OpenVPN, although not it is usually incorporated by hardware manufacturers for firewalls or routers.

OpenVPN uses a set of SSL / TLS protocols that work at the transport layer, and we have two types of operation:

• TUN : The TUN controller emulates a point-to-point device, it is used to create virtual tunnels operating with the IP protocol . In this way, all the packets that are transported through it can be encapsulated as TCP segments or UDP datagrams (later you will see that we choose UDP instead of TCP, and you will ask why, since TCP is connective, reliable and oriented to Connection). The machines behind each end of the link will belong to different subnets.
• TAP : Simulates an Ethernet network interface, more commonly known as bridge or bridge mode, these virtual tunnels directly encapsulate Ethernet packets . This situation allows packaging different fabrics than IP. The machines behind each end of the link can operate as part of the same subnet (if the IP protocol is used). The bridge operating mode is particularly useful to link remote users, since they can connect to the same server and virtually be part of the main network, however, if the private network where the origin is connected coincides with the destination, we will have Routing problems and communication will not work.

In the manual we will use TUN and see how we create a virtual subnet 10.8.0.0/24 where the OpenVPN clients will be when they connect. In this way, it will be much easier to identify the VPN clients that we have connected in the local network.

In this manual I am going to explain how to do it in GNU / Linux (in Debian 10) , although in essence, it is the same for Windows , only the commands in the console (cmd.exe), the certificates and the keys change, they are the The same for both , that is, you can create EVERYTHING in GNU / Linux and then pass it to Windows to use it (either client or server), you only have to change the client / server extension .conf to .ovpn , although in the latest versions OpenVPN for Windows already allows us to recognize and use .conf configuration files, so we will not have to change the extension.

In this manual I am going to show you how to make a very secure OpenVPN configuration, customizing the symmetric, asymmetric and hash encryption algorithms. In this way, we can have the best possible encryption of communications.

Summary of the cryptography to use

• Digital certificates : We will use EC (Elliptical Curves) for the creation of the Public Key Infrastructure . We will create both the certificates of the CA (Certification Authority), as well as the certificates of the server and VPN clients that want to connect. The EC algorithm used is secp521r1, although we have many others available. The hash algorithm that we will use will be SHA512 . An important detail is that not all OpenVPN clients / servers support it, we must have our OpenVPN and cryptographic libraries updated, but nowadays it is rare to find ourselves in a scenario that is not compatible.
• OpenVPN control channel : we will use at least TLS 1.2, and always using PFS (Perfect Forward Secrecy) based on Diffie-Hellmann with elliptic curves (ECDHE). That is, we will use a selection of secure crypto suites, such as TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384. If you want to check if your server or client supports this type of encryption, you should put in the console “openvpn –show-tls”.
• OpenVPN data channel : We will use the AES-256-GCM symmetric encryption algorithm, the most secure currently and which has been incorporated into OpenVPN 2.4 and later. If you want to check if your server or client supports this type of encryption, you must put in the console « openvpn –show-ciphers «. If we use AES-256-GCM as data channel encryption, we will not use any HASH algorithm since it is AEAD, however, if we use AES-256-CBC we will use SHA512.

In addition to these security measures, we will include an additional HMAC signature for the first TLS negotiation, in this way, we will protect the system from possible denial of service attacks, UDP Port Flooding attacks and also TCP SYN attacks. When connecting to the server, if the client does not have the correct HMAC signature, it will be blocked. In previous versions of OpenVPN 2.4 the directive was tls-auth , which was only responsible for the authentication of a pre-shared key generated by OpenVPN itself. Now in versions higher than OpenVPN 2.4 it is called tls-crypt , the main difference is that in addition to authenticating, it also encrypts the channel so that no one is able to capture said pre-shared key. The configuration is very similar, the generation of the key is exactly the same in both.

Finally, we will use the UDP protocol instead of TCP, because it is stronger against denial of service attacks, we must remember that UDP is non-connective, unreliable and connection-oriented. However, we can use TCP without any problem to provide the VPN with all the benefits of this protocol.

Steps to follow to work with OpenVPN

Below you will be able to see in detail how to install this software, and also everything you need to start it up with the best possible security provided by this solution to create a virtual private network.

Download and install

The first thing we have to do is install OpenVPN on our computer, either with Windows or Linux. If you use Windows you must go to the official OpenVPN download website and install everything in the installation wizard. If you use an operating system like Debian (we will be using Debian 10 throughout this manual), you will have to enter the following command:

sudo apt update

sudo apt install openvpn

Easy-RSA 3 download for certificates

Once installed, we must download the Easy-RSA 3 software package, this software package is used to create digital certificates easily and quickly. We can modify the length of the key, the type of key, if we want to put a password to the private keys etc. On the official website of the Easy-RSA 3 project on GitHub you have all the information and the possibility of downloading a .zip with everything.

If you are on a Linux system, we recommend using the wget command to download the .zip:

wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.8/EasyRSA-3.0.8.tgz

Next, we must unzip this downloaded file and enter the folder to start configuring the vars file.

tar -zxvf EasyRSA-3.0.8.tgz

Configure Easy-RSA 3 «vars»

The vars.example file is the center of all the configuration of the certificates, it is where we must define if we want to create certificates based on RSA or based on EC. Likewise, it will also allow us to sign the certificates with SHA256 or SHA512 among others. That is, we must configure this configuration file correctly to later create the digital certificates.

The first thing we must do is copy the file vars.example in the same folder with name “vars”, if we do not have it with this name “vars” it will not work. We also have the possibility to rename the file vars.example in “vars”, but we recommend you better make a backup in case you delete something and then it doesn’t work for you.

We go to the main folder of Easy-RSA3 and copy the file in this way:

cp vars.example vars

Once we have the “vars” file, we must edit it with any file editor via console or graphical interface, we will use nano due to its ease. In the following «vars» configuration file you can see how EC would look with the secp521r1 algorithm, signed with SHA512 and we have used a DN (Distinguished Name) putting the CN (Common Name) instead of the typical «organization data »As we have always done before, in this way, we facilitate the creation of certificates, however, we could also do it by indicating the typical organization data.

In the file itself are the original comments in English, and in Spanish we have put ours to facilitate the location of what needs to be modified. A very important detail, WordPress automatically puts these symbols << and >> when it should just put double quotes: »

# Easy-RSA 3 parameter settings

# NOTE: If you installed Easy-RSA from your distro’s package manager, don’t edit
# this file in place – instead, you should copy the entire easy-rsa directory
# to another location so future upgrades don’t wipe out your changes.

# HOW TO USE THIS FILE
#
# vars.example contains built-in examples to Easy-RSA settings. You MUST name
# this file ‘vars’ if you want it to be used as a configuration file. If you do
# not, it WILL NOT be automatically read when you call easyrsa commands.
#
# It is not necessary to use this config file unless you wish to change
# operational defaults. These defaults should be fine for many uses without the
# need to copy and edit the ‘vars’ file.
#
# All of the editable settings are shown commented and start with the command
# ‘set_var’ – this means any set_var command that is uncommented has been
# modified by the user. If you’re happy with a default, there is no need to
# define the value to its default.

# NOTES FOR WINDOWS USERS
#
# Paths for Windows * MUST * use forward slashes, or optionally double-esscaped
# backslashes (single forward slashes are recommended.) This means your path to
# the openssl binary might look like this:
# “C: / Program Files / OpenSSL-Win32 / bin / openssl.exe”

# A little housekeeping: DON’T EDIT THIS SECTION
#
# Easy-RSA 3.x doesn’t source into the environment directly.
# Complain if a user tries to do this:
if [-z “$ EASYRSA_CALLER”]; then
echo “You appear to be sourcing an Easy-RSA ‘vars’ file.” > & 2
echo «This is no longer necessary and is disallowed. See the section called »> & 2
echo “‘How to use this file’ near the top comments for more details.” > & 2
return 1
fi

# DO YOUR EDITS BELOW THIS POINT

# This variable is used as the base location of configuration files needed by
# easyrsa. More specific variables for specific files (eg, EASYRSA_SSL_CONF)
# may override this default.
#
# The default value of this variable is the location of the easyrsa script
# itself, which is also where the configuration files are located in the
# easy-rsa tree.

#set_var EASYRSA “$ {0% / *}”

# If your OpenSSL command is not in the system PATH, you will need to define the
# path to it here. Normally this means a full path to the executable, otherwise
# you could have left it undefined here and the shown default would be used.
#
# Windows users, remember to use paths with forward-slashes (or escaped
# back-slashes.) Windows users should declare the full path to the openssl
# binary here if it is not in their system PATH.

#set_var EASYRSA_OPENSSL “openssl”
#
# This sample is in Windows syntax – edit it for your path if not using PATH:
#set_var EASYRSA_OPENSSL “C: / Program Files / OpenSSL-Win32 / bin / openssl.exe”

# Edit this variable to point to your soon-to-be-created key directory. By
# default, this will be “$ PWD / pki” (ie the “pki” subdirectory of the
# directory you are currently in).
#
# WARNING: init-pki will do a rm -rf on this directory so make sure you define
# it correctly! (Interactive mode will prompt before acting.)

#set_var EASYRSA_PKI “$ PWD / pki”

# Define X509 DN mode.
# This is used to adjust what elements are included in the Subject field as the DN
# (this is the «Distinguished Name.»)
# Note that in cn_only mode the Organizational fields further below aren’t used.
#
# Choices are:
# cn_only – use just a CN value
# org – use the “traditional” Country / Province / City / Org / OU / email / CN format

#ELEGIMOS cn_only FOR THE CREATION OF CERTIFICATES

set_var EASYRSA_DN “cn_only”

# Organizational fields (used with ‘org’ mode and ignored in ‘cn_only’ mode.)
# These are the default values for fields which will be placed in the
# certificate. Don’t leave any of these fields blank, although interactively
# you may omit any specific field by typing the «.» symbol (not valid for
# email.)

#set_var EASYRSA_REQ_COUNTRY “US”
#set_var EASYRSA_REQ_PROVINCE “California”
#set_var EASYRSA_REQ_CITY “San Francisco”
#set_var EASYRSA_REQ_ORG “Copyleft Certificate Co”
#set_var EASYRSA_REQ_EMAIL “me@example.net”
#set_var EASYRSA_REQ_OU “My Organizational Unit”

# Choose a size in bits for your keypairs. The recommended value is 2048. Using
# 2048-bit keys is considered more than sufficient for many years into the
# future. Larger keysizes will slow down TLS negotiation and make key / DH param
# generation take much longer. Values up to 4096 should be accepted by most
# software. Only used when the crypto alg is rsa (see below.)

#set_var EASYRSA_KEY_SIZE 2048

# The default crypto mode is rsa; ec can enable elliptic curve support.
# Note that not all software supports ECC, so use care when enabling it.
# Choices for crypto alg are: (each in lower-case)
# * rsa
# * ec

# WE CHOOSE ELIPTICAL CURVE FOR THE CREATION OF CERTIFICATES, BY DEFAULT IT IS RSA.

set_var EASYRSA_ALGO ec

# WE DEFINE THE NAME OF THE ELIPTICAL CURVE CHOSEN

set_var EASYRSA_CURVE secp521r1

# WE CONFIGURE THE EXPIRY OF THE AC

set_var EASYRSA_CA_EXPIRE 3650

# WE CONFIGURE THE EXPIRY OF THE CERTIFICATES CREATED.

set_var EASYRSA_CERT_EXPIRE 1080

# How many days until the next CRL publish date? Note that the CRL can still be
# parsed after this timeframe passes. It is only used for an expected next
# publication date.

# How many days before its expiration date a certificate is allowed to be
# renewed?
#set_var EASYRSA_CERT_RENEW 30

#set_var EASYRSA_CRL_DAYS 180

# Support deprecated “Netscape” extensions? (choices “yes” or “no”.) The default
# is “no” to discourage use of deprecated extensions. If you require this
# feature to use with –ns-cert-type, set this to “yes” here. This support
# should be replaced with the more modern –remote-cert-tls feature. If you do
# not use –ns-cert-type in your configs, it is safe (and recommended) to leave
# this defined to “no”. When set to “yes”, server-signed certs get the
# nsCertType = server attribute, and also get any NS_COMMENT defined below in the
# nsComment field.

#set_var EASYRSA_NS_SUPPORT “no”

# When NS_SUPPORT is set to «yes», this field is added as the nsComment field.
# Set this blank to omit it. With NS_SUPPORT set to “no” this field is ignored.

#set_var EASYRSA_NS_COMMENT “Easy-RSA Generated Certificate”

# A temp file used to stage cert extensions during signing. The default should
# be fine for most users; however, some users might want an alternative under a
# RAM-based FS, such as / dev / shm or / tmp on some systems.

#set_var EASYRSA_TEMP_FILE “$ EASYRSA_PKI / extensions.temp”

# !!
# NOTE: ADVANCED OPTIONS BELOW THIS POINT
# PLAY WITH THEM AT YOUR OWN RISK
# !!

# Broken shell command aliases: If you have a largely broken shell that is
# missing any of these POSIX-required commands used by Easy-RSA, you will need
# to define an alias to the proper path for the command. The symptom will be
# some form of a ‘command not found’ error from your shell. This means your
# shell is BROKEN, but you can hack around it here if you really need. estos
# shown values are not defaults: it is up to you to know what you’re doing if
# you touch these.
#
#alias awk = »/ alt / bin / awk»
#alias cat = »/ alt / bin / cat»

# X509 extensions directory:
# If you want to customize the X509 extensions used, set the directory to look
# for extensions here. Each cert type you sign must have a matching filename,
# and an optional file named ‘COMMON’ is included first when present. Note that
# when undefined here, default behavior is to look in $ EASYRSA_PKI first, then
# fallback to $ EASYRSA for the ‘x509-types’ dir. You may override this
# detection with an explicit dir here.
#
#set_var EASYRSA_EXT_DIR “$ EASYRSA / x509-types”

# OpenSSL config file:
# If you need to use a specific openssl config file, you can reference it here.
# Normally this file is auto-detected from a file named openssl-easyrsa.cnf from the
# EASYRSA_PKI or EASYRSA dir (in that order.) NOTE that this file is Easy-RSA
# specific and you cannot just use a standard config file, so this is an
# advanced feature.

#set_var EASYRSA_SSL_CONF “$ EASYRSA / openssl-easyrsa.cnf”

# Default CN:
# This is best left alone. Interactively you will set this manually, and BATCH
# callers are expected to set this themselves.

#set_var EASYRSA_REQ_CN “ChangeMe”

# Cryptographic digest to use.
# Do not change this default unless you understand the security implications.
# Valid choices include: md5, sha1, sha256, sha224, sha384, sha512

# WE SELECTED THE HASH SHA512

set_var EASYRSA_DIGEST “sha512”

# Batch mode. Leave this disabled unless you intend to call Easy-RSA explicitly
# in batch mode without any user input, confirmation on dangerous operations,
# or most output. Setting this to any non-blank string enables batch mode.

#set_var EASYRSA_BATCH «»

Once we have modified everything, we save the file since later we are going to use it with these values.

PKI creation: CA, server and client certificates

When we have the «vars» file configured, we proceed to create the Public Key Infrastructure (PKI) with the following command (we assume that you are still in the main Easy-RSA3 directory):

./easyrsa init-pki

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa init-pki

Note: using Easy-RSA configuration from: ./vars

init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /home/bron/EasyRSA-v3.0.6/pki

Once the PKI is initialized, we must create the Certification Authority (CA):

./easyrsa build-ca

Once executed, we must follow the simple CA generation wizard. The password that you ask us is to protect the private key of the CA, something fundamental.

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa build-ca

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019

Enter New CA Key Passphrase:
Re-Enter New CA Key Passphrase:
read EC key
writing EC key
Can’t load /home/bron/EasyRSA-v3.0.6/pki/.rnd into RNG
139864421569664: error: 2406F079: random number generator: RAND_load_file: Cannot open file: ../ crypto / rand / randfile.c: 98: Filename = / home / bron / EasyRSA-v3.0.6 / pki / .rnd
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, The field will be left blank.
—–
Common Name (eg: your user, host, or server name) [Easy-RSA CA]: AUTHORITY-CERTIFICATION

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/home/bron/EasyRSA-v3.0.6/pki/ca.crt

If we do not want to enter a password in the private key of the CA (it is not recommended for security reasons), we must put this command:

./easyrsa build-ca nopass

Once we have created the CA, we must create the server certificate and the client certificates. Next, we must sign it with the CA.

Create the server certificate and sign it with the CA

When creating the server and client certificates, we can give them a password for the private key, however, it is not recommended to do it on the server since every time we start it, it will ask us for the password to use it. If we do not want a password, we will put “nopass” behind each order that you will see below.

./easyrsa gen-req servidor-openvpn-redeszone nopass

The output of the terminal is as follows:

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa gen-req server-openvpn-redeszone nopass

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019
Generating an EC private key
writing new private key to ‘/home/bron/EasyRSA-v3.0.6/pki/private/server-openvpn-redeszone.key.bHJsAFg0KR’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, The field will be left blank.
—–
Common Name (eg: your user, host, or server name) [server-openvpn-redeszone]:

Keypair and certificate request completed. Your files are:
req: /home/bron/EasyRSA-v3.0.6/pki/reqs/server-openvpn-redeszone.req
key: /home/bron/EasyRSA-v3.0.6/pki/private/servidor-openvpn-redeszone.key

Once the certificate is created, we must sign it with the CA in “server” mode:

./easyrsa sign-req server servidor-openvpn-redeszone

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa sign-req server server-openvpn-redeszone

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019

You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 1080 days:

subject =
commonName = server-openvpn-redeszone

Type the word ‘yes’ to continue, or any other input to abort.
Confirm request details: yes
Using configuration from /home/bron/EasyRSA-v3.0.6/pki/safessl-easyrsa.cnf
Enter pass phrase for /home/bron/EasyRSA-v3.0.6/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject’s Distinguished Name is as follows
commonName: ASN.1 12: ‘server-openvpn-redeszone’
Certificate is to be certified until Dec 23 11:40:22 2022 GMT (1080 days)

Write out database with 1 new entries
Data Base Updated

Certificate created at: /home/bron/EasyRSA-v3.0.6/pki/issued/servidor-openvpn-redeszone.crt

And we have already created the .crt that we will use later in the OpenVPN configuration file.

Create client certificates and sign them with the CA

The steps that you will see below, we will have to perform once FOR EACH CLIENT that we are going to create. That is, if we are going to create 2 clients, we must follow the steps of creating and signing twice. In this part, it is advisable to create the client’s certificates with a password, so we can be sure that if we lose the certificate, no one can use it. We are not going to introduce any password in the manual (we will put nopass at the end).

./easyrsa gen-req cliente1-openvpn-redeszone nopass

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa gen-req client1-openvpn-redeszone nopass

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019
Generating an EC private key
writing new private key to ‘/home/bron/EasyRSA-v3.0.6/pki/private/cliente1-openvpn-redeszone.key.YflrPvFgdV’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, The field will be left blank.
—–
Common Name (eg: your user, host, or server name) [client1-openvpn-redeszone]:

Keypair and certificate request completed. Your files are:
req: /home/bron/EasyRSA-v3.0.6/pki/reqs/cliente1-openvpn-redeszone.req
key: /home/bron/EasyRSA-v3.0.6/pki/private/cliente1-openvpn-redeszone.key

Once created, we must sign it:

./easyrsa sign-req client cliente1-openvpn-redeszone

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa sign-req client client1-openvpn-redeszone

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019

You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a client certificate for 1080 days:

subject =
commonName = client1-openvpn-redeszone

Type the word ‘yes’ to continue, or any other input to abort.
Confirm request details: yes
Using configuration from /home/bron/EasyRSA-v3.0.6/pki/safessl-easyrsa.cnf
Enter pass phrase for /home/bron/EasyRSA-v3.0.6/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject’s Distinguished Name is as follows
commonName: ASN.1 12: ‘client1-openvpn-redeszone’
Certificate is to be certified until Dec 23 11:41:36 2022 GMT (1080 days)

Write out database with 1 new entries
Data Base Updated

Certificate created at: /home/bron/EasyRSA-v3.0.6/pki/issued/cliente1-openvpn-redeszone.crt

If we wanted to create and sign a certificate number 2 for another client, we should put something like this:

./easyrsa gen-req cliente2-openvpn-redeszone nopass ./easyrsa sign-req client cliente2-openvpn-redeszone

Remember that if you want to put a password, we must remove the “nopass”.

Organize the server and client .crt and .key certificates

Something very important is to organize the server and client certificates by folders. The server and client certificates are in the path “/ pki / issued /” and the private keys are in “/ pki / private”, the ca.crt is in the root of the “pki” folder. We must create three folders with the following content (for now):

• server: ca.crt, server-openvpn-redeszone.crt, server-openvpn-redeszone.key
• client1: ca.crt, client1-openvpn-redeszone.crt, client1-openvpn-redeszone.key
• client2: ca.crt, client2-openvpn-redeszone.crt, client2-openvpn-redeszone.key

Create the Diffie-Hellmann parameters and the key tls-crypt (tls-auth on older systems)

Once we have the certificates created and signed, formerly we had to create the Diffie-Hellmann parameters to place them in the “server” folder, to generate them we used “./easyrsa gen-dh” but when using ECDHE it is not necessary to create or indicate it neither in the server configuration file. What we must create is the tls-crypt key with the name ta.key or whatever we want. The order that we must put is the following:

openvpn --genkey --secret ta.key

This key ta.key must be placed on the server and on ALL clients.

Once we get here, our folders with the certificates should have the following:

• server: ca.crt, server-openvpn-redeszone.crt, server-openvpn-redeszone.key, dh.pem (Diffie-Hellmann, OPTIONAL because we won’t use it with ECDHE), ta.key (tls-crypt)
• client1: ca.crt, client1-openvpn-redeszone.crt, client1-openvpn-redeszone.key, ta.key (tls-crypt)
• client2: ca.crt, client2-openvpn-redeszone.crt, client2-openvpn-redeszone.key, ta.key (tls-crypt)

If we are going to use tls-auth instead of tls-crypt (because it is not supported, for example), we must take this into account:

In the server configuration (server.conf or server.ovpn) we must put:

tls-auth ta.key 0 (0 from Incoming)

In the client configuration (client.conf or client.ovpn) we must put:

tls-auth ta.key 1 (1 from Outgoing)

Next, we put a table of what each certificate is (names vary).

When we have everything organized in folders, now is when we must create the configuration file (.conf for Linux systems and .ovpn for Windows systems). There are examples of the configuration files on the official OpenVPN website , and also in the path “/ usr / share / doc / openvpn / examples / examples-config-files /”.

The first thing we have to verify is if our server and clients support symmetric ciphers, tls-ciphersuites (TLS 1.3) and tls-cipher (TLS 1.2) and the configured elliptical curves. We must take it into account, since otherwise it will give us an error. To carry out these verifications we must execute:

• openvpn –show-ciphers
• openvpn –show-tls (it will show us whether it supports TLS 1.3 and which ones, like TLS 1.2)
• openvpn –show-curves

Configure the OpenVPN server and start it

The configuration of the OpenVPN server is essential to give access permissions to clients to our local network, configure the TLS negotiation. Because we have hundreds of configurations available, we are going to put our configuration with some comments explaining each parameter, you can copy and paste the configuration without problems. Remember that for Linux it must have a .conf extension and for Windows .ovpn.

#PORT TO BE USED BY TCP OR UDP, BY DEFAULT IS 1194.
#PROTOCOL TO USE TCP OR UDP
#TUNNELING MODE
port 11949
proto udp
dev tun

#CERTIFICATES
#IF WE HAVE THE .CONF IN THE SAME FOLDER, THERE IS NO MISSING TO METER ROUTE, ONLY THE NAME.
#IF THEY ARE ON ANOTHER ROUTE, WE SHOULD TEST THE ROUTE OF ALL OF THEM

ca ca.crt
cert server-openvpn-redeszone.crt
key server-openvpn-redeszone.key
#dh dh.pem (OPTIONAL BECAUSE WE USE ECDHE)
dh none
tls-crypt ta.key

# WE CHECK CUSTOMERS ‘CERTIFICATES (GREATER SECURITY)
remote-cert-tls client

# WE MODIFY THE SYMMETRIC ENCRYPTION OF THE DATA CHANNEL, THE TLS CONTROL CHANNEL AND THE ALGORITHM TO VERIFY THE INTEGRITY.
#IF WE USE AES-256-GCM IT IS NOT NECESSARY TO PUT THE AUTH DIRECTIVE SINCE IT IS NOT USED.

cipher AES-256-GCM
tls-ciphersuites TLS_AES_256_GCM_SHA384: TLS_CHACHA20_POLY1305_SHA256
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384: TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256
ecdh-curve secp521r1
tls-version-min 1.2
reneg-sec 0
auth SHA512

# NETWORK TOPOLOGY (SUBNET RECOMMENDED) AND VIRTUAL SUBNET WHERE THE CLIENTS WILL BE.

subnet topology
server 10.8.0.0 255.255.255.0

# WE CONFIGURE THE SERVER SO THAT THE CLIENTS HAVE THE SAME IP ALWAYS, ONCE THEY CONNECT.
ifconfig-pool-persist ipp.txt

# WE PROVIDE THE CUSTOMER ACCESS TO THE HOME NETWORK, WE PERFORM INTERNET REDIRECTION AND PROVIDE OPENDNS DNS. WordPress automatically puts these symbols << and >> when it should just put double quotes: »
push “route 192.168.2.0 255.255.255.0”
push “redirect-gateway def1”
push “dhcp-option DNS 208.67.222.222”
push “dhcp-option DNS 208.67.220.220”

# WE ENABLE COMMUNICATION BETWEEN CLIENTS, WE ENABLE KEEPALIVE TO KNOW IF THE TUNNEL HAS DROPPED, WE ENABLE COMPRESSION AND A MAXIMUM OF 100 CLIENTS SIMULTANEOUSLY
client-to-client
keepalive 10 120
max-clients 100

#NO USER PERMISSIONS IN OPENVPN, FOR SERVER SECURITY
user nobody
group nogroup

#KEY AND PERSISTENT TUNNEL
persist-key
persist-tun

# THE SERVER LOGS IN THAT FILE, CONFIGURATION VERB 3 FOR THE LOGS.
status openvpn-status.log
verb 3
explicit-exit-notify 1

So far we have arrived with the configuration of the server, to start it we will simply have to put “openvpn server.conf” in Linux systems and it will start automatically, at the end of the boot you must put “Initialization Sequence Completed”.

Configure the client (or clients)

Next, you can see the client configuration associated with the server that we have seen previously. The only difference between the different clients.conf is the path of the certificates, for example. Very important that the cipher, tls-cipher and other parameters are exactly the same, otherwise it will not connect to the server. Remember that for Linux it must have a .conf extension and for Windows .ovpn.

# WE CONFIGURE IN THE CLIENT MODE, TUN MODE, UDP PROTOCOL.

client
dev tun
proto udp

#THIS DIRECTIVE IS THE CONNECTION WITH THE PUBLIC IP OR DOMAIN OF THE OPENVPN SERVER, WE ALSO HAVE TO PUT THE SAME SERVER PORT
remote 127.0.0.1 11949

# CONTINUOUSLY RESOLVE THE IP OR DOMAIN TO CONNECT US, KEY AND PERSISTENT TUN AS THE SERVER.
resolv-retry infinite
nobind
persist-key
persist-tun

#RUTA DE LA CA, CLIENT CERTIFICATES AND TA.KEY.
#IF WE HAVE IT IN THE SAME FOLDER, IT IS NOT NECESSARY TO PUT THE ENTIRE ROUTE.
ca ca.crt
cert client1-openvpn-redeszone.crt
key client1-openvpn-redeszone.key
tls-crypt ta.key

#CHECK THE SERVER IDENTITY, USE GCM SYMMETRIC ENCRYPTION, TLS 1.2 AND AUTH CONFIGURATION. If our client does not support TLS 1.3.
remote-cert-tls server
cipher AES-256-GCM
auth SHA512

compress

#If our client supports TLS 1.3, we add this directive:
# tls-ciphersuites TLS_AES_256_GCM_SHA384: TLS_CHACHA20_POLY1305_SHA256

#If our client supports TLS 1.2 only, we add this directive:
# tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384: TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256

# ENABLE VERBOSE LEVEL 3 LOG

verb 3

If you use Windows, the folder of the certificates with the configuration file in the extension .ovpn must be in the default OpenVPN path, which is C: UsersBronOpenVPNconfig by default, although we can change it. Once this is done, if we right click on OpenVPN in the lower right bar we will see the name of the client file to connect successfully. At the end of the boot you must put “Initialization Sequence Completed” and we will have successfully connected to the configured OpenVPN server.

Create static route in our router

In order to have connectivity with the local network of our home, it is necessary to create a static route in our home router. With the configuration of 10.8.0.0/24 that we have configured in the OpenVPN server, we must create a static route with this information:

• Subnet IP: 10.8.0.0
• Mask: 255.255.255.0
• Gateway: local IP where we start the OpenVPN server, if for example we have installed on a Raspberry PI with IP 192.168.1.100, we must put this IP.

Main problems and connection failures when connecting

When we first set up an OpenVPN server, we may have different problems connecting the different clients. Before listing the different problems and connection failures that may appear, we must tell you that if you have followed the tutorial step by step, you should not have any errors when connecting, since we have checked the configuration in detail. The configuration of both the server and the clients is in “verb 3”, that is, a recommended registration level for all users, in case of having a connection problem, if we do not find the failure we will have to increase the registration level , and put “verb 5” to have more details of everything that happens in the connection.

RESOLVE: Cannot resolve host address: xxxx.no-ip.org:11949 (Unknown host.)

This error is because the OpenVPN server cannot be found, we must check that the domain that we put is correct, this error is because it cannot find any public IP associated with that domain. The most common is that we have put the domain wrong in the VPN client, that the domain that we have entered does not exist because we have not created it yet, or because the dynamic DNS service is not working correctly.

Could not determine IPv4 / IPv6 protocol

This error is related to the previous one, we have entered a domain that it is not able to find, either using the IPv4 protocol or the IPv6 protocol.

SIGUSR1 [soft, init_instance] received, process restarting

This warning tells us that the connection process with the VPN server is going to be restarted, it simply indicates that there has been an error previously and that it is going to try the connection again.

MANAGEMENT:> STATE: 1603127258, WAIT ,,,,,,

Although this is not an error itself, if the OpenVPN client continually stays in this section of the connection, it is because we do not have any open ports on our router or firewall to the VPN server, depending on whether we have used TCP or UDP, and of the selected port, we must open one port or another. This is because the client is able to locate the IP address without problems, but it waits for a response from the OpenVPN server, a response that will never arrive.

This error also usually happens when we do not have the VPN server started, if we have forgotten to start it at the beginning, we will have this problem. The solution is to start it up and wait for the first clients to appear.

NOTE: –user option is not implemented on Windows

In Windows operating systems we do not need to put the “user nobody” directive, something that in Linux-based operating systems it is advisable to put it.

NOTE: –group option is not implemented on Windows

In Windows operating systems we do not need to put the “group nogroup” directive, something that in Linux-based operating systems it is advisable to put it.

WARNING: Ignoring option ‘dh’ in tls-client mode, please only include this in your server configuration

In the VPN client we do not have to put anything related to Diffie-Hellmann, this directive is only in the server configuration file, in the client it is simply unnecessary.

tls-crypt unwrap error: packet authentication failed and TLS Error: tls-crypt unwrapping failed from [AF_INET]

Authentication with the tls-crypt directive has failed, this is usually because the content of the ta.key file on the server and the clients is different. We must remember that the ta.key must be exactly the same both on the server and on all the VPN clients that we are going to use.

TLS Error: Unroutable control packet received from [AF_INET] and TLS Error: local / remote TLS keys are out of sync

The TLS keys that we have used are not correct on the server and / or client, it is necessary to check the configuration of the certificates and also the ta.key. This error occurs especially when we have the ta.key incorrectly configured.

TLS Error: Unroutable control packet received from

This is a general error of the TLS connection, you may have wrongly copied the CA, the server certificate (in the server settings), the client certificate (in the client settings). This error is due to a failure when copying the different certificates.

WARNING: ‘link-mtu’ is used inconsistently, local = ‘link-mtu 1549 ′, remote =’ link-mtu 1550 ′

This error appears because it is necessary that the MTU is the same both in local (client) and also in remote (VPN server), if the MTU is incorrectly configured, the connection will be established, but we will have a very low performance, and it is possible that the VPN connection is cut at any time.

This error also occurs when we have activated data compression on the VPN server, and we do not have it configured on the client. It also happens when we have different compression algorithm on server / clients. It is necessary for the server and the clients to use the same compression, or not to use compression, which is the most recommended for security.

To solve this error, just put the directive: «compress» on the client, so that it accepts the compression sent by the server through the «PUSH» it performs.

WARNING: ‘comp-lzo’ is present in remote config but missing in local config, remote = ‘comp-lzo’

This error occurs when on the VPN server we have activated data compression with comp-lzo, and on the clients we have no compression at all. It is necessary that both the server and the clients have exactly the same compression algorithm. To solve this error, just put the directive: «compress» on the client, so that it accepts the compression sent by the server through the «PUSH» it performs.

The error “write to TUN / TAP: Unknown error (code = 122)” may also appear due to this compression feature.

TLS Error: TLS handshake failed

An error occurred when negotiating the information on the control channel, it is possible that we have different tls-cipher or tls-ciphersuites and there is no common control channel algorithm, this causes the “handshake” to fail and cannot continue.

Updates and news in the new versions of OpenVPN

OpenVPN does not stop updating and releasing new versions with bug fixes, performance improvements and also security improvements, with the ultimate goal that VPN connections are as secure as possible. Next, we are going to explain some of the improvements that OpenVPN 2.5 will have that will come very soon, since it is in the “Release Candidate” phase.

Tls-crypt-v2 is added

tls-crypt is a functionality that allows us to mitigate DoS and DDoS attacks on OpenVPN servers, thanks to these keys that we create directly in OpenVPN, we will be able to make each client pre-authenticate, to later enter the authentication phase with their client certificate. The first version tls-crypt requires that both the server and all clients have the exact same tls-crypt key. With tls-crypt-v2 we can make each client have their own tls-crypt key, in this way, very large organizations or OpenVPN providers can adequately protect their servers by creating several of these keys.

ChaCha20-Poly1305 encryption support

Currently the most secure symmetric encryption that can be used on the data channel is AES-256-GCM and AES-128-GCM. With the latest version of OpenVPN 2.5 we will also have the possibility to choose the popular ChaCha20-Poly1305 encryption that uses VPN like WireGuard.

Enhanced encryption negotiation on the data channel

Closely related to the previous point, we have that in the new version of OpenVPN 2.5, the ncp-ciphers option has been renamed to data-ciphers, although the old name will continue to be accepted. The change is in order to avoid the ambiguity of “–cipher” and “–tls-cipher”. Now the VPN clients will tell the server what type of ciphers it supports, and the server will choose the first common cipher from the list of supported data ciphers, instead of using the first one on the list, which will make the VPN establishment be faster. This also allows us that if the server has the configuration of “data-ciphers” ChaCha20-Poly1305: AES-256-GCM, and the client has ChaCha20-Poly1305, it will use it because the client supports it.

Support for BF-CBC is removed in default settings

Now the default OpenVPN configuration will not allow using BF-CBC, the latest version will only accept AES-256-GCM and AES-128-GCM ciphers for the data channel. We must remember that in OpenVPN we have BG-CBC when we do not have the option of –cipher or –ncp-ciphers in the configuration. If you want to use this type of encryption, you will need to explicitly enable it.

We hope this manual has been helpful to you. If you have any questions you can comment, we recommend you visit the official OpenVPN HOWTO where you will find all the information about the different parameters to use. The MAN PAGE of OpenVPN 2.4 where you have all the parameters available is also very helpful.