Additional security command line options

Change the encryption cipher for server and client

The default encryption cipher, as of Access Server 2.5, is now AES-256-CBC. Previous versions used BF-CBC which was considered secure at the time, but no longer. The default of AES-256 is considered secure and meets stringent security requirements. OpenVPN clients like OpenVPN Connect and others based on OpenVPN 2.4 or higher should automatically upgrade this to AES-256-GCM. This is the same level of encryption but has a benefit in speed as it combines encryption and signing in one step instead of in two separate steps.

As of Access Server version 2.5, we have introduced two new configuration keys that you can use to alter the cipher used by clients and the server. If you install a fresh Access Server 2.5 or newer, the Access Server will automatically create these two configuration keys, and set them to the default cipher, AES-256-CBC.

If you migrate old data from an older Access Server, or if you upgrade an older Access Server, these configuration keys are not added automatically. The Access Server assumes you want to use BF-CBC. This maintains backward compatibility, as changing the cipher can break an existing VPN client’s ability to connect. If you have specified OpenVPN directives to change the cipher to a custom setting in Server Config Directives or Client Config Directives under the Advanced VPN configuration in your server’s Admin Web UI, you will need to remove the entries from those fields and implement the new configuration keys, should you migrate/update from a version older than Access server 2.5 to something newer.

The following information pertains to Access Server 2.5 and newer. The ciphers used must be one of the allowed types and must be the same on server and client side. For all commands using the sacli program, execute the commands as root user in this directory: /usr/local/openvpn_as/scripts/.

View current cipher configuration keys (if defined):

 ./sacli ConfigQuery | grep "cipher"

Remove cipher configuration keys to make Access Server assume old BF-CBC cipher:

./sacli --key "vpn.client.cipher" ConfigDel
./sacli --key "vpn.server.cipher" ConfigDel
./sacli start

Set the cipher configuration key to the desired cipher:

./sacli --key "vpn.client.cipher" --value <CIPHER> ConfigPut
./sacli --key "vpn.server.cipher" --value <CIPHER> ConfigPut
./sacli start

Valid values for <CIPHER>:

  • DES-CBC
  • RC2-CBC
  • DES-EDE-CBC
  • DES-EDE3-CBC
  • DESX-CBC
  • BF-CBC
  • RC2-40-CBC
  • CAST5-CBC
  • RC2-64-CBC
  • AES-128-CBC
  • AES-192-CBC
  • AES-256-CBC
  • none

Mid-session TLS encryption key renegotiation

The mid-session TLS encryption key renegotiation refers to when an OpenVPN session renegotiates the underlying TLS session and the encryption key used. The server or client may trigger the renegotiation. Normally this renegotiation is invisible to the end-user on Access Server because the session token, if still valid, will be used as an authentication proxy/token. The default value for this renegotiation is 60 minutes (1 hour) as of Access Server 2.9.3. Previous versions use the default value of 360 minutes (6 hours). If you upgrade Access Server from a previous version to 2.9.3 or greater, the 360 minute value stays.

Session expiration is tested during TLS renegotiation which occurs automatically at the specified schedule with this setting or when the connection is disrupted and reconnects. So if you change the session token expiration, make sure to adjust this parameter as well, or the session may not expire at the moment you expect. You can change this setting in the Admin Web UI or via command line.

To change this in the Admin Web UI:

  1. Sign in to Admin Web UI.
  2. Click Configuration > Advanced VPN.
  3. Enter the new value under Connection Security Refresh.
  4. Click Save Settings, then Update Running Server.

To change this using the command line, set the specific configuration key with sacli. Ensure you are connected with root privileges and run the commands below from the directory, /usr/local/openvpn_as/scripts/.

Change the mid-session TLS renegotiation period (default 60 minutes):

./sacli --key "vpn.tls_refresh.interval" --value <MINUTES> ConfigPut
./sacli start

Restore this value to default:

./sacli --key "vpn.tls_refresh.interval" --value "60" ConfigPut
./sacli start

Note: The OpenVPN protocol has a parameter that determines after how many bytes a key should be renegotiated (no configuration key in Access Server). If you use BF-CBC, to prevent any possible gathering of enough data to exploit the BF-CBC encryption cipher flaw for these installations, the key renegotiation byte threshold is set at around 60 megabytes on up-to-date OpenVPN client programs. This forces a key refresh more often which mitigates the vulnerability in the Blowfish (BF-CBC) cipher.

Authentication failure lockout policy

