Skip to main content

Tutorial: Migrate from AWS Tiered to a Subscription

Overview

If your Access Server is hosted on an AWS Tiered instance, you may have dealt with the pain of migrating to a new server should you need to increase or decrease your connections. With our subscription model, you can migrate to a new instance, activate a subscription, and stay with your instance, no matter the connections needed. You can increase or decrease your connections to suit your needs simply by changing your subscription on our site.

Follow this guide to migrate from a tiered image to a new one with a subscription key.

Tip

We recommend using a subscription so you can change your license amount anytime.

To migrate, you’ll follow these steps:

  1. Back up your current system.

  2. Spin up a new system.

  3. Move your backup to the new system.

When done properly, your OpenVPN clients won’t require reinstalling to connect, as the migration keeps the required user and certificate data intact.

Important

These steps are for migrating from a tiered AWS instance to an AWS image with a subscription installed. Refer to Access Server license types for details about the different Access Server licenses.

Before you begin

Tip

Review these tips before you begin:

  1. Set up a hostname or elastic IP address first. When you migrate to a new server, the easiest way to keep the user experience the same is to keep their access the same. This is done by setting up a hostname or static IP address. If you did this for your VPN server before adding clients, whether you set up a hostname or used the AWS elastic IP address, your VPN connections won’t see a difference. If, however, your migration results in a new IP address, you’ll need to update client connections.

  2. Note that you should skip the database backup steps if you’re using a separate database to support a cluster of Access Servers. Instead, you can set up a new instance with a subscription, add it to your cluster, then remove the old node.

Back up your current AWS instance’s Access Server configuration databases. Access Server uses SQLite configuration database files to store its information by default. These include:

  • Passwords (for local authentication).

  • MFA codes for TOTP authentication.

  • VPN client and server certificates.

  • Web interface certificates.

  • Log reports.

Use these commands to back up your SQLite configuration database files. Your Access Server has a unique private and public key used internally in the certificate management system to generate unique client certificates. These certificates are incompatible with those of another installation, so you need to migrate them.

  1. Run these commands, with root privileges, to make a backup:

  2. The resulting configuration files are saved in /usr/local/openvpn_as/ with the .bak extension.

Tip

We recommend creating backups automatically as good security etiquette.

Set up a new server to copy over your database backups. For details on these steps, refer to the AWS quick start guide.

When you create a new instance with AWS, you’ll use a key pair to enable SSH access to your instance. If you don’t have one set up in your AWS console to use, you’ll want to create a new one first. This can be done from the EC2 console by clicking Key Pairs under Network & Security.

  1. Purchase a new subscription from our website.

  2. Click on Get Access Server and choose AWS to use the AWS Launcher to quickly spin up a new server with the CloudFormation script.

  3. Once you launch your new server and access the Admin Web UI with your temporary password, you view your subscription under the Configuration > Activation tab.

With your new subscription server running, you can move your configuration over before going live.

To connect with a file transfer application such as WinSCP, you need key pairs from old and new instances. You’ll sign in with your key pairs and the default username on our images, ‘openvpnas. '

Important

You don't need to copy database files if you already use a separate database to support a cluster of Access Servers. Instead, add the new subscription server to your cluster and remove the old, tiered node.

Follow these steps to move your configuration backup to your new server:

  1. Transfer the backup files from the /usr/local/openvpn_as/ folder of your old instance to your new one using SCP or WinSCP. Place them in the same folder: /usr/local/openvpn_as/.

  2. Stop the Access Server service on your new installation, then restore the backup and restart the service using the commands below with root privileges:

  3. Sign in to the Admin Web UI of your new server and click Configuration > Activation. You’ll notice that the server is now running with a free subscription of two VPN connections.

  4. Copy your activation key from the billing portal on our website and paste it into the activation key field.

  5. Click Activate.

To automatically move your clients over to your new subscription server, update your DNS A record if using a hostname so that it points to the IP address of your new server. If you are using the Elastic (or static) IP address in Amazon, take it off your old server and allocate it to the new one:

  1. Log in to your AWS account.

  2. Release the Elastic IP Address associated with your old server.

  3. Associate that Elastic IP Address with your new subscription server.

Once you have set up your hostname or IP address to point to your new server, your users automatically connect to it. The final step is to cancel your old server so you no longer have that instance running and occurring fees.

Helpful Tips

  1. The passwords are stored in the operating system if you use PAM authentication. They will not be backed up in the configuration files from step one.

  2. If you encounter errors when attempting to transfer the files using WinSCP, it may be due to insufficient privileges. Connect using SCP and choose “sudo su -” from the Shell field.

  3. If you use Access Server's clustering function, your data is stored separately in a MySQL-type database. Rather than following the above steps for backing up and restoring database configurations, you will simply set up a new server of BYOL type, add it to the cluster, and then remove the old node from the cluster.