Change the encryption cipher for server and client
As of Access Server 2.5 we now use by default the encryption cipher AES-256-CBC. Older versions used BF-CBC. Since the OpenVPN programs used work with a single encryption scheme, meaning that clients and server must all agree to use the same encryption cipher, it is not possible to alter this from one side without affecting connectivity. If you change the cipher on an existing installation of Access Server, be prepared to reprovision or reinstall your already installed clients, so that they are updated correctly with instructions to use the new cipher, or they may simple be unable to connect. There is no automatic provisioning solution to automate this included in Access Server or the Connect Client. An exception is the OpenVPN Connect Client for Windows and macOS, if a server-locked profile is used. Those are updated automatically with the new cipher settings.
As of Access Server version 2.5, we have introduced 2 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 2 configuration keys, and set these to AES-256-CBC, which is the current default for new Access Server 2.5+ installations. If you migrate old data from an older Access Server, or if you do an upgrade from an older Access Server, these configuration keys are not added automatically, and the Access Server will then assume you want to use BF-CBC, which was the old standard used on Access Server 2.1.12 and older. This way, we can maintain backward compatibility. If in the past you used the fields client config directives and server config directives in the Advanced VPN page of the Admin UI on an older Access Server to change the cipher to a custom setting, and have now migrated/updated to Access Server 2.5 or newer, then please remove these entries from those fields, and implement the new configuration keys instead.
The following information is valid only on Access Server 2.5 and newer. And of course the ciphers used must be one of the allowed type and must be the same on server and client side.
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>:
Mid-session TLS encryption key renegotiation
In the Admin UI this setting can be found in the Advanced VPN section. But it can also be controlled through the command line with a specific configuration key. This mid-session TLS renegotiation period controls when an OpenVPN client session will renegotiate the underlying SSL/TLS session and therefore the encryption key used. Normally this renegotiation is invisible to the end-user because the session token, if still valid, will be used as an authentication proxy/token. By default, this value is set to 360 minutes (6 hours). Session expiration will only be tested for 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 else the connection may not stop at the exact threshold that the session token timeout is set to, which may lead to connections that last longer than what you set your session token expiration parameter to.
Change the mid-session TLS renegotiation period (default 360 minutes):
./sacli --key "vpn.tls_refresh.interval" --value <MINUTES> ConfigPut ./sacli start
Restore this value to default:
./sacli --key "vpn.tls_refresh.interval" --value "360" ConfigPut ./sacli start
It is important to note that there is also a parameter in the OpenVPN protocol (no configuration key in Access Server) that determines after how many bytes a key should be renegotiated, and that in the past, Blowfish was the encryption cipher used, and we use this additional bytes threshold parameter for vulnerability mitigation. Unfortunately a flaw was found in Blowfish not so long ago that could be abused if enough data was gathered that used the same encryption key. To resolve this we have moved to AES-256 as the default but still allow Blowfish on older installations and clients, but have set the key renegotiation byte threshold at around 60 megabytes on up-to-date OpenVPN client programs, to prevent any possible gathering of enough data to exploit that particular flaw in the Blowfish encryption cipher.
Authentication failure lockout policy
As a security precaution the Access Server automatically locks out user accounts temporarily when authentication attempts fail repeatedly when using a server-locked profile in Connect Client, or when using the web services directly. The lockout policy will not be triggered when a user-locked profile is used with an OpenVPN client program since this requires that the user already has a valid connection profile with certificates for his account, and to be in possession of such a file you would most likely already have the correct credentials anyways (unless you stole the file from a user somehow – in which case the certificate should be revoked by an administrator), and the connection itself is also secured with the user’s personal certificate and key so it is extremely unlikely to be intercepted in some way. When repeated authentication failures occur through a server-locked profile in Connect Client, or via the web services directly, the user is temporarily banned from further login attempts. This is to prevent brute-forcing the password by endlessly trying different passwords. When this lockout is triggered on an account the user will receive 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 3 times consecutively. When the lockout is triggered and you wait 15 minutes, the lockout will be lifted. Lockouts can also be lifted manually by the administrator. The lockout policy is configurable 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 is used to keep track of all the hashes of wrong passwords that were 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 then you can 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 which are very unlikely to ever occur. We recommend you do not change this value.
As mentioned an exception to the lockout policy are authentication attempts made with a valid user-locked connection profile. 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. When Access Server is installed the initial administrative bootstrap user is called 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 UI even when for example an external authentication backend like LDAP or RADIUS is failing. This allows you to correct any problems with LDAP/RADIUS settings in the Admin 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.
When you have run into the problem that your users have run into the automatic authentication lockout policy and are currently blocked, and you wish to unblock them, please follow the steps below. It is important to note that at this time it is not possible to unlock a single specific user. Instead what we advise is that you set the automatic lockout reset period to 1 second, wait a moment so that all lockouts are reset, and then to set the lockout period back to whatever you had it set to before. The below lines will do this and assumes your lockout policy automatic reset period is supposed to be set back to the default 15 minutes (900 seconds) afterwards and restarts the Access Server to clear any locked sessions.
./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 authentication (HMAC firewall)
To explain the concept of TLS authentication in simpler terms, the idea here is to have a unique TLS key, a certificate, that is known and used by the server and its clients. A shared secret if you will, that will be used to digitally sign and verify packets in both directions. What this does is make it possible for the OpenVPN protocol to easily recognize if packets are truly VPN packets from a known VPN client, or if they are garbage packets from unknown sources. Every OpenVPN packet by itself contains encrypted information inside of it, but on top of that, the packet itself is signed digitally. The other party receiving the packet can then check if the signature matches with the known shared TLS key, and if it does, can then handle it further. If it doesn’t match, the packet is not from a known client and can be discarded. Aside from helping to filter away some attempts at denial of service attacks it also improves security by making other attacks impossible. It is simply an extra layer of security which is enabled by default on the OpenVPN Access Server.
There are unfortunately products on the market that do implement OpenVPN for connectivity to an OpenVPN server, but they come with a GUI that unfortunately does not give you the option to use TLS authentication. Some only have some menu options to provide a certificate, a key, and some encryption options for the OpenVPN tunnel, but no means to upload a configuration file or a TLS authentication key with the necessary instructions that the OpenVPN binary requires to implement TLS. This leads to the odd situation that the OpenVPN binary in the product can support TLS authentication, but there is no way to configure it to use it. In these situations if connectivity is required it is possible to disable TLS authentication. Unfortunately this is an option that cannot be set per user account. This is a server-wide global setting. It can be disabled or enabled from the Admin UI under “Advanced VPN” or in the command line with the commands below.
Enable TLS authentication (default):
./sacli --key "vpn.server.tls_auth" --value ="true" ConfigPut ./sacli start
Disable TLS authentication:
./sacli --key "vpn.server.tls_auth" --value="false" ConfigPut ./sacli start
It is important to note that when switching a server from one mode to another, to enable or disable TLS authentication, requires that all the clients currently installed are reconfigured for the new setting. OpenVPN Connect Client installations with a server-locked profile will automatically retrieve an updated connection profile when they next log on, but any clients that have a stored copy of a user-locked or auto-login type profile will need to be reconfigured or provided with a new connection profile in order to be able to connect again to a server that previously had a different TLS authentication setting.
Google Authenticator multi-factor authentication
This documentation section was moved to: Google Authenticator multi-factor authentication
Selecting TLS level for the OpenVPN daemons
The default for OpenVPN daemons on the Access Server in the past has been to use TLS 1.0. Later support was added to use TLS 1.1 and TLS 1.2 on the OpenVPN protocol. Older clients however may not know how to deal with this. For example an OpenVPN client from December 2014 will not be able to connect to an OpenVPN server that requires TLS 1.1 or TLS 1.2. Also, if you have your server set to TLS 1.0 on the OpenVPN daemons now and you have OpenVPN connection profiles and client software installed on a large number of clients, it is recommend to stay with TLS 1.0 and not to upgrade it to TLS 1.1 or TLS 1.2. Likewise the reverse is true if for some reason you downgrade from TLS 1.1 or 1.2 down to 1.0. The reason for this is that connection profiles can be either configured for the old method where TLS 1.0 is assumed, or can be configured 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 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 version 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 UI in the “SSL/TLS Settings” page. 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
Disable use of client certificates
Using unique client certificates and private keys is a major underpinning of the security of the OpenVPN protocol. Each user account is given a unique public key and private key and these uniquely identify the client to the server and have an important role in encryption and decryption of traffic. It is enabled by default and managed automatically by the OpenVPN Access Server. We recommend that you leave this option enabled and that you do not disable it. However, in rare cases, for example within networks that are secure already, it can be desirable to get rid of any overhead and use the Access Server program purely for the VPN tunneling functions without bothering with unique certificates for the users. If this is what you want to do then it is indeed possible to disable the use of client certificates. In such a case simple user name and password authentication is used instead. But please do be aware of the security implications as this lowers the security of the OpenVPN protocol significantly.
With client certificates disabled, the Access Server will no longer use the certificates database file. The Access Server still does need access to specific certificates and keys in there to be able to handle encryption and decryption, and for basic functionality. Therefore it is necessary to copy the required files out of the certificates database file and into the configuration database. This can be done with the following 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 popd
Next edit the as.conf file and add the following options:
In this file go all the way to the bottom and then add this line:
And then restart the OpenVPN Access Server service:
service openvpnas restart
Now the Access Server will function without client certificates. Any connection profiles generated by the Access Server now will not include the public key or private key for a client. Connections are now only possible by using user name and password authentication.