As a security precaution Access Server automatically locks out user accounts with server-locked profiles after repeated failed authentications. The same happens with failed authentication on the web services. The user account lock is temporary. When repeated authentication failures occur through a server-locked profile in OpenVPN Connect, or the Client UI, the user is temporarily banned from further login attempts. This prevents brute-forcing the password by endlessly trying different passwords. When this lockout is triggered on an account the user receives a message like “LOCKOUT” or “user temporarily locked out due to multiple authentication failures”. By default, the lockout is triggered when a wrong password is entered three times consecutively. The lockout expires after 15 minutes. Lockouts can also be lifted manually by the administrator. The lockout policy is not triggered by a user-locked profile on an OpenVPN client program since this requires a valid connection profile with certificates. The connection is also secured with the user’s personal certificate and key.

Configure the lockout policy with the settings below.

Set the number of authentication failures after which the user will be locked out (default is 3):

./sacli --key "vpn.server.lockout_policy.n_fails" --value <NUMBER> ConfigPut
./sacli start

Release the lockout on a user after the specified amount of seconds passes (default is 900 seconds, or 15 minutes):

./sacli --key "vpn.server.lockout_policy.reset_time" --value <SECONDS> ConfigPut
./sacli start

Maximum size of lockout dictionary (default is 10000):

./sacli --key "vpn.server.lockout_policy.max_history" --value <BYTES> ConfigPut
./sacli start

The lockout dictionary tracks all of the hashes of wrong passwords entered by users recently. Unless you have thousands of users repeatedly entering incorrect passwords then the default value should be more than fine, and if you do have such a situation, increase the dictionary size. If the dictionary reaches its maximum size it will eventually be purged. The consequence of this dictionary reaching its limits with thousands of users entering wrong passwords is that if the failed authentication attempts are spread far enough apart (hours) that the number of authentication failures can be higher than configured. If however the failed authentication attempts occur shortly after one another then the number of authentication failures per user will be adhered to just fine. Generally you never need to adjust this value except in extreme circumstances. We recommend you do not change this value.

As mentioned an exception to the lockout policy is for authentication attempts made with a valid user-locked connection profile. It is after all reasonable to assume that someone in possession of a valid user-locked profile is not a random person trying to brute-force.

Note: if you’re using an external authentication system, that system might have its own lockout policy that can still be triggered. Additionally the so-called “bootstrap” users, which are special administrative users of which by default only one exists, are also an exception to the lockout policy.

An initial installation of Access Server includes an administrative bootstrap user, openvpn. This user account can always log in and does not adhere to the lockout policy. This account is meant to initially set up the server and to serve as a way to gain access to the Admin Web UI even if an external authentication backend like LDAP or RADIUS is failing. This allows you to correct any problems with LDAP/RADIUS settings in the Admin Web UI. In our security recommendations to secure the openvpn administrative user account we specifically advise you to disable this special bootstrap user after initial setup.

If you wish to manually unlock a locked-out user, follow the steps below. It is important to note that at this time it is not possible to unlock a single specific user. We recommend doing the following: set the automatic lockout reset period to one second, allow time for all lockouts to reset, then set the lockout period back to its previous value. The example command lines reset the lockout to the default 15 minutes (900 seconds):

./sacli --key "vpn.server.lockout_policy.reset_time" --value "1" ConfigPut
./sacli start
sleep 2
./sacli --key "vpn.server.lockout_policy.reset_time" --value "900" ConfigPut
./sacli start
service openvpnas restart

TLS control channel security

You can configure the TLS Control Channel security through the Admin Web UI under Configuration > Advanced VPN. You can also make changes from the command line. For detailed information, refer to TLS Control Channel Security in OpenVPN Access Server.

Google Authenticator multi-factor authentication

This documentation section was moved to: Google Authenticator multi-factor authentication

Selecting TLS level for the OpenVPN daemons

Current versions of Access Server use TLS 1.2 as the default for the OpenVPN daemons. Older clients may not be able to handle TLS 1.1 or newer. For example an OpenVPN client from 2014 or older will not be able to connect to an OpenVPN server that requires TLS 1.1 or TLS 1.2. If your current Access Server is set to TLS on the OpenVPN daemons and you have OpenVPN connection profiles and client software installed on a large number of clients, we recommend you stay with TLS 1.0 and not upgrade. Likewise the reverse is true if for some reason you want to downgrade from TLS 1.1 or later. The reason for this is that connection profiles can be either configured for the old method where TLS 1.0 is assumed, or for the new method where a minimum version of TLS is configured in the connection profile and it then expects that version or higher to be present. In other words, switching it between TLS 1.0 and TLS 1.1/1.2/1.3 will require that some clients need a new copy of the connection profile or need to be updated or reinstalled. It is important to be aware of these consequences before changing the setting.

