Introduction
We don’t recommend downgrading Access Server to an earlier version unless you have a pressing need to do so. We encourage you to use the latest version containing the latest bug and vulnerability fixes. Refer to keeping Access Server updated on how to upgrade to the latest version. If you choose to downgrade, it is at your own risk, and our ability to support you in this may be limited.
If you have a case where it’s necessary to revert to an older version of Access Server, ensure that you restore a backup of the configuration that works for that version, or you may encounter unexpected issues with the newer configuration used on an older Access Server. Access Server can upgrade configurations, but it can’t downgrade them.
Downgrade steps overview
Here are the recommended steps to perform downgrade to an older Access Server version:
- Back up your current configuration and note your current Access Server version. This gives you a point to go back to if the rollback fails.
- Ensure the correct software repository for your operating system is installed. You can find the necessary information here: VPN Software Repository & Packages.
- Pin the openvpn-as package so that it doesn’t get automatically upgraded.
- Secure a backup of the configuration that is the same version or older than the Access Server version number you wish to downgrade to.
- Install the older version of Access Server that you need.
- Stop the Access Server service and restore the backup.
- Start the Access Server service and verify that all is well.
Configuration backups
It is ultimately your responsibility to maintain backups of your Access Server configuration. The configuration contains unique certificates you can’t reproduce if they’re lost. Suppose you’ve upgraded your Access Server and don’t have backups of the configuration before the upgrade. In that case, you might not be able to downgrade due to changes in the configuration database schemas.
When you perform an in-place upgrade, Access Server automatically makes backups of the SQLite3 database files containing the pre-upgrade configuration. It stores these backups in the /usr/local/openvpn_as/etc/backup/ directory with timestamps. However, if you use a MySQL database, Access Server doesn’t make a backup. You must make that type of backup in the MySQL database system.
If you don’t use MySQL or clustering, and your Access Server is a standalone or failover setup using the default SQLite3 databases, the automatic backups made during upgrades should be sufficient to perform a downgrade. But any changes you made after the backup was created will be lost when restoring the configuration backup.
Refer to our backup and restore guide on how to make backups of Access Server configurations and how to restore that backup.
Downgrading Access Server package
Since Access Server 2.7.5, we deliver the openvpn-as OpenVPN Access Server package via our software repository for the supported Linux operating systems. By default, the latest version available for your OS is selected when you install or upgrade from our software repository. Using the package manager, you can select an older Access Server release if available for your operating system.
If you need to downgrade to a version older than 2.7.5, we recommend against doing that for security reasons, and those older versions aren’t available on our software repository. To obtain an older version, you must contact our support team and request a specific version. Let us know the operating system name and version, the requested version of Access Server, and the architecture you need it for (x86 or amd64).
Note: Not all Access Server releases may be available for your operating system. Suppose you also upgraded your operating system when upgrading Access Server. In that case, you may, in some cases, not be able to downgrade to the desired version without also downgrading your operating system.
For Debian and Ubuntu
You can use the apt package manager to install a specific version from the software repository. We recommend that you pin the package afterward, so it doesn’t upgrade again to the latest version when you run apt upgrade for operating system upgrades. We assume that you have the correct software repository installed and that you are running all commands as root user.
List openvpn-as versions from the software repository:
apt update
apt list -a openvpn-as
An overview like below appears:
openvpn-as/focal 2.10.2-3383e1e5-Ubuntu20 amd64 [upgradable from: 2.10.2-3383e1e5-Ubuntu20] openvpn-as/now 2.10.2-3383e1e5-Ubuntu20 amd64 [installed,upgradable to: 2.10.2-3383e1e5-Ubuntu20] openvpn-as/focal 2.10.1-d5bffc76-Ubuntu20 amd64 openvpn-as/focal 2.10.0-ca1e86b5-Ubuntu20 amd64 openvpn-as/focal 2.9.6-1090f6b3-Ubuntu20 amd64 openvpn-as/focal 2.9.5-82d54e5b-Ubuntu20 amd64 openvpn-as/focal 2.9.4-8b3ce898-Ubuntu20 amd64 openvpn-as/focal 2.9.3-ed03d859-Ubuntu20 amd64 openvpn-as/focal 2.9.2-04614689-Ubuntu20 amd64 openvpn-as/focal 2.9.1-a832f4bf-Ubuntu20 amd64 openvpn-as/focal 2.9.0-5c5bd120-Ubuntu20 amd64 etcetera
Install specific version, for example 2.9.6:
apt install openvpn-as=2.9.6-1090f6b3-Ubuntu20 -y --allow-downgrades
Verify the installed version with one of two commands:
dpkg -l|grep openvpn-as
/usr/local/openvpn_as/scripts/sacli Version
(Both commands should return the same version and build number.)
Pin the package, so it isn’t automatically upgraded:
apt-mark hold openvpn-as
For CentOS, RHEL, and Amazon Linux 2:
You can use the yum package manager to install a specific version from the software repository. We recommend that you pin the package afterward, so it doesn't upgrade to the latest version when you run yum update for operating system upgrades. We assume that you have the correct software repository installed and that you’re running all commands as root user.
List openvpn-as versions from the software repository:
yum list --showduplicates openvpn-as
An overview like below appears:
Installed Packages openvpn-as.x86_64 2.10.2_3383e1e5-CentOS7 as-repo-centos7 Available Packages openvpn-as.x86_64 2.10.2_3383e1e5-CentOS7 as-repo-centos7 openvpn-as.x86_64 2.10.1_d5bffc76-CentOS7 as-repo-centos7 openvpn-as.x86_64 2.10.0_ca1e86b5-CentOS7 as-repo-centos7 openvpn-as.x86_64 2.9.6_1090f6b3-CentOS7 as-repo-centos7 openvpn-as.x86_64 2.9.5_82d54e5b-CentOS7 as-repo-centos7 openvpn-as.x86_64 2.9.4_8b3ce898-CentOS7 as-repo-centos7 openvpn-as.x86_64 2.9.3_ed03d859-CentOS7 as-repo-centos7 openvpn-as.x86_64 2.9.2_04614689-CentOS7 as-repo-centos7 openvpn-as.x86_64 2.9.1_a832f4bf-CentOS7 as-repo-centos7 openvpn-as.x86_64 2.9.0_5c5bd120-CentOS7 as-repo-centos7 etcetera
Install specific version, for example 2.9.6:
yum downgrade openvpn-as-2.9.6_1090f6b3-CentOS7 -y
Verify the installed version with one of two commands:
rpm -qa|grep openvpn-as
/usr/local/openvpn_as/scripts/sacli Version
(Both commands should return the same version and build number.)
Yum can pin a package if you have the yum-versionlock plugin installed:
yum versionlock openvpn-as
Restore configuration backup
As we add new Access Server features, we correspondingly update the configuration database schema. To work correctly, Access Server needs the configuration database to be the same or an older version. Access Server can upgrade a configuration database automatically, but it can’t downgrade it. Hence the need to restore a backup if you downgrade Access Server. If you try to use a configuration from a newer Access Server version, you will likely encounter problems.
Restore from manual backup
Refer to our backup and restore guide on how to backup Access Server configurations and restore backups.
Restore from automatic backup
When you perform an in-place upgrade of Access Server, it automatically makes backups of the SQLite3 database files containing the pre-upgrade configuration, which it stores in the /usr/local/openvpn_as/etc/backup/ directory with timestamps.
Access Server also makes automatic backups when performing a downgrade. Ensure you restore the backupset Access Server automatically created when you upgraded it. Be careful not to use the backupset automatically created when you downgraded. Usually, this means you should restore the second newest backup when performing a downgrade operation.
Example to restore backupset "2022-04-01T12:00:00":
service openvpnas stop cd /usr/local/openvpn_as/etc/backup/ cd "2022-04-01T12:00:00+0000" [ -e config.db ]&& /bin/cp config.db ../../db/config.db [ -e certs.db ]&&/bin/cp certs.db ../../db/certs.db [ -e userprop.db ]&&/bin/cp userprop.db ../../db/userprop.db [ -e log.db ]&&/bin/cp log.db ../../db/log.db [ -e config_local.db ]&&/bin/cp config_local.db ../../db/config_local.db [ -e cluster.db ]&&/bin/cp cluster.db ../../db/cluster.db [ -e clusterdb.db ]&&/bin/cp clusterdb.db ../../db/clusterdb.db [ -e notification.db ]&&/bin/cp notification.db ../../db/notification.db service openvpnas start
Verify normal operation
As your final step, verify Access Server works, and your clients connect successfully.
Check in the logs if the Access Server starts up correctly, and check that the web interface and the VPN connections are functioning again as before. Any changes made after the backup was created will be lost when restoring the configuration backup. So keep this in mind when testing.
If you face any issues, contact our support team with details of the steps you’ve taken, a problem description, and any error messages from the Access Server log file.