Tutorial: Update Your Access Server Version
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.
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.
Distribution | Version |
|---|---|
Ubuntu* | 26.04 LTS (x86_64 and ARM64) 24.04 LTS (x86_64 and ARM64) 22.04 LTS (x86_64 and ARM64) |
Debian | 13 12 |
Red Hat Enterprise Linux | 10 9 8 |
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 VPN Server.
Click the Security / Encryption tab.
Set the Minimum TLS level required to TLS 1.0.
Click Save and Restart.
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.
Sign in to the Access Server Portal.
Select Install Access Server.
Copy the bash install command.
Connect to your Access Server console however you prefer: bash, SSH, PuTTY, etc.
Gain root privileges. For example:
sudo suPaste 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.
Wait for the script to complete.
After the upgrade, reboot the server to apply the new version:
rebootIf all went well, your Access Server and your Linux system are now up to date.
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-asRed 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 upgradeRed Hat Enterprise Linux
sudo yum check-update && sudo yum update
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-asRepin 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, such as which interface to listen on and how to connect to the central database, are configured locally on each cluster node. This section walks you through upgrading an Access Server cluster using a rolling upgrade to minimize downtime.
Before you begin
Back up your data, both the central and local databases:
Use the
mysqldumptool to create a backup of the data in the cluster's central database. This ensures you have a copy of critical data in case of an issue during the upgrade.After backing up the central database, back up the local configuration stored in the
config_local.dbfile on each node. Refer to How to Back Up Access Server Configuration.
Ensure version consistency. All nodes need to run on the same version. As you upgrade, all nodes need to eventually match the same new version.
Steps for a rolling upgrade
A rolling upgrade updates nodes one at a time, so the cluster is never fully offline. Clients connected to the node being upgraded may briefly disconnect, but should automatically reconnect to another node if your cluster uses round-robin DNS (RRDNS) and a shared hostname. Without this setup, reconnect attempts may fail or take longer.
This example walks through upgrading a two-node cluster.
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.
Upgrade the first node 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.
Step 1: Upgrade Node1
Connect to the Node1 console and get root privileges.
Upgrade Access Server using your preferred method. To upgrade using our installation script, refer to Step 1: Get the installation script above. To upgrade using the package manager:
Ubuntu/Debian:
apt update && apt -y install openvpn-asRed Hat Enterprise Linux:
yum -y install openvpn-as
Verify that Node1 is functioning properly before continuing.
Step 2: Upgrade Node2
Connect to the Node2 console and get root privileges.
Upgrade Access Server using your preferred method, as in step 2.
Test connectivity
Verify that the cluster functions as expected and clients can connect and use services without issues.
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.
Use the following command to determine the active node for making a backup:
grep "Switching to state:" /var/log/openvpnas.log |tail -n1If 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 that is acting as BACKUP. In our case, this is the secondary node.
Stop the primary node's Access Server service:
systemctl stop openvpnasUpgrade the software on the primary node.
To upgrade using our installation script, refer to Step 1: Get the installation script above.
To upgrade using the package installer, refer to Option: Upgrade using package manager (apt/yum) above.
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.
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.
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:
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.
Yes, upgrading Access Server requires restarting the service, but the downtime is typically brief, lasting only a few minutes. After the upgrade, VPN clients should automatically reconnect.
For minimal disruption, we recommend performing upgrades during off-peak hours, such as nights or weekends.
Alternatively, you can set up a new server alongside the old one, migrate the configuration, and test it before making the switch. This approach minimizes downtime to just a few minutes.
If you're using an unsupported operating system, we recommend setting up a new server with a supported OS and migrating your Access Server configuration to it. When we drop support for an OS, it's typically because the OS maintainers have also ended support, leaving it vulnerable to security issues that will not be resolved.
Migrating your configuration to a new server ensures that your VPN client settings remain intact. You can swap out the old server for the new one, allowing you to continue business as usual without disruption.
For detailed steps on migrating your Access Server configuration, refer to our migration guide.
No, fixed license keys are retained when upgrading on the same server.
If your upgrade involves setting up a new server, and you're using a fixed license key, you will need to contact us to have your key reissued. This process is free and can be done via our support ticket system.
With a subscription plan, there is no need for reissuance. Subscriptions can be activated on as many servers as needed, providing more flexibility for your installations.
No, you will not lose any important information. The upgrade retains all configuration settings, ensuring that VPN clients can reconnect and maintain their settings without disruption.
It is unlikely that you will lose important features. You can review the Access Server release notes for any deprecated features. While it's uncommon for us to remove features, we recommend setting up a new server alongside the old one for testing before upgrading or replacing the old server to ensure the upgrade doesn't impact any critical functionalities.
Although your current version may be working fine, it's crucial to keep Access Server up to date to maintain optimal security and performance. Security vulnerabilities can emerge over time, and updates often include patches that protect against threats. Staying current ensures that you avoid risks and maintain a secure, reliable VPN solution.
If you're unsure how to upgrade or manage Access Server, we recommend engaging an IT networking specialist or a new employee with the necessary skills and expertise. Alternatively, you can switch to our CloudConnexa solution, which provides secure connectivity without the need to maintain a dedicated server.
Regardless of your solution, it's essential to keep your network's access point up to date to maintain security. While Access Server is highly secure, neglecting updates over time introduces potential risks.
We provide this comprehensive upgrade guide that walks you through the entire process. If your current IT admin is not familiar with performing these tasks, we recommend training on Linux system maintenance, or alternatively, you can explore our CloudConnexa solution. CloudConnexa allows you to securely connect systems without the need to manage your own VPN server.
It is highly unlikely, but in some rare cases, issues may arise. Since the security landscape evolves, if your last upgrade was a long time ago, some components may have become incompatible.
We maintain a software repository with versions going back to 2.7.5, so if needed, you can easily roll back to a previous version.
For added assurance, we recommend setting up a new server alongside the existing one, migrating your data, and conducting tests while the old server remains active. Once you're confident that everything is working correctly, you can proceed with the upgrade or switch the old server with the new one.
We don’t recommend downgrading Access Server to an earlier version unless it's absolutely necessary. Using the latest version ensures that you have the most up-to-date bug fixes and security patches.
If you do need to revert to an older version, please refer to our Access Server downgrade tutorial for detailed instructions.