As of OpenVPN Access Server 2.1.12 the default OpenVPN daemons TLS setting is 1.2. During upgrades from older versions the previous setting is maintained to avoid breaking existing setups. The minimum TLS level setting for the OpenVPN daemons can be configured in the Admin Web UI in TLS Settings. Below are the commands to reconfigure this on the command line.

Set minimum allowed TLS level to 1.0 (legacy):

./sacli --key "vpn.server.tls_version_min" --value "1.0" ConfigPut

Set minimum allowed TLS level to 1.1:

./sacli --key "vpn.server.tls_version_min" --value "1.1" ConfigPut

Set minimum allowed TLS level to 1.2 (the default):

./sacli --key "vpn.server.tls_version_min" --value "1.2" ConfigPut

Set minimum allowed TLS level to 1.3:

./sacli --key "vpn.server.tls_version_min" --value "1.3" ConfigPut

Disable use of client certificates

OpenVPN Access Server uses unique client certificates and private keys as an important piece of the security of the OpenVPN protocol. Each user account has a unique public key and private key that when combined uniquely identify the client to the server. The public key and private key pair also has an important role in encrypting and decrypting traffic.

The use of these client certificates is enabled by default and managed automatically by the OpenVPN Access Server, and we strongly recommend against disabling it. However, in rare cases, for example within networks that are already secured, you may want to lower overhead and use the Access Server program purely for its VPN tunneling functions without requiring unique certificates for your users. If the use of client certificates is disabled, username and password authentication is used instead. Note that this practice degrades the security of the OpenVPN protocol.

With client certificates disabled, the Access Server no longer uses the certificate database file. However, the Access Server still requires access to specific certificates and keys to handle encryption and decryption, and for basic functionality. Therefore, it is necessary to copy the required files from the certificate database file and into the configuration database.

Beginning with version 2.8.8, these steps are required to disable client certificates:

Copy the required files into the configuration database:

cd /usr/local/openvpn_as/scripts
mkdir -p server-certs
./sacli -o server-certs GetServer
pushd server-certs
../confdba -mk external_pki.ca_crt --value_file ca.crt
../confdba -mk external_pki.server_crt --value_file server.crt
../confdba -mk external_pki.server_key --value_file server.key
../confdba -mk external_pki.ta_key --value_file ta.key
../confdba -mk external_pki.dh_pem --value_file dh*.pem
../confdba -mk external_pki.auth_token_key --value_file auth_token.key
popd
nano /usr/local/openvpn_as/etc/as.conf

Scroll to the bottom and add this line:

no_client_cert=true
  1. Restart the OpenVPN Access Server service:
service openvpnas restart

After the service restarts, Access Server will function without client certificates. Any connection profiles generated by Access Server won’t include the public key or private key for a client, and connections are possible with only username and password authentication.

In Access Server version 2.6.1 and previous, only four files need to be copied from the certificate database file and into the configuration database:

  • CA certificate: ca.crt
  • Server certificate: server.crt
  • TLS auth shared key: ta.key
  • Diffie Hellman parameters: dh*.pem

In Access Server 2.8.8 and above, these five files need to be copied from the certificate database file and into the configuration database, as noted in Step 1 above:

  • CA certificate: ca.crt
  • Server certificate: server.crt
  • TLS auth shared key: ta.key
  • Diffie Hellman parameters: dh*.pem
  • Auth token shared key: auth_token.key

If you want  to set this up with Access Server version 2.6.1, remove this line from Step 1 above, and then run the command:

../confdba -mk external_pki.auth_token_key --value_file auth_token.key

Error message: Parameter \”external_pki.auth_token_key\” is missing from the configuration file.

If you receive this error message after upgrading your Access Server, its services will not start. You must reinstate the use of client certificates, restart the service to create new tokens, and then revert the use of client certificates setting back to disabled:

Edit the as.conf file:

nano /usr/local/openvpn_as/etc/as.conf

Delete the no_client_cert option:

no_client_cert=true

Restart the OpenVPN Access Server service:

service openvpnas restart

Run the configuration commands:

cd /usr/local/openvpn_as/scripts
mkdir -p server-certs
./sacli -o server-certs GetServer
pushd server-certs
../confdba -mk external_pki.ca_crt --value_file ca.crt
../confdba -mk external_pki.server_crt --value_file server.crt
../confdba -mk external_pki.server_key --value_file server.key
../confdba -mk external_pki.ta_key --value_file ta.key
../confdba -mk external_pki.dh_pem --value_file dh*.pem
../confdba -mk external_pki.auth_token_key --value_file auth_token.key
popd

Edit the as.conf file again:

nano /usr/local/openvpn_as/etc/as.conf

Add the command to disable the use of client certificates back in:

no_client_cert=true

Restart the OpenVPN Access Server service:

service openvpnas restart