Keeping Access Server updated

Updating Access Server

This page provides you with detailed information for updating and upgrading Access Server.

Before you begin

To make a complete backup of your settings without stopping your server, use these backup commands on the command line. The information stored in Access Server (e.g.: server and client certificates) is unique and cannot be replaced. We recommend setting up automated backup tasks if you haven’t already done so.

Compatibility of the current version of Access Server to past versions is very good. You can update as described here for versions all the way back to 1.7.1. If needed, Access Server does leave a copy of old data in this directory, whenever you upgrade: /usr/local/openvpn_as/etc/backup

There may be some cases where older client software cannot connect to a modern Access server. To fix this, simply update to a more recent version of the client software. If that is not possible, you may lower the security requirements of the Access server. It may be that an upgraded Access Server has the minimum required TLS security level set to a higher version, causing an issue with older clients. You can change this for your server. Open the Admin Web UI, go to TLS Settings and set OpenVPN daemons to TLS 1.0.

If you have an Amazon AWS tiered instance, pre-licensed with “xx connected devices”, you don’t need to worry about licenses. It is taken care of internally by Amazon’s systems that handle licensing and billing. Simply upgrade the Access Server package itself.

Below you’ll find your different installation options. We recommend using the official OpenVPN software repository for upgrading.

Installations and upgrades using the official OpenVPN software repository

The official OpenVPN software repository provides you with an enhanced user experience for installing and upgrading Access Server. The following will give you instructions for adding the repository with a new installation, adding it to an existing server in order to upgrade, using Linux to automatically update Access Server, updating Access Server without updating all other Linux packages, and preventing Access Server from automatically updating. Refer to the section that suits your needs.

Adding the repository with a new Access Server installation

Beginning with Access Server 2.7.5, we distribute the package and client bundle primarily through our official software repository. From our central server, you can obtain the latest Access Server software. Your Linux operating system will download and install the latest version and upgrade your existing installation whenever you get updates and upgrades.

You can find simple copy and paste instructions on how to do this on the software packages download page on our website. This is our recommended method for installation and updates. The steps found there are all it takes to add the repository and get started with a new Access Server installation within minutes.

Adding the repository and upgrading existing Access Server

If you are using Access Server 2.7.4 or older, you need to do the following:

  • Determine your operating system.
  • Get the instructions for your OS from our website to install the repository.
  • Install the latest version of Access Server.

To determine your operating system:

                            cat /etc/issue
                            lsb_release -a
                            uname -a

This should output some useful information. If you encounter some failure, that is fine. You should still get what you need. Below is an example of output from an older Access Server on Amazon AWS:

                            OpenVPN Access Server Appliance 2.1.9 \n \l
                            No LSB modules are available.
                            Distributor ID: Ubuntu
                            Description: Ubuntu 16.04.2 LTS
                            Release: 16.04
                            Codename: xenial
                            Linux openvpnas2 4.4.0-96-generic #119-Ubuntu SMP Tue Sep 21 14:59:54 UTC
                            2017 x86_64 x86_64 x86_64 GNU/Linux

Now we know that we’re running Ubuntu 16.04.2 LTS on an x86_64 platform. With the information on your system, determine the operating system name, version number, and whether it’s x86 (32 bits) or x86_64 (64 bits).

Based on those three things, look up the repository installation instructions in the Access Server portal on our website by signing in or creating an account, selecting your operating system and version, and using the instructions listed.

The instructions give you the commands for you to copy and paste to your server’s command line. It will set up the software repository for you, download and install the latest Access Server version, and upgrade your existing installation.

After adding the repository, when you run apt update and apt upgrade in the future, it will update Access Server at the same time as your system.

For the final step, we recommend rebooting your server:


This completes the upgrade process.

Note: If your operating system is older than those we have listed, you may need to consider updating your whole system. For example, we no longer offer downloads for CentOS 5 as it could not handle functions we support today for IPv6. Installing Access Server on an older platform than it was designed for will result in failure.

