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 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, 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, and the root account is blocked from direct SSH access. 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:


On our ESXi or HyperV appliances, or in your own custom Linux installation, it may also be useful to create your own account in Linux that you can use for SSH access, since the root account will usually not be able to do so, unless you adjust the SSH server settings to allow it. The better solution is to create your own user account and give it sudo rights. You need the sudo program installed so the commands below will take you through the steps to install sudo, create a new user account with your chosen name, and give it the right to run commands as root user. The commands below are assumed to be run as root user on a Debian/Ubuntu system.

apt-get -y install sudo
adduser <USERNAME>
usermod -aG sudo <USERNAME>

Where <USERNAME> is a name of your own choice, without spaces or special characters. You can use this new user account to log in through SSH and use programs such as SCP or WinSCP to transfer files, although that is limited to files you actually have access to. If you want to get root privileges from this new account run this command and provide your own password (not the root password):

sudo su

You should aim to have a situation where the root user can only be used directly on the console, and not over the network, and obviously with a very secure password. Additionally you should have your own user account with a very secure password that you can use to log on over the network with, and has the ability to use sudo to run commands as root user. To make things even better you should set up an SSH key-pair for user login under your own user account, instead of simple username+password authentication. But that strays pretty far into Linux system management and we feel it is better if you refer to your operating system's documentation on how to do that. On Amazon AWS at least, they insist on having things set up this way, and so by default it is indeed set up as described, with an SSH key.

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 immediately a security issue because an account without a password set on it normally cannot be used to log on at all, especially on the images we provide. 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 locking the account:

passwd -l openvpn

Note: we advise that you test logging in with the account on the admin UI of the Access Server, to confirm that logging in is now not possible.

If you want to start using this account again in the future, unlock it and set a new password:

passwd -u openvpn
passwd 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

If you ever lose access to your server, either because of the steps above or because you have lost the password and have problems recovering access, then give our troubleshooting authentication problems page a try.

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.

Some of our customers do not want the web services visible on the Internet, but only want the OpenVPN daemons reachable for VPN tunnel termination. We advise against doing this because of the fact that managing the Access Server without a web service makes things a lot more difficult. You would then have to rely on using the command line interface tools to manage the Access Server settings, users, and certificates, and also the distribution of the required connection profiles to the users. Having the web services available makes this a lot easier. Furthermore, the OpenVPN Connect Client is tied into the web services of the Access Server using a secure XML-RPC connection over SSL. In short, this allows any user with valid credentials to log in with the OpenVPN Connect Client, instead of having to install separate user-locked connection profiles for each and every user that needs to log in from a client computer. Making the web services unreachable from the Internet breaks this functionality and forces you to use user-locked or auto-login profiles only. In short, you would end up breaking some of the designed functionality, and force you to do some extra work.

However, if you really want to, you can choose to for example only allow ports TCP 443 and UDP 1194 default ports for the OpenVPN daemons from the Internet through your firewalls to your Access Server installation, and then disable the service forwarding options for the client web UI and the admin web UI in the Server Network Settings page. Those two actions together will make the web interface unreachable from the Internet but still allow incoming user-locked and auto-login connection profile based OpenVPN tunnels to make a connection. But server-locked profiles will not be able to connect anymore. To learn more about what the service forwarding is, and what effect it has, check the description in the command line page describing how to configure the web service forwarding settings. To learn about the various types of connection profiles see the connection profiles page.