Cryptographic Settings¶

This section controls how the VPN encrypts and validates traffic to and from peers.

Shared Key¶

Danger

Shared key mode has been deprecated by OpenVPN as it is no longer considered sufficiently secure for modern requirements.

Shared key mode will be removed from future versions of OpenVPN. Users should not create any new shared key tunnels and should immediately convert any existing shared key tunnels to SSL/TLS mode.

When an SSL/TLS instance is configured with a /30 tunnel network it behaves in a similar manner to shared key mode. The primary difference is the need to create and distribute the certificate structure to peers. See OpenVPN Site-to-Site Configuration Example with SSL/TLS for information on configuring OpenVPN in SSL/TLS mode.

When using a shared key instance, either check the Automatically generate a shared key box to make a new key, or uncheck the box to paste in a shared key from an existing OpenVPN tunnel. When generating the key automatically, return to the edit screen for this tunnel later to obtain the key which may be copied to the remote router.

TLS Authentication¶

TLS, or Transport Layer Security, can provide session authentication and encryption to ensure the validity of peers and to protect the control channel.

Warning

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.

Tip

To generate a new key manually, use the command openvpn --genkey secret /dev/stdout from a shell command prompt (SSH, console, or GUI). On systems with older versions of OpenVPN, use openvpn --genkey --secret /dev/stdout instead.

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.

Tip

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 0 on server instances and 1 on 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 Authority¶

Select the certificate authority which signed the client or peer certificate(s) for this OpenVPN server instance.

Tip

If there are no entries in this list, first import or generate a certificate authority under System > Cert Manager, on the CAs tab.

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.

Tip

If there are no entries in this list, first import or generate a CRL at System > Cert Manager, on the Certificate Revocation tab.

OCSP Check¶

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.

Server Certificate¶

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.

Tip

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.

Note

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

ECDH Curve¶

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.

Encryption algorithm¶

These options define the cryptographic ciphers OpenVPN will use for this VPN.

Warning

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 invalid selections.

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.

Note

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.

Note

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 /30).

In shared key mode or when using a /30 tunnel 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 (/30 tunnel network).

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.

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.

Note

OpenVPN defaults to SHA1 when this option omitted from its configuration. Unless both sides are set to a known value, use SHA1 here.

Certificate Depth¶

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.