Updating Access Server with Linux OS updates

We recommend keeping your Linux operating system updated. With the built-in package manager program, it’s easy to retrieve updates and install them. We recommend doing this regularly to keep up with security fixes. To do so, run these commands when logged on to the Access Server as a root user:

Ubuntu and Debian

                            apt-get update
                            apt-get upgrade

RedHat and CentOS

                            yum check-update
                            yum update

These commands update packages within the version of your operating system. If your Access Server uses our software repository, it will also upgrade the Access Server and bundled OpenVPN Connect apps if there are any newer versions.

These commands will not upgrade your Linux OS, such as from Debian 8 to Debian 9. Such a large upgrade is called a distribution upgrade, and chances are doing one could break your license key. If that happens, you will need to contact us to have it reissued. See this page for details on migrating your Access Server installation.

Updating Access Server if you are already using the repository

If you have Access Server 2.7.5 or higher, it’s likely you are using our repository. When we release a new version of Access Server on our website and to the repository, you should be able to install it easily.

Any updates and upgrades will run whenever you update your operating system with these commands:

                            apt-get update
                            apt-get upgrade

RedHat and CentOS

                            yum check-update
                            yum update

After this completes, reboot the server:


If all went well, your Access Server is now up to date along with your Linux system.

If you are running an instance of Access Server on a cloud image (AWS, Google, DigitalOcean, or Azure), we have pinned the openvpn-as package, which prevents your Ubuntu server from including it in updates with the commands above. For information about this, refer to the section below.

Preventing Access Server updates

Once you have added the Access Server software repository to your system, any time you run the commands to update your operating system, it will also pull in the new Access Server release and bundled connect clients, if there are any. For cloud images (Google, Azure, AWS, and DigitalOcean), and ESXi and HyperV appliances, we have pinned the openvpn-as package so that the Access Server program does not update when you install operating system updates.

The reason we have done this is to avoid a sudden change in process. Past versions of Access Server stayed at their currently installed version number when people ran operating system updates. We did not want to end up surprising a system administrator with a new Access Server version just by doing security updates.

You can change that by unpinning it, and repin if you’d like with these commands.

Unpin the openvpn-as package:

                            apt-mark unhold openvpn-as

Repin the openvpn-as package:

                            apt-mark hold openvpn-as

Installations and upgrades using package installer files

Linux programs are installed as packages, either from a software repository or a separately downloaded and installed file. We recommend using our official repository. We also continue to support OpenVPN Access Server as software package files that can be downloaded and installed separately.

Beginning with Access Server 2.7.5, we have split the program into two pieces:

  • Access Server bundled Connect software for Windows and macOS
  • The Access Server program itself

You must install both packages:

  • Sign in to the Access Server portal.
  • Click Get Access Server.
  • Select your Linux operating system and version.
  • Follow the instructions for Option Two: Manually download packages.

Cluster upgrade procedure

An Access Server cluster relies on a central database system to store information about users, certificates, and other cluster configuration. Some configuration stays locally on the individual cluster nodes such as which interface to listen on and how to connect to the central database system.

Before you begin: We recommend making a backup first. As some data is stored in a central database for a cluster setup, use the mysqldump tool for your backup. Once you've backed up the data stored in your central database, refer to How to back up Access Server configuration for specifics on how to backup the local configuration stored in the config_local.db file.

All nodes of a cluster must run on the same version of Access Server. Therefore, when upgrading a cluster of Access Server nodes to a new version, ensure that you upgrade all nodes. You don’t have to upgrade all at once, but it can be done in a rolling upgrade, where each node in turn gets upgraded until all nodes are on the same, new version. A rolling upgrade ensures that the cluster is never fully down. Clients connected to a node that goes down for maintenance should automatically connect to the next available node. This may cause some temporary disconnects for your users, but the clients should automatically reconnect.

Rolling back to a previous version

Note: If you need to roll back due to difficulties, we recommend contacting support. We can help out.

