How to migrate OpenVPN Access Server from AWS Tiered to use the new OpenVPN Subscriptions

Upgrade to Latest Version

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

Follow this guide to migrate from a tiered image over to a BYOL image with a subscription key. We suggest switching over to using a subscription so you have full flexibility to change your licensed amount at any time.

The documentation here provides the steps necessary to do this. You’ll back up your current system, spin up a new one, and then move your backup over to the new system. Your OpenVPN clients won’t require reinstalling to connect as the migration keeps the required user and certificate data intact.

To help you understand whether this would help you, here are the different setups for OpenVPN Access Server on an Amazon Machine Image:

OpenVPN Access Server AWS BYOL Subscription

Bring Your Own License refers to an image launched through AWS with a subscription purchased from openvpn.net. You can manage your connections through the billing portal on our website when you need to change the number of connections. Our new subscription model is designed for deployments in IaaS cloud environments. The BYOL image also supports the fixed license key model.

OpenVPN Access Server AWS Tiered

This refers to a payment agreement with Amazon for the number of connections necessary. If you need to scale up or down, that is done through your AWS account.

Two notes before you begin:

Hostname or Elastic IP:

When you migrate to your new server, the easiest way to keep the user experience the same is to keep their access the same. This means setting up either a hostname or a static IP address. If you did this for your VPN server prior to adding clients, whether it’s by setting up a hostname or using the AWS Elastic IP address, the VPN connections won’t see a difference on their end. If, however, your migration results in a new IP address, you will need to update client connections.

Using a Cluster of OpenVPN Access Servers:

If you are already using a separate database to support a cluster of Access Servers, you will not need to follow these steps for making a database backup and migrating over. Instead, you can set up a new BYOL instance with a subscription, add it to the cluster, then remove the old node. It may help to review the information about changing the database backend to MySQL or Amazon RDS (which you are likely using).

Migrate Access Server Instances

Steps to move from AWS tiered to BYOL instance with subscription.

1Backup your OpenVPN Access Server configuration

Start by backing up your current AWS instance’s OpenVPN Access Server configuration databases. (Refer to our detailed information on creating these backups if you don’t already have an automatic backup system.)

If you are using Access Server in its default configuration, it will be using SQLite configuration database files to store its information. This includes:

  • Passwords (in local auth mode)
  • MFA codes for Google Authenticator
  • VPN client and server certificates
  • Web interface certificates
  • Log Reports database

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

Backing up the SQLite configuration database files saves you the frustrations of losing your data. Migrating without these would break your connections for all OpenVPN clients. Even reinstalling a new server with the same usernames and passwords won’t work. Your Access Server has a unique private and public key that is used internally in the certificate management system to generate unique client certificates. These certificates are not compatible with that of another installation. We want to restore all of this exact information when your new server launches, so migration goes smoothly.

  1. Start by using the below commands, 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
  2. The resulting configuration files are now stored in /usr/local/openvpn_as/. You can find them there with the .bak extension.
  3. Now that you have these backup files created, you can move on to setting up a new Access Server.

2Launch a new instance

Now that you have your Access Server database backups, you can set up your new server to copy those over. Below are the high-level steps for doing this. If you would like more detail, please refer to our existing documentation, How to Use The Access Server AWS Launcher.

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 on Key Pairs under Network & Security.

  1. Purchase your new subscription by choosing the number of VPN connections you need. The following screen will display with your information after:
    Purchase your new subscription
  2. From the Access Server Portal, click on Get Access Server. From there, you can launch a new Cloud Image directly from our site with CloudFormation Script. If you prefer to start from the AWS Marketplace, make sure you choose BYOL to add the subscription.
  3. After you select your AWS Region, choose your new subscription from the drop-down:
  4. Click on Launch Script on AWS.
  5. You will automatically be directed to the AWS site where the subscription auto-populates the Activation Key field. Select the remaining parameters for your new Instance and click on Create stack.
    Stack name Name of your stack
    Activation Key Subscription key
    VPC ID ID of your existing virtual private cloud (VPC)
    Public Subnet ID ID of your existing public subnet of your VPC
    EC2 Instance Name Name of your new EC2 instance
    Instance Type Select the size of your instance
    Key Pair Name Select a KeyPair for SSH access (you’ll also use this for SCP or WinSCP when restoring database files for your migration)
  6. Monitor the progress as AWS creates the stack:
    Monitor the progress as AWS creates the stack
  7. Once the status shows as complete, click on outputs to see the URL for your OpenVPN Access Server Admin Web UI and the password for the first login:
    click on outputs to see the URL
  8. Click on the URL to log in to your Admin Web UI with the username, openvpn, and temporary password. We strongly recommend changing your password. To do so, you need to change the user’s UNIX password from terminal. With root privileges, enter the command passwd openvpn. Enter a new password and confirm it.
  9. To view your new, activated subscription, you can click on Status Overview and see it listed in your Allowed VPN Connections. You can also see it on the Configuration > Activation tab and the billing portal on our website:
    click on Status Overview

3Restore Access Server Data

Now that you have your new subscription server set up, you can move your configuration over to it before going live.

For this step, you’ll need your Key Pairs from both your old and new instances to connect with a file transfer applications such as WinSCP, and connect using SSH to run commands. You’ll login with your key pairs and the default username on our images, ‘openvpnas’.

NOTE: If you are already using a separate database to support a cluster of Access Servers, it may help to review the information about changing the database backend to MySQL or Amazon RDS (which you are likely using).

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 for Windows. Place them under 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: 
    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
  3. Log back in again to re-copy your activation key. Go to the Admin Web UI of your new subscription server and log in as your administrator. You’ll notice that the server is now running with a free subscription of 2 VPN connections. Copy your Activation Key from the billing portal on our website. In the Admin Web UI, click on Configuration > Activation. Paste the key into the field that states, ‘Enter Activation Key here.’
  4. Click on Activate.

4Change your DNS A record or IP address

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, you will need to 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.
    Please refer to the documentation on the AWS site for instructions, if needed.

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

5Cancel your AWS fixed license or tiered instance

Please refer to the AWS website for documentation on terminating your EC2 license. Make sure you choose your instance that was your fixed license Access Server.

Notes:

  1. If you use PAM authentication, the passwords are stored in the operating system. 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:
    transfer the files using WinSCP
  3. If you are using the clustering function of Access Server, your data is stored in a MySQL-type database, separately. 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, then remove the old node from the cluster.