openvpn-install

OpenVPN installer for Debian, Ubuntu, Fedora, CentOS and Arch Linux.

This script will let you setup your own secure VPN server in just a few minutes.

This repo is a simple fork of the OpenVPN installer from angristan which in turn is a fork of Nyr's original script. The fork this fork is based on is designed to be a hardened, more security focused setup.

My fork right here simply adds a few tweaks I think are better choices for a hardened OpenVPN server installation.

Any of these scripts are an excellent way to make it easy for anyone who possesses both basic computer skills and a few quid for a VPS to make their own VPN. But I do recommend either my one or agristan's one, because they build on the great work of Nyr's original to create more secure setups. And after all isn't security a top priority for a VPN?

Encrypting the Certificate Authority (CA)

When you create an OpenVPN server, you create your own CA. Think of this as being like TLS (SSL or HTTPS as it's more commonly known). When a site has that padlock on it, not only is the connection encrypted but the site has a certificate to verify you are really on the correct site. These certificates are issued to websites by third party CA's, for example Comodo and DigiCert are two of the most popular and recognisable. Recently Let's Encrypt has been growing especially on smaller non-commercial sites because they provide the certs for free in order to promote universal encryption.

An OpenVPN server does the same. When you connect, your device verifies the server has the correct certificate, and the server verifies the device is using a client configuration file that it's CA has signed off on. So when the server creates new client files to allow connections to your new VPN, it uses the CA to issue a new client access. This is a high level, simplified explanation, but those who think it's too dumbed down are people who likely know how a CA works anyway ;)

So back to this fork. Originally I just forked this to remove the "nopass" argument from the CA creation. This is a significant security measure because it encrypts your CA. So let's imagine a blackhat is able to gain unauthorised access to your server and steal your CA files, they would need a password to create new client files and allow themselves or anyone else access to your VPN. As the password is actually a decryption key, assuming it's a strong password (weak ones can be brute forced with relative ease), you can be pretty sure they won't be getting in. Of course it goes without saying if you detect an intrusion you should create a new CA and generate new client configs anyway. But you may not notice straight away.

On the other two scripts (at time of writing) the CA creation is still set with the "nopass" argument, presumably to prioritise convenience over security. This leaves the vitally sensitive CA keys sitting there unencrypted in plaintext. With this setup you do not need to enter a password to access the CA (e.g. when creating a new client file). But this also means that with those setups, should your server ever get breached, the attacker can then create as many client files as they want, therefore allowing as many new devices and users onto your VPN as they want. It is not at all uncommon to see stolen VPN credentials sold on the black market (e.g. hacker forums, darknet markets) where they will likely be purchased by malicious users who want to use the VPN to mask activity such as blackhat hacking, credit card fraud, etc.

Strictly speaking the most secure way to run a VPN is to have a seperate airgapped machine for the CA to run on. This way your CA keys are never stored on your server at all. But this is of course not easy to just automate via a script. There are some very good, well detailed articles on how to create such a setup manually, but it requires a lot more work. On the other hand, it also forces you to understand how VPN servers actually work. You'll know more about what it is you're actually setting up and what everything means and what each piece of the puzzle does. But a casual user is likely to favour a script that asks a few questions and does the hard work for them. Which is very understandable. But this script and the one I forked it from do also provide technical detail behind it all and give you the option to change advanced parts of the setup such as the type of encryption algorithm to use and how strong many bits you need.

More to come, watch this space!

The following is from angristian's project description:

Usage

First, get the script and make it executable :

curl -O https://raw.githubusercontent.com/Angristan/openvpn-install/master/openvpn-install.sh
chmod +x openvpn-install.sh

Then run it :

./openvpn-install.sh

You need to run the script as root and have the TUN module enabled.

The first time you run it, you'll have to follow the assistant and answer a few questions to setup your VPN server.

When OpenVPN is installed, you can run the script again, and you will get the choice to :

• Add a client
• Remove a client
• Uninstall OpenVPN

In your home directory, you will have .ovpn files. These are the client configuration files. Download them from your server and connect using your favorite OpenVPN client.

If you have any question, head to the FAQ first.

Headless install

It's also possible to run the script headless, e.g. without waiting for user input, in an automated manner.

Example usage:

AUTO_INSTALL=y ./openvpn-install.sh

# or

export AUTO_INSTALL=y
./openvpn-install.sh

A default set of variables will then be set, by passing the need for user input.

If you want to customise your installation, you can export them or specify them on the same line, as shown above.

• APPROVE_INSTALL=y
• APPROVE_IP=y
• IPV6_SUPPORT=n
• PORT_CHOICE=1
• PROTOCOL_CHOICE=1
• DNS=1
• COMPRESSION_ENABLED=n
• CUSTOMIZE_ENC=n
• CLIENT=clientname
• PASS=1

If the server is behind NAT, you can specify its endpoint with the ENDPOINT variable. If the endpoint is the public IP address which it is behind, you can use ENDPOINT=$(curl -4 ifconfig.co) (the script will default to this). The endpoint can be an IPv4 or a domain.

Other variables can be set depending on your choice (encryption, compression). You can search for them in the installQuestions() function of the script.

Password-protected clients are not supported by the headless installation method since user input is expected by Easy-RSA.

Features

• Installs and configures a ready-to-use OpenVPN server
• Iptables rules and forwarding managed in a seamless way
• If needed, the script can cleanly remove OpenVPN, including configuration and iptables rules
• Customisable encryption settings, enhanced default settings (see Security and Encryption below)
• OpenVPN 2.4 features, mainly encryption improvements (see Security and Encryption below)
• Variety of DNS resolvers to be pushed to the clients
• Choice to use a self-hosted resolver with Unbound (supports already existing Unbound installations)
• Choice between TCP and UDP
• NATed IPv6 support
• Compression disabled by default to prevent VORACLE. LZ4 (v1/v2) and LZ0 algorithms available otherwise.
• Unprivileged mode: run as nobody/nogroup
• Block DNS leaks on Windows 10
• Randomised server certificate name
• Choice to protect clients with a password (private key encryption)
• Many other little things!

Compatibility

The script supports these OS and architectures:

	i386	amd64	armhf	arm64
Arch Linux	❔	✅	❔	❔
CentOS 7	❔	✅	❌	✅
Debian 8	✅	✅	❌	❌
Debian 9	❌	✅	✅	✅
Debian 10	❔	✅	❔	❔
Fedora 27	❔	✅	❔	❔
Fedora 28	❔	✅	❔	❔
Ubuntu 16.04	✅	✅	❌	❌
Ubuntu 18.04	❌	✅	✅	✅
Ubuntu 19.04	❌	✅	✅	✅

To be noted:

• It should work on Debian 8+ and Ubuntu 16.04+. But versions not in the table above are not officially supported.
• The script requires systemd.
• The script is regularly tested against amd64 only.

Fork

This script is based on the great work of Nyr and its contributors.

Since 2016, the two scripts have diverged and are not alike anymore, especially under the hood. The main goal of the script was enhanced security. But since then, the script has been completely rewritten and a lot a features have been added. The script is only compatible with recent distributions though, so if you need to use a very old server or client, I advise using Nyr's script.

FAQ

LOOK AT THE WIKI FOR MORE INFORMATION. PLEASE READ BOTH BEFORE OPENING AN ISSUE.

PLEASE do net send me emails or private messages asking for help. The only place to get help is the issues. Other people may be able to help and in the future, other users may also run into the same issue as you.

Q: Which provider do you recommend?

A: I recommend these:

• Vultr: Worldwide locations, IPv6 support, starting at $3.50/month
• PulseHeberg: France, unlimited bandwidth, starting at €3/month
• Digital Ocean: Worldwide locations, IPv6 support, starting at $5/month

---

Q: Which OpenVPN client do you recommend?

A: If possible, an official OpenVPN 2.4 client.

• Windows: The official OpenVPN community client.
• Linux: The openvpn package from your distribution. There is an official APT repository for Debian/Ubuntu based distributions.
• macOS: Tunnelblick.
• Android: OpenVPN for Android.
• iOS: The official OpenVPN Connect client.

---

Q: Am I safe from the NSA by using your script?

A: Please review your threat models. Even if this script has security in mind and uses state-of-the-art encryption, you shouldn't be using a VPN if you want to hide from the NSA.

---

Q: Is there an OpenVPN documentation?

A: Yes, please head to the OpenVPN Manual, which references all the options.

---

Security and Encryption

OpenVPN's default settings are pretty weak regarding encryption. This script aims to improve that.

OpenVPN 2.4 was a great update regarding encryption. It added support for ECDSA, ECDH, AES GCM, NCP and tls-crypt.

If you want more information about an option mentioned below, head to the OpenVPN manual. It is very complete.

Most of OpenVPN's encryption-related stuff is managed by Easy-RSA. Defaults parameters are in the vars.example file.

Compression

By default, OpenVPN doesn't enable compression. This script provides support for LZ0 and LZ4 (v1/v2) algorithms, the latter being more efficient.

However, it is discouraged to use compression since it since the VORACLE attack makes use of it.

TLS version

OpenVPN accepts TLS 1.0 by default, which is nearly 20 years old.

With tls-version-min 1.2 we enforce TLS 1.2, which the best protocol available currently for OpenVPN.

TLS 1.2 is supported since OpenVPN 2.3.3.

Certificate

OpenVPN uses an RSA certificate with a 2048 bits key by default.

OpenVPN 2.4 added support for ECDSA. Elliptic curve cryptography is faster, lighter and more secure.

This script provides:

• ECDSA: prime256v1/secp384r1/secp521r1 curves
• RSA: 2048/3072/4096 bits keys

It defaults to ECDSA with prime256v1.

OpenVPN uses SHA-256 as the signature hash by default, and so does the script. It provides no other choice as of now.

Data channel

By default, OpenVPN uses BF-CBC as the data channel cipher. Blowfish is an old (1993) and weak algorithm. Even the official OpenVPN documentation admits it.

The default is BF-CBC, an abbreviation for Blowfish in Cipher Block Chaining mode.

Using BF-CBC is no longer recommended, because of its 64-bit block size. This small block size allows attacks based on collisions, as demonstrated by SWEET32. See https://community.openvpn.net/openvpn/wiki/SWEET32 for details.

Security researchers at INRIA published an attack on 64-bit block ciphers, such as 3DES and Blowfish. They show that they are able to recover plaintext when the same data is sent often enough, and show how they can use cross-site scripting vulnerabilities to send data of interest often enough. This works over HTTPS, but also works for HTTP-over-OpenVPN. See ​https://sweet32.info/ for a much better and more elaborate explanation.

OpenVPN's default cipher, BF-CBC, is affected by this attack.

Indeed, AES is today's standard. It's the fastest and more secure cipher available today. SEED and Camellia are not vulnerable to date but are slower than AES and relatively less trusted.

Of the currently supported ciphers, OpenVPN currently recommends using AES-256-CBC or AES-128-CBC. OpenVPN 2.4 and newer will also support GCM. For 2.4+, we recommend using AES-256-GCM or AES-128-GCM.

AES-256 is 40% slower than AES-128, and there isn't any real reason to use a 256 bits key over a 128 bits key with AES. (Source : 1,2). Moreover, AES-256 is more vulnerable to Timing attacks.

AES-GCM is an AEAD cipher which means it simultaneously provides confidentiality, integrity, and authenticity assurances on the data.

The script supports the following ciphers:

• AES-128-GCM
• AES-192-GCM
• AES-256-GCM
• AES-128-CBC
• AES-192-CBC
• AES-256-CBC

And defaults to AES-128-GCM.

OpenVPN 2.4 added a feature called "NCP": Negotiable Crypto Parameters. It means you can provide a cipher suite like with HTTPS. It is set to AES-256-GCM:AES-128-GCM by default and overrides the --cipher parameter when used with an OpenVPN 2.4 client. For the sake of simplicity, the script set both the --cipher and --ncp-cipher to the cipher chosen above.

Control channel

OpenVPN 2.4 will negotiate the best cipher available by default (e.g ECDHE+AES-256-GCM)

The script proposes the following options, depending on the certificate:

• ECDSA:
  • TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
  • TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
• RSA:
  • TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
  • TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384

It defaults to TLS-ECDHE-*-WITH-AES-128-GCM-SHA256.

Diffie-Hellman key exchange

OpenVPN uses a 2048 bits DH key by default.

OpenVPN 2.4 added support for ECDH keys. Elliptic curve cryptography is faster, lighter and more secure.

Also, generating a classic DH keys can take a long, looong time. ECDH keys are ephemeral: they are generated on-the-fly.

The script provides the following options:

• ECDH: prime256v1/secp384r1/secp521r1 curves
• DH: 2048/3072/4096 bits keys

It defaults to prime256v1.

HMAC digest algorithm

From the OpenVPN wiki, about --auth:

Authenticate data channel packets and (if enabled) tls-auth control channel packets with HMAC using message digest algorithm alg. (The default is SHA1 ). HMAC is a commonly used message authentication algorithm (MAC) that uses a data string, a secure hash algorithm, and a key, to produce a digital signature.

If an AEAD cipher mode (e.g. GCM) is chosen, the specified --auth algorithm is ignored for the data channel, and the authentication method of the AEAD cipher is used instead. Note that alg still specifies the digest used for tls-auth.

The script provides the following choices:

• SHA256
• SHA384
• SHA512

It defaults to SHA256.

tls-auth and tls-crypt

From the OpenVPN wiki, about tls-auth:

Add an additional layer of HMAC authentication on top of the TLS control channel to mitigate DoS attacks and attacks on the TLS stack.

In a nutshell, --tls-auth enables a kind of "HMAC firewall" on OpenVPN's TCP/UDP port, where TLS control channel packets bearing an incorrect HMAC signature can be dropped immediately without response.

About tls-crypt:

Encrypt and authenticate all control channel packets with the key from keyfile. (See --tls-auth for more background.)

Encrypting (and authenticating) control channel packets:

• provides more privacy by hiding the certificate used for the TLS connection,
• makes it harder to identify OpenVPN traffic as such,
• provides "poor-man's" post-quantum security, against attackers who will never know the pre-shared key (i.e. no forward secrecy).

So both provide an additional layer of security and mitigate DoS attacks. They aren't used by default by OpenVPN.

tls-crypt is an OpenVPN 2.4 feature that provides encryption in addition to authentication (unlike tls-auth). It is more privacy-friendly.

The script supports both and uses tls-crypt by default.

Say thanks

You can say thanks if you want!

Credits & Licence

Many thanks to the contributors and Nyr's original work.

This project is under the MIT Licence