When Access Server starts up and detects an older version of the databases in use, it may need to perform certain updates to the databases and possibly change some values. These changes are expected when updating your Access Server. In the case of a cluster, this means the central databases get updated as well. This could, in rare cases, lead to incompatibilities with older versions of Access Server.

Therefore, if you find, for whatever reason, the need to roll back to an older version of Access Server, you should also restore the databases to an older version. You can do this by restoring a backup taken of the databases before you performed the Access Server upgrade.

Failover upgrade procedure

Note: Before you begin, ensure that you do a backup of the main node, which is in the master state. Use these backup commands on the command line.

Access Server comes with a built-in failover mode you can deploy on your local LAN network. It allows one primary node to handle all tasks, with a secondary standby node. The secondary node comes online automatically, taking over all tasks, if your primary node fails. This is done with a method called UCARP using VRRP heartbeat network packets. For more details, refer to Setting up high-availability failover mode on our site.

It’s important to keep both Access Server nodes updated with the same versions. We also recommend following a specific upgrade procedure to avoid triggering the failover unnecessarily. This should also ensure that you have a way to easily restore connectivity in the rare event that anything goes wrong with the upgrade.

Keeping your primary node online, make a backup first. Use the following command to ensure this node is active at the moment by running:

cat /var/log/openvpnas.log|grep "Switching to state:" |tail -n1

If you see [WARNING] Switching to state: MASTER — you are on the active node. Make your backup here.

If you see [WARNING] Switching to state: BACKUP — you are on the standby node. Go to the other node and re-check if it's active.

Shut down the (virtual) machine where your failover installation of Access Server is installed. Then stop the primary node's Access Server service with service openvpnas stop. Then do the software upgrade step. To upgrade using the repository, please click on the Software Repository section on this page. To upgrade using the package installer, please click on the Package Files section on this page.

Once you have completed the upgrade of your primary node, validate that everything is working as expected. Access Server should have started automatically after the upgrade, but if not you can start the service yourself with service openvpnas start. Once the primary node is tested, you can bring the failover node online and perform the same upgrade steps there as well. The failover node won't actually do anything while the primary node is online. So you can now safely upgrade the failover node to the latest version. Afterwards give it ten minutes to get a configuration update from your primary node before you start testing failover functionality.

At an opportune time, we recommend testing to see if the failover system is working properly. To do this, take the primary node down and check to see that your connections and Admin Web UI work as expected.

If something goes wrong with the upgrade process of the primary node, we recommend you gather log file information and contact us with our support ticket system. Then, take the primary node offline. Once it is offline, bring the failover node online. It should start up as the old system it was and take over and handle connections. This keeps your clients up and running while you look into the problem on the primary node. Once issues are diagnosed and resolved, you can bring the primary node back up, take the failover node offline, and perform the upgrade steps as outlined above.

Replace entire appliance or cloud image

If you are in the situation that your appliance of cloud image is really outdated, and/or your installation has an old and no longer supported operating system, you should consider installing a new one. Please refer to our migration or reinstallation guide for this. It describes how to backup your system and restore the configuration to another Access Server. We recommend this step if your Linux OS is too old. Upgrade your entire OS and start over with a new Access Server installation. When you restore your data and license keys, you’ll be up and running again.

Usually, this kind of migration or reinstallation can be done in a way where you can keep the current system up and running while you set up a new system in parallel. Then, you can test it before you do the actual switch.

Service Notice: Perpetual License Keys

If you have a perpetual license key that was purchased prior to 2013, you must purchase a new subscription in order to upgrade your Access Server instance. All Access Server license keys purchased since 2013 are standard license keys, not perpetual.

OpenVPN strictly adheres to the original terms under which we sold perpetual licenses. One of those terms was that neither support nor upgrades were allowed when the license key’s term for support expired. A perpetual license key will not work on an Access Server higher than version 1.8.4.

For more information, refer to My perpetual license key does not work anymore.