Tutorial: Update Your Access Server Version
How to keep Access Server updated to the latest version. We recommend running the latest version for best security practices.
Overview
This tutorial guides you through updating Access Server to the latest version. While the easiest and most effective way to update is by using the installation script provided on the Access Server portal, you can also upgrade using other methods, such as package managers.
If you prefer not to use the installation script, you can upgrade Access Server manually by using apt or yum. However, keep in mind that you will need to ensure that any held packages are handled properly during the process.
For a related resource, we have a video that shows you how to update Access Server to the latest version.
Use these backup commands on the command line to completely back up your settings without stopping your server. 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.
The current version of Access Server is very compatible with past versions. You can update versions as described here back to 1.7.1. If needed, Access Server leaves a copy of old data in this directory whenever you upgrade: /usr/local/openvpn_as/etc/backup.
Some cases may exist where older client software can't connect to a modern Access Server. To fix this, update to a more recent client software version. If that isn't possible, you may lower Access Server's security requirements. 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:
Sign in to the Admin Web UI.
Click Configuration > TLS Settings.
Set the 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. Amazon’s licensing and billing systems take care of them internally. Simply upgrade the Access Server package itself.
Tip
We highly recommend using the installation script from the Access Server portal for a smooth and automated update process. The script automatically handles any dependencies and potential issues like held packages.
Sign in to the Access Server Portal.
Click Install Access Server.
Copy the bash install command.
Connect to your Access Server console how you prefer: bash, SSH, PuTTY, etc.
Gain root privileges. For example:
sudo su
Paste the bash command and run it.
"Welcome to the OpenVPN Access Server Installation Script!" displays and starts the installation.
The script detects your Linux distribution and Access Server version.
If the current installation is pinned, the script temporarily ignores that and upgrades anyway. After this, the openvpn-as package is pinned again.
After the openvpn-as package upgrades, the script checks for OpenVPN DCO and installs or upgrades as necessary.
Tip
Refer to Tutorial: Turn on OpenVPN DCO for more about performance improvements with OpenVPN DCO.
Wait for the script to complete.
After the upgrade, reboot the server to apply the new version:
reboot
If all went well, your Access Server and your Linux system are now up to date.
Tip
We provide detailed installation guides for the different platforms available. Refer to these installation guides for steps.
If you prefer using the Linux package manager (apt for Debian/Ubuntu or yum for RHEL), you can manually upgrade the package with these steps:
Check for package locking: Ensure the package isn't held in the package manager. If the package is held, using the following commands to unhold it:
Ubuntu and Debian
apt-mark unhold openvpn-as
Red Hat Enterpise Linux
yum versionlock openvpn-as
Update the system: Run the following commands to update your system:
Ubuntu and Debian
sudo apt update && sudo apt upgrade
Red Hat Enterprise Linux
sudo yum check-update && sudo yum update
Tip
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 newer versions.
These commands will not upgrade your Linux OS, such as from Ubuntu 18.04 LTS to Ubuntu 20.04 LTS. Such a large upgrade is called a distribution upgrade. Refer to Tutorial: How to Migrate an Access Server Installation.
If you use a fixed license key, a distribution upgrade could break it. Contact us for help.
After completing the upgrade, reboot the server:
reboot
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), ESXi, and HyperV appliances, we have pinned the openvpn-as package so that the Access Server program doesn't update when you install operating system updates.
We have done this 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 surprise a system administrator with a new Access Server version just by performing 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
If you use our official installation script to perform an update of the Access Server, the script will detect if the openvpn-as package is on hold or not:
If the package is marked hold, the script will unpin it and proceed with the update. Once the update is finished, it will put the openvpn-as package on hold again.
If the package is marked unhold, the script will proceed with the update. Once the update is finished, it will put the openvpn-as package on hold.
An Access Server cluster relies on a central database system to store user, certificate, and configuration information. Some settings, like which interface to listen on and how to connect to the central database, remain locally on each cluster node. This section walks you through upgrading an Access Server cluster while minimizing downtime and disruptions.
Before you begin
Back up your data, both the central and local databases:
Use the
mysqldumptool to create a backup of the data stored in the cluster's central database. This ensures you have a copy of critical data if something goes wrong during the upgrade.After backing up the central database, refer to the Tutorial: How to Back Up Access Server Configuration for details on backing up the local configuration stored in the config_local.db file on each node.
Ensure version consistency. All nodes must run on the same version. It's important that as you upgrade, all nodes eventually match the same new version.
Steps for a rolling upgrade
These steps walk you through upgrading nodes one at a time.
Begin upgrading your Access Server nodes one by one. This is called a rolling upgrade, and it ensures the entire cluster is never fully down.
Take the first node down for maintenance and upgrade it to the new version.
During this process, clients connected to the node being upgraded may experience temporary disconnects but should automatically reconnect to the next available node.
Repeat this process for each node in your cluster.
Verify that all nodes are correctly upgraded and functioning as expected.
Test connectivity
Verify that the cluster functions as expected and clients can connect and use services without issues.
Let's assume we have two nodes in our cluster:
Stop services on both nodes with the below command:
systemctl stop openvpnas
Upgrade Node1. Use the installation script or the official repository.
The openvpnas services will be started automatically.
Upgrade Node2. Use the installation script or the official repository.
No need to start the services here. After the upgrade, the services will be started automatically.
Following this order will allow migrating DB (changing its structure) properly with an upgrade.
Warning
Before you begin, ensure that you backup the main node in the master state. Use these backup commands on the command line.
Access Server has 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 using a method called UCARP, which uses VRRP heartbeat network packets. For more details, refer to Tutorial: How To Set Up Failover Mode.
Important
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 can easily restore connectivity if anything goes wrong with the upgrade.
Use the following command to determine the active node for making a backup:
grep "Switching to state:" /var/log/openvpnas.log |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.Note
In our example, the primary node is MASTER and the secondary node is BACKUP.
Shut down the (virtual) machine that is acting as BACKUP. In our case, this is the secondary node.
Stop the primary node's Access Server service:
systemctl stop openvpnas
Upgrade the software on the primary node.
To upgrade using our installation script, follow the steps under .
To upgrade using the repository, follow the steps under Updating Access Server if you're already using the repository.
To upgrade using the package installer, follow the steps under .
Validate everything works on your updated primary node. Access Server should have started automatically after the upgrade, but if it didn't, run
systemctl start openvpnas.After testing the primary node, bring the failover node online and perform the same upgrade steps.
Note
The failover node won't actually do anything while the primary node is online, so you can now safely upgrade it to the latest version.
After completing the failover node upgrade, wait ten minutes for a configuration update from your primary node before testing the failover functionality.
At a reasonable time, we recommend testing to see if the failover system is working correctly. To do this, take the primary node down and check to see that your connections and Admin Web UI work as expected.
Tip
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 outlined above.
Important
We recommend contacting support if you need to roll back due to difficulties. We can help out.
When Access Server detects an older version of its databases, it may automatically update them during startup. In cluster setups, this also affects the central databases. These updates occasionally cause incompatibilities with older Access Server versions if you need to roll back.
Steps to roll back and restore databases:
Important
Use the steps below for SQLite 3 as the database backend.
If you're using MySQL, only the last step — using a backup tool like mysqldump — applies to you.
Always create a backup of the local and central databases before upgrading.
If you roll back to an older version of Access Server, restore the databases from the backup created before the upgrade.
Use your backup tools (such as
mysqldump) to restore the central and local databases to their pre-upgrade state.
Downgrade Access Server
We recommend running the latest version, but if you need to downgrade to an older version, refer to this tutorial:
If your appliance or cloud image is outdated or your system runs on an unsupported operating system, we recommend installing a fresh Access Server version. Here's how you can perform the migration or reinstallation:
Follow the Tutorial: How to Migrate an Access Server Installation to back up your system and configuration files, including all settings and your subscription license.
Install a new Linux OS and Access Server on a separate system while keeping your old system running.
Once the new system is set up, restore your configuration, data, and subscription license from the backup to the new Access Server.
Before switching to the new server, test it out.
Finally, switch to the new system and decommission the old server.
If you have a perpetual license key purchased prior to 2013, you must purchase a new subscription 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 support term expired. A perpetual license key will not work on an Access Server higher than version 1.8.4.