This section controls how the VPN encrypts and validates traffic to and from peers.
TLS, or Transport Layer Security, can provide session authentication and encryption to ensure the validity of peers and to protect the control channel.
When using an SSL/TLS mode the best practice is to use TLS Authentication. In addition to the added security benefit from the key requirement, a TLS key also protects against some SSL-based attacks such as Heartbleed which could otherwise compromise the VPN using the control channel.
- Use a TLS Key
Check the box to make the VPN utilize a TLS key. When unchecked the GUI hides the remaining related options.
- Automatically generate a shared TLS authentication key
The GUI offers this option when there is no existing TLS key. Leave this checked so the firewall will generate a new TLS key automatically when the instance is saved. Otherwise, uncheck the box to display the TLS Key field and paste in a TLS key.
When generating the key automatically, return to the edit screen for this tunnel later to obtain the key, then copy the key to the remote peer.
- TLS Key
A text area containing the TLS key for this instance. This type of key is specific to OpenVPN and is not the same type of key used for an OpenSSL certificate.
To generate a new key manually, use the command
openvpn --genkey secret /dev/stdoutfrom a shell command prompt (SSH, console, or GUI). On systems with older versions of OpenVPN, use
openvpn --genkey --secret /dev/stdoutinstead.
- TLS Key Usage Mode
- TLS Authentication
In TLS Authentication mode OpenVPN uses the TLS key for HMAC authentication of control channel packets, protecting the peers from unauthorized connections.
- TLS Encryption and Authentication
In TLS Encryption and Authentication mode OpenVPN uses the key for authentication, as above, but it also uses the key to encrypt control channel communication. This provides increased privacy and traffic control channel obfuscation.
In some cases this can also help OpenVPN avoid detection by network systems which identify OpenVPN traffic by its control packets.
- TLS keydir Direction
The direction in which this VPN endpoint uses the TLS key. The TLS Key Direction must be set to complementary values on the server and clients. The default behavior uses
0on server instances and
1on client instances.
For example, if the server is set to
0, clients must be set to
1. Both peers may omit the direction in which case the TLS Key will be used bidirectionally.
Peer Certificate Revocation List¶
This optional field is for the Certificate Revocation List (CRL) this tunnel will use to check the validity of peer certificates.
A CRL is a list of certificates signed by a CA which are no longer valid. This could be due to a certificate being compromised or lost, such as from a stolen laptop, spyware infection, etc.
If there are no entries in this list, first import or generate a CRL at System > Cert Manager, on the Certificate Revocation tab.
When set, OpenVPN will attempt to confirm client certificate validity using Online Certificate Status Protocol (OCSP) against the site listed in the OCSP URL field.
The certificate used by the VPN instance to identify itself to peers. This certificate must contain appropriate properties marking it as a server certificate and not a user or client certificate.
If there are no entries in this list, first import or generate a certificate under System > Cert Manager, on the Certificates tab.
DH Parameters Length¶
The Diffie-Hellman (DH) key exchange parameters are used for establishing a secure communications channel. They may be regenerated at any time, and they are not specific to an OpenVPN instance. When importing an existing OpenVPN configuration these parameters do not need to be copied from the previous server nor does it require generating new parameters. The length of the desired DH parameters may be chosen from the drop-down box, either 1024, 2048, or 4096. There is an additional choice for ECDH Only which disables traditional DH parameters and uses only ECDH.
Due to the heavy computation involved in generating DH keys, the firewall contains a pre-generated set of keys for several common lengths as specified in RFC 7919. The DH group values specified in the RFC have been audited for security and are the safest values for use by end-users.
Should a use case require custom DH keys, generate new DH parameters manually by using the following shell commands:
# /usr/bin/openssl dhparam 2048 > /etc/dh-parameters.2048 # /usr/bin/openssl dhparam 3072 > /etc/dh-parameters.3072 # /usr/bin/openssl dhparam 4096 > /etc/dh-parameters.4096
Configures a specific elliptic curve to use for Elliptic Curve Diffie-Hellman key exchanges. This is only for use with ECDH TLS encryption.
OpenVPN uses the curve from the server certificate by default when configured with an ECDSA certificate. Otherwise, OpenVPN uses secp384r1 as a fallback.
These options define the cryptographic ciphers OpenVPN will use for this VPN.
At this time the only algorithm compatible with OpenVPN Data Channel Offload (DCO) is
AES-256-GCM. When DCO is active these options are hidden to prevent
- Data Encryption Negotiation
When set, OpenVPN will attempt to negotiate a compatible set of acceptable cryptographic data encryption algorithms from those selected in the Data Encryption Algorithms list.
This allows the client and server to agree on the most preferable cipher available without limiting the VPN to a single cipher. Legacy clients can still connect so long as the cipher they use is present in the list.
Disabling this feature is deprecated. The option remains as a mechanism for legacy compatibility but it should not be disabled unless absolutely necessary.
- Data Encryption Algorithms
The list of Data Encryption Algorithms OpenVPN may use for this VPN, in order of preference. The default selection uses AES-GCM in 256 and 128 bit varieties as well as ChaCha20-Poly135.
The best practice is to use AEAD ciphers such as AES-GCM and ChaCha20-Poly135. These ciphers combine encryption and authentication and thus do not require a separate hash algorithm. Aside from offering strong security, they are typically much faster than other ciphers as well.
This feature is only supported in client/server mode, which means it only works with SSL/TLS modes where the tunnel network is large enough for multiple clients (e.g. larger than a
In shared key mode or when using a
/30tunnel network, OpenVPN only uses the value of Fallback Data Encryption Algorithm.
- Fallback Data Encryption Algorithm
The Data Encryption Algorithm OpenVPN will use when it cannot negotiate an algorithm automatically. OpenVPN uses this value for shared key tunnels and for SSL/TLS configurations only capable of using a single client (
OpenVPN also uses this algorithm for older legacy clients which not only cannot negotiate a data encryption algorithm but have been compiled for a “small footprint”, such as embedded devices.
The default is AES-128-CBC, which is AES 128 bit Cipher Block Chaining. This is a fine choice for most scenarios.
Hardware Crypto for more information on using cryptographic accelerators and choosing an encryption algorithm.
Auth Digest Algorithm¶
Selects the message digest algorithm OpenVPN uses for HMAC authentication of incoming packets. This is used for the data channel and if also for the control channel when the tunnel uses a TLS key. The GUI default of SHA256 is a good balance of security and speed.
When using AEAD ciphers such as AES-GCM, OpenVPN ignores this value for the data channel since AEAD ciphers already perform authentication. Even with an AEAD cipher, OpenVPN still uses this algorithm to authenticate the control channel when the tunnel uses a TLS key.
OpenVPN defaults to SHA1 when this option omitted from its configuration. Unless both sides are set to a known value, use SHA1 here.
If available, this option controls which hardware cryptographic accelerator will be used by OpenVPN. When left unspecified, OpenVPN will choose automatically based on what is available in the operating system to accelerate ciphers OpenVPN wants to use.
Some hardware acceleration, such as AES-NI, happens automatically in OpenVPN via OpenSSL and cannot be enabled or disabled by this option.
In most common deployments this setting is unnecessary as the automatic behavior of OpenVPN is correct.
This option limits the valid length of a certificate chain. The default value limits a chain to One (Client+Server). With that value, if an unauthorized intermediate CA signs a certificate, certificates signed by the rogue intermediate would fail validation. In cases when the certificate stricture requires chaining with intermediates, raise this limit to accommodate the longest allowed chain.
Strict User-CN Matching¶
Controls whether the firewall will enforce a strict match between the username supplied by the user and the Common Name of their user certificate when the firewall authenticates a user. When enabled, authentication fails if the two values do not match.
This prevents users from using their own credentials with the certificate from a different user and vice versa.
Client Certificate Key Usage Validation¶
When set, the authentication process verifies that a certificate supplied by a client contains the appropriate certificate properties to act as a client. This means that the certificate must include the extended key usage attribute for “TLS Web Client Authentication”.
This prevents using certificates made for different purposes, such as e-mail signing or acting only as a server, from being used as a VPN client certificate.