(Jan 2019)
OpenVPN uses a custom protocol to establish a virtual private network — TLS for session authentication and IPSec ESP for secure tunnel transport over UDP. It support multiple platforms.
The basic OpenVPN server and client are GPL licensed, but the OpenVPN company offers several feature-enhanced commercial products (e.g., OpenVPN Accesses Server).
OpenVPN authenticates clients using pre-shared secret keys, certificates, username/password, or any method with a PAM module.
Pre-shared key vs certs:
Static key encryption mode has certain advantages, the primary being ease of configuration.
There are no certificates or certificate authorities or complicated negotiation handshakes and protocols. The only requirement is that you have a pre-existing secure channel with your peer (such as ssh ) to initially copy the key. This requirement, along with the fact that your key never changes unless you manually generate a new one, makes it somewhat less secure than TLS mode (see below). If an attacker manages to steal your key, everything that was ever encrypted with it is compromised. Contrast that to the perfect forward secrecy features of TLS mode (using Diffie Hellman key exchange), where even if an attacker was able to steal your private key, he would gain no information to help him decrypt past sessions.
Another advantageous aspect of Static Key encryption mode is that it is a handshake-free protocol without any distinguishing signature or feature (such as a header or protocol handshake sequence) that would mark the ciphertext packets as being generated by OpenVPN. Anyone eavesdropping on the wire would see nothing but random-looking data.
In most scenarios, we want a public key infrastructure for OpenVPN. Minimally, this consists of:
Using its own key, the CA signs the certs for the clients and OpenVPN server. Because both the clients and server trust the CA, they can mutually verify the authenticity of each other’s identity. The server trusts the CA, and can verify that the client’s cert was signed by that CA. The client trusts the CA, and can verify that the server’s cert was signed by that CA.
To disable access of a particular client to the OpenVPN server, add that client’s certificate to the servers certificate revocation list (CRL).
The OpenVPN server can enforce client-specific access rights based on embedded cert fields, like Common Name.
Bear in mind is that the client necessarily sends its cert in plain text, so eavesdroppers see the cert values.
As described in openvpn(8), the OpenVPN client supports fallback redundancy.
The client tries servers we specify with <connection> profiles until it connects to one.
The --remote-random flag selects amount connections at random.
openvpn(8)