Migrating an Access Server installation

Upgrade to Latest Version

Introduction

This document provides helpful steps for migrating an installation of Access Server to a new server. It also includes information about how to upgrade Access Server in the process.

Before you begin

Before you migrate your server, you’ll take note of the following scenarios, covered in the next sections:

  1. The type of license on your server.
  2. Whether clients connect via IP address or hostname.

We cover how these scenarios impact your server migration.

Licensing considerations and preparations

Take note of the following information about the type of license on your Access Server:

  • Perpetual licenses are the oldest license keys we used to sell but no longer do. Under the original terms of these licenses, which we still honor, these don’t support upgrades. If you use this old license key with an Access Server 1.8.4 or older, you lose your license key when you upgrade. Refer to our licensing FAQ page for more information. You need to purchase a new subscription.
  • Standard license keys are the license keys sold beginning in 2013 until replaced with our subscriptions. With these licenses—also called the bring your own license (BYOL) system—you can upgrade and migrate to another installation, but you must contact us for a license key reissue. You can contact us in advance, as the old license key will still function for up to two weeks, giving you time to migrate your settings to the new server and test things out. Note: We only assist in solving problems with license keys if the license keys are still valid.
  • Pre-licensed AWS tiered instances are the Amazon AWS tiered instances that come pre-licensed with a stated amount of "xx connected devices," you need not worry about licenses. Amazon's systems manage licensing and billing for your instances. You can set up a new instance and migrate your data there. As an example, if you want to switch from a 10 connected devices instance to a 25 connected devices instance, you would backup your old instance's Access Server data, restore it on the new instance, update the DNS record pointing to your Access Server or reattach the old elastic IP to the new instance, and then take the old instance down (to avoid incurring extra costs).
  • Subscriptions: We currently offer subscriptions, which significantly simplifies migrating Access Servers. You can activate your subscription on more than one server at a time. You don’t need to contact us for a reissue. You can have the subscription activated on the old and new servers simultaneously as you migrate. For more, refer to our Subscription FAQ.

IP address change, DNS record update

Your users and clients can connect to your Access Server in two ways:

  • Using the server’s IP address.
  • Using a fully-qualified domain name (FQDN) or hostname.

You can connect to the Admin Web UI and Client Web UI for your Access Server using either the IP address or a hostname.

If you use the server IP address:

If your clients connect using the IP address, this will likely change when you migrate servers, and clients will no longer be able to connect. Existing client installations will need to download new connection profiles—unless you can associate the same IP address with the new server (such as with an Elastic IP in AWS).

We recommend setting up a proper hostname, such as vpn.yourcompany.com, so you don’t have to update clients and connections should the server’s IP address change. Refer to Setting up your OpenVPN Access Server hostname for the steps on registering a domain name, adding a DNS A record, and adding the hostname in the Admin Web UI.

With a hostname setup, your clients won’t lose connections or have to download new connection profiles when you migrate servers. You only need to update the DNA A record to point to the new IP address of your new server and clients connect.

If you use the hostname:

If your clients connect using the hostname, you’ll only need to update the DNS A record with the new IP address once you’ve migrated servers.

It is worth noting that an FQDN DNS address is required to get a properly validated and signed SSL certificate installed and working on your Access Server, and we do recommend this.

If you're on Amazon AWS, and your old server has an Elastic IP, you can disassociate the Elastic IP from the old instance, associate it with the new instance, and then you don't need to update any DNS record or IP settings.

Making a backup of the old Access Server

The first step in migrating servers is to make a backup of your current environment. Here we explain Access Server’s configuration database and provide the commands to create backup files.

Access Server’s Configuration Database

Access Server’s configuration database files contain log reports, user properties, certificates for VPN connections, certificates for the web interface, and so on. Every installation of OpenVPN Access Server comes with a unique private key and public key used internally in Access Server’s certificate management system built to generate unique client certificates. The certificates for one installation of OpenVPN Access Server are not compatible with that of another installation.

We recommend creating regular backups of the configuration database files so, in the event of a server crash, you can restore the necessary data to get your clients reconnected without requiring them all to reinstall their clients or connection profiles.

Likewise, with a migration, we will restore things so that installed OpenVPN clients can connect again with the same connection profiles they already have. This assumes that you have set up the Access Server with an FQDN DNS name and can update the DNS record to point to the new IP address or that you can keep the old IP address intact.

Backup Commands

With the commands below you can backup all the required information while your OpenVPN Access Server is live. That means you do not need to stop the Access Server service to make a backup file; it can continue running while you create the backup files.

Security note: The security of your VPN system is compromised if anyone gets a hold of these backup files; it contains all the settings and certificates. So please do pay attention to where you store these backups and how you store them.

Use the commands below with root privileges to make a backup:

which apt > /dev/null 2>&1 && apt -y install sqlite3
which yum > /dev/null 2>&1 && yum -y install sqlite
cd /usr/local/openvpn_as/etc/db
[ -e config.db ]&&sqlite3 config.db .dump>../../config.db.bak
[ -e certs.db ]&&sqlite3 certs.db .dump>../../certs.db.bak
[ -e userprop.db ]&&sqlite3 userprop.db .dump>../../userprop.db.bak
[ -e log.db ]&&sqlite3 log.db .dump>../../log.db.bak
[ -e config_local.db ]&&sqlite3 config_local.db .dump>../../config_local.db.bak
[ -e cluster.db ]&&sqlite3 cluster.db .dump>../../cluster.db.bak
[ -e clusterdb.db ]&&sqlite3 clusterdb.db .dump>../../clusterdb.db.bak
[ -e notification.db ]&&sqlite3 notification.db .dump>../../notification.db.bak 
cp ../as.conf ../../as.conf.bak

Once completed, you now have backup configuration files in /usr/local/openvpn_as/. They all end in .bak and contain everything unique about your OpenVPN Access Server installation.

If you have an Access Server subscription, this is included in the above backups and works on the new server when you restore the data. Fixed license keys can’t be backed up or copied over, and the only way to migrate those is to contact support and request a fixed license key reissue.

If you use PAM, LDAP, or RADIUS authentication:

The above commands create a backup file of users and passwords for local authentication.

If any of your users authenticate with PAM, their passwords are stored in the operating systems. The above commands don’t backup PAM users or passwords.

For user authentication with LDAP or RADIUS, their passwords are stored in those systems and not involved in the migration process of Access Server—as long as the server can reach those systems on the new installation.

Restore backup to the new server

After you’ve created your backup files, set up your new Access Server, and then refer to this section for restoring your backup files on your new server. The commands below will help you follow these steps:

  1. Sign in to your new server with root access.
  2. Stop the Access Server service.
  3. Transfer backup files from the previous server to the new server using SCP or WinSCP (for Windows) to /usr/local/openvpn_as/.
  4. Restore the backup.
  5. Create the user openvpn (for certain situations detailed below).
  6. Start the OpenVPN Access Server service again.

Note: You can’t combine Access Server configurations. When you run these commands to replace configuration files with the backups, any configuration on the new server is wiped out and replaced by the contents of the backup files.

Use the commands below with root privileges to restore the backup:

service openvpnas stop
which apt > /dev/null 2>&1 && apt -y install sqlite3
which yum > /dev/null 2>&1 && yum -y install sqlite
cd /usr/local/openvpn_as/etc/db
[ -e ../../config.db.bak ]&&rm config.db;sqlite3<../../config.db.bak config.db
[ -e ../../certs.db.bak ]&&rm certs.db;sqlite3 <../../certs.db.bak certs.db
[ -e ../../userprop.db.bak ]&&rm userprop.db;sqlite3 <../../userprop.db.bak userprop.db
[ -e ../../log.db.bak ]&&rm log.db;sqlite3 <../../log.db.bak log.db
[ -e ../../config_local.db.bak ]&&rm config_local.db;sqlite3 <../../config_local.db.bak config_local.db
[ -e ../../cluster.db.bak ]&&rm cluster.db;sqlite3 <../../cluster.db.bak cluster.db
[ -e ../../clusterdb.db.bak ]&&rm clusterdb.db;sqlite3 <../../clusterdb.db.bak clusterdb.db
[ -e ../../notification.db.bak ]&&rm notification.db;sqlite3 <../../notification.db.bak notification.db
[ -e ../../as.conf.bak ]&&cp ../../as.conf.bak ../as.conf
chmod 0600 /usr/local/openvpn_as/etc/db/*.db
chmod 0600 /usr/local/openvpn_as/etc/as.conf
service openvpnas start

This restores the configuration backup.

When to create the openvpn admin user before starting the openvpnas service:

OpenVPN Access Server 2.10.0 and newer no longer creates the system user, openvpn. Instead, it’s created as a local user in Access Server’s user database. If you migrate configuration from Access Server 2.9.6 and older, you need to create this system user with these commands:

adduser openvpn
passwd <SET_PASSWORD>

There are a few caveats to note for your configuration backup:

  • If you restore a configuration backup to another server, you might have your system configured in a specific way that doesn't work on the new server installation. For example, if you set Access Server to listen on a specific IP address, you may run into issues where the web interface won’t respond if the new server’s IP address is different. To resolve this, check the section on resetting the interface and port for the web services to listen on to default settings. Once you have access to the Admin Web UI, you can reconfigure your settings. Alternatively, you can use the command-line tools to configure the web server settings manually.
  • The configuration database also contains the setting on how many TCP daemons and UDP daemons to launch. If this is set higher than available CPU cores, Access Server may become unstable. So if you have restored this configuration on a different server, and the amount of CPU cores is different from the server the configuration backup came from, adjust this on the Network Settings page in the Admin Web UI, or use our reset commands for the OpenVPN daemons here.
  • If you’re using an Amazon AMI you can either update the DNS record to point to the new public IP or move the elastic IP (if you have that—it's not available for every system on Amazon) to the new server instance. Then you can take the old instance down.

Test with local hosts file

Before you switch over to the new server and shut down your old server, you can test a connection from your machine using the local hosts file.

The local hosts file lets you manually map FQDN entries or hostnames to IP addresses. There are programs for your operating system (such as Hosts File Editor for Windows) to edit the hosts file to point a specific hostname to a specific IP. Using your preferred method, follow these steps:

  1. Open the hosts file with administrator privileges.
  2. Add the IP address of your new VPN server.
  3. Point it to your hostname, such as vpn.yourcompany.com.
  4. Test your connections to the new server:
    1. Can you access the Admin Web UI and the Client Web UI?
    2. Can you connect to the VPN server with your existing OpenVPN Connect connection profile?

Once your tests pass, you can update the DNS record to point to your new server, so all users switch over.