Tutorial: Migrate from AWS Tiered to AWS PAYG
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 to increase or decrease your connections. With our AWS SaaS Marketplace listing, you can migrate to a new EC2 instance with a flexible subscription model through AWS. This option allows you to manage your Access Server connections directly through AWS billing while maintaining the ability to quickly scale your connections up or down as needed without the hassle of instance migrations.
Follow this guide to migrate from an AWS-tiered instance to the new SaaS listing, where you can choose your connections and adjust them anytime through AWS.
Tip
We recommend using this AWS subscription model to scale your connections quickly and avoid having to spin up a new instance each time your needs change.
To migrate, you’ll follow these steps:
Back up your current system.
Launch a new instance from the AWS SaaS Marketplace.
Move your backup to the new system.
When done correctly, your OpenVPN clients won’t require reinstalling to connect, as the migration keeps the necessary certificate and user data intact.
Important
These steps are for migrating from a tiered AWS instance to an AWS instance using the subscription model available on the AWS SaaS Marketplace. Refer to Access Server license types for details about the different licenses.
Before you begin
Tip
Review these tips before you begin:
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.
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.
An AWS tiered instance.
A hostname or elastic IP set up for accessing the VPN and Web UIs.
SSH access to the instance.
AWS Marketplace account.
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.
Run these commands, with root privileges, to make a backup:
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 PAYG quick start guide.
Important
Ensure you have an SSH key for the new instance or access to the key used for the existing AWS Tiered instance. You can use the same private key to establish SSH access to both instances.
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:
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/.
Stop the Access Server service on your new installation, then restore the backup and restart the service using the commands below with root privileges:
Connect to the console and get root privileges.
Run the below command to grab and activate your subscription license key:
sacli -v $(grep '^license=' /var/lib/cloud/instance/user-data.txt | cut -d'=' -f2-) LoadSubscription
Caution
Only run this command in your Access Server launched via Cloudformation (AWS pay as you go).
Sign in to the Admin Web UI to see the available, licensed connections on the Status page.
Tip
You can also check your subscription status by running the below command:
sacli SubscriptionStatus
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:
Log in to your AWS account.
Release the Elastic IP Address associated with your old server.
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
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.
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.
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 PAYG type, add it to the cluster, and then remove the old node from the cluster.