Select Page

Recommendations to improve security after installation

Secure the root user account

When you deploy one of our appliances for ESXi or HyperV it comes with a rather simplistic password for the root account. We do take the precaution with our appliances to ensure that accessing the root account over the network is by default not possible. But if someone has access to the console then the default password is not very good. To replace the account password for the root user simply first log on to the operating system and obtain root privileges. Via the console you can do this directly as root user. On our AWS appliances you are relatively safe though, and you may skip this step. That is because on Amazon the appliances you launch must use a secure private/public key pair on an unprivileged account (openvpnas) to get in and afterwards you can sudo up to gain root privileges. And on AWS there is no console so it can't be accessed in this way. But on the ESXi and HyperV appliances you can log on to the console directly using the root account, and as such you should protect it better than with the default password. Use the command below to set a new password once you are root:

Set a new password on the account you're logged on as:


Secure the openvpn administrative user account

By default the OpenVPN Access Server comes configured with a user account called openvpn without a password set on it. That by itself is not a security issue because an account without a password set on it simply cannot be used to log on at all. You are expected to make your own password and set it on the openvpn user account to start logging in to the Admin UI and setting things up on the Access Server. So that is not the problem, but having an account with a predictable user name is of course not a good thing to have, especially when it's facing the Internet. And the openvpn user account is also a bootstrap account meaning it has special access privileges. For example it can bypass Google Authenticator and the authentication failure lockout policy. Therefore we recommend that one of the first things you do after setting up the OpenVPN Access Server is to create a new user for yourself and give it admin privileges. That will then be your administrative user account from that moment on. You can do this from the Admin UI under User Permissions by adding a user there. If you use local authentication you can set a password for the new account there as well. If you are using an external authentication system like PAM, RADIUS, or LDAP, remember to also add the account there as well so you can actually use it to log on to the Admin UI. Obviously test this first before proceeding with the next steps.

Next we recommend disabling the openvpn account by removing its password:

passwd -d openvpn

If you want to take it a few steps further it is possible to completely erase all traces of this initial administrative account. To do that follow the steps outlined below. But we recommend that you only disable the account by removing its password, instead of removing it entirely from your Access Server. If you are using for example an LDAP server to authenticate users, and you change something on your LDAP server, like giving it a new IP address or changing the bind user's password, then nobody can log on at the Access Server's admin UI anymore. Including your administrative user that you created yourself. But the openvpn user can because it's a special bootstrap user that instead authenticates to the operating system. In such a case you can give the openvpn user a password again with the command passwd openvpn and you can log on to the Admin UI and make corrections to the LDAP authentication settings and get things running again. But if you want to continue with the steps to completely remove the openvpn account then do the following:

Delete the user from the operating system:

deluser openvpn

Open as.conf in a text editor:

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

Locate this line:


And comment it out like so:


Press ctrl+x, then y, and then enter, to save and exit the file. Then restart the Access Server service:

service openvpnas restart

Finally remove the user from the Access Server database:

./sacli --user "openvpn" UserPropDelAll

Installing an SSL certificate on the web interface

By default the OpenVPN Access Server comes with a self-signed certificate to at least get things working. Such a self-signed certificate cannot be automatically verified by your web browser or an OpenVPN client program to check if the server it is contacting is really your server, and not some other server pretending to be. SSL certificates allow for the web browser to automatically verify if you are connecting to the real server, and to automatically trust the server so that the web interface will not show a warning message about not being able to validate the authenticity of the server, but instead show a nice green padlock icon in the address bar in the browser.

This requires that your OpenVPN Access Server is set up with an FQDN DNS name that points to the public IP address that the Access Server can be reached at from the Internet, and that this FQDN DNS name is configured correctly in the Admin UI under Server Network Settings in the Host name or IP address field. We recommend that you set up this FQDN DNS name in all cases, not only because it is required for an SSL certificate to function properly, but also because if ever in the future you change the IP address of your Access Server, for example if you move it to another Internet connection, then you need only update the DNS record and all clients will be able to find the server again. If however you configure it to IP basis only, then you will have to reinstall all your clients if you move your server to another public IP address.

See the page on how to install an SSL certificate on the Access Server web server for more information on how to do this.

Hardening the web server cipher suite string

The web server built into the Access Server by default uses HTTPS SSL encryption. This secures the connection between the web browser and the web server, so that any credentials you enter on the web interface cannot be intercepted by a "man-in-the-middle" attack or be seen in plain text on the network connection. Instead that information is all nicely encrypted. The cipher used to encrypt this information is one that is agreed upon by the web server and the web browser. The server offers a number of ciphers that it allows to be used, and the web browser then picks (usually) the best one of those that it can support and uses that to encrypt information. The list of ciphers that the web server allows is called the cipher suite string. By default the cipher suite string that the Access Server comes shipped with is reasonably secure, but not overly so. There are some older ciphers allowed to offer compatibility for older web browsers and operating systems, like Windows XP for example. In most cases though you will probably want to run the web server through its paces using an online SSL security checker like Qualys SSL Labs SSL Server Test to see what grade your current settings get and then adjust the cipher suite string to eliminate weak ciphers and thereby improve the grade and thus the security of your web server. This can have as consequence that older browsers and operating systems can't connect to the web interface anymore, though.

The cipher suite string must be set through the command line, and is described in the custom cipher suite string for the web server section of the command line tools documentation.