Tutorial: Migrate from Azure Tiered to Azure PAYG or Access Server Subscription
Migrate an OpenVPN Access Server deployment from Azure Tiered (pre-licensed AMI) to Azure PAYG (billed through Azure Marketplace) or a standalone Access Server subscription — covers backing up your configuration, switching your Azure instance, and restoring Access Server settings.
Overview
An Azure Tiered Access Server deployment has a fixed connection amount. To move to a licensing model that offers more flexibility for changing connections, migrate your Access Server configuration to a new Azure instance using either Azure pay-as-you-go (PAYG) or an Access Server Subscription.
You can't convert the licensing model on the same instance. This is a one-time migration to a new Azure virtual machine (VM). After the migration, you can change the connection amount using the licensing controls for PAYG or your Access Server Subscription without migrating Access Server to another VM again.
With Azure PAYG, you purchase and manage Access Server through Azure Marketplace, and Microsoft Azure handles the Access Server billing. With an Access Server Subscription, you deploy a bring-your-own-license (BYOL) instance and activate it with a license activation key from OpenVPN.
Before migrating, create a configuration backup of your Azure Tiered instance. You'll launch the replacement instance, restore the Access Server configuration, verify the Azure networking and new license, move traffic to the new instance, and then retire the Azure Tiered deployment.
For an overview of the available Azure licensing options, refer to Deploy Access Server on Azure — Choose Your Licensing Model.
Choose your destination licensing model
Licensing model | Access Server billing | License management | Future connection changes |
|---|---|---|---|
Azure PAYG | Microsoft Azure | Azure Marketplace | Change the PAYG plan without migrating Access Server to another Azure VM. |
Access Server Subscription | OpenVPN | Access Server Hub and license activation key | Change the subscription connection amount without migrating Access Server to another Azure VM. |
Prerequisites
Before starting the migration, ensure you have:
An existing Azure Tiered Access Server deployment.
Administrative access to Access Server.
SSH access to the current Azure VM.
Permission to deploy a new Azure VM and its associated Azure resources.
If you're migrating to Azure PAYG: access to Azure Marketplace and a new OpenVPN account. Azure PAYG requires a new Access Server Hub account, so you can’t use the account associated with your current Azure Tiered deployment. Create it before you start (Step 3).
If you're migrating to an Access Server Subscription: an OpenVPN account with an active Access Server Subscription and its license activation key. You can use your existing Access Server Hub account.
Access to your DNS provider if you use a hostname for Access Server.
A maintenance window for the final cutover.
A current configuration backup.
Tip
Refer to Tutorial: How to Back Up Access Server Configuration for the complete Access Server backup procedure. Access Server stores its default configuration in SQLite database files, including the server configuration, certificates, user and group properties, logs, local-node configuration, and cluster-related configuration.
Important
The backup and restore commands in this tutorial apply to Access Server installations that use the default SQLite configuration databases.
If your deployment uses a separate database for an Access Server cluster, don't use the SQLite backup and restore procedure. Instead, deploy the replacement instance, add it to the existing cluster, verify it, and then remove the Azure Tiered node.
Important
An Access Server configuration backup doesn't recreate Azure infrastructure. Azure resources and settings such as network interfaces, public IP addresses, network security groups, IP forwarding, and route tables need to be reviewed separately on the new instance.
Choose the licensing model you want to use before launching the replacement Azure instance.
Decide whether you want to manage Access Server billing through Azure Marketplace or directly through OpenVPN.
Choose one of the following:
Azure pay-as-you-go (PAYG): Use this option if you want Azure Marketplace to manage Access Server billing.
Access Server Subscription: Use this option if you want to purchase and manage the Access Server license directly through OpenVPN.
Complete any account or subscription setup required for your chosen option before continuing.
Option 1: Azure PAYG
You purchase Azure pay-as-you-go (PAYG) through the Azure Marketplace. Microsoft Azure handles billing for both the Access Server Marketplace subscription and your Azure infrastructure.
The Azure PAYG workflow lets you select a plan based on the number of connections you need when you subscribe.
Refer to Azure PAYG for the current deployment procedure.
Option 2: Access Server Subscription
You purchase and manage an Access Server Subscription directly through OpenVPN. For this migration path, deploy an Azure BYOL instance and activate it with your OpenVPN license activation key.
Azure BYOL separates the Access Server subscription from Azure infrastructure billing: OpenVPN bills the Access Server Subscription, while Microsoft Azure bills the Azure VM and related resources.
Refer to Azure BYOL for the current Azure Marketplace deployment procedure.
Create a current configuration backup of the Azure Tiered deployment before launching the replacement server.
Access Server can create its SQLite configuration backups while the service is running; you don't need to stop Access Server to perform the backup.
Connect to the Azure Tiered VM using SSH.
Get root privileges.
Run the following commands to create the configuration backup:
The backup files are created in
/usr/local/openvpn_as/with the.bakextension.
Verify the backup files exist.
Store the backup somewhere you can access when the new Azure instance is ready.
Note
If you use PAM authentication, the operating system stores user passwords rather than the Access Server configuration databases. This configuration backup doesn't include PAM passwords.
Launch a new instance using the licensing model you selected in Step 1.
You can't switch an existing Azure Tiered instance to PAYG or an Access Server Subscription in place.
Option 1: Launch an Azure PAYG instance
To launch the replacement server with Azure PAYG:
Important
This option requires a new Access Server Hub account.
Under Installation, select Azure.
Under Azure Deployment Options, select Azure Marketplace Options.
Select Buy with Azure for the Azure PAYG option to continue to the SaaS Contract offering.
Sign in to your Microsoft Azure account if prompted.
Select the PAYG plan for the number of connections you need.
Select Subscribe.
Enter your Project details:
Subscription
This auto populates.
Resource group
Select your group from the drop-down to assign this new image.
Name
Enter a name for your SaaS subscription.
Contract duration
Select between monthly and yearly.
Auto-renew
Select whether to set your plan to auto-renew.
Select Review + subscribe.
Review the product and plan details, then select Subscribe.
The SaaS subscription is in progress and will display a successful subscribed message when complete.
In the Azure portal, select Configure your account.
You're redirected to the OpenVPN website.
On the OpenVPN site, the Link Your Azure Account to OpenVPN sign-in page appears.
Enter your OpenVPN account email and password, then select Sign In.
Enter your account details and select Confirm.
The page Deploy on Azure marketplace using our Azure Launcher displays.
Select Azure SaaS Subscriptions in the side navigation.
Your Azure SaaS subscription details display.
From the Azure deployment, select Outputs.
The URL for the Admin Web UI is displayed in the adminPortal field, along with the temporary password.
Open your web browser and navigate to the Admin Web UI using the provided IP address, such as:
https://<public_ip_of_instance>/admin
Note
During deployment, Let's Encrypt is enabled by default for the public IP address. If you don't enable Let's Encrypt, or certificate issuance isn't successful, Access Server uses its self-signed certificate. Your browser may display a certificate warning when you open the web interface.
Enter the admin username, openvpn, and your temporary password displayed in the output.
Once signed in, we recommend changing the password for the openvpn user account in the Admin Web UI.
From the Azure portal, record the new instance's public and private IP addresses.
Ensure you have SSH access to the new VM. You'll need SSH access to restore the configuration backup in Step 4.
Refer to Azure PAYG for the complete PAYG process.
Option 2: Launch an Azure BYOL instance
To use an Access Server Subscription, launch an Azure BYOL instance:
Sign in to the Access Server Hub.
Under Installation, select Azure.
Under Azure Deployment Options, select Azure Marketplace Options.
Under Azure Virtual Disk Image, select Launch from Azure Marketplace.
Sign in to your Microsoft Azure account if prompted.
Review the OpenVPN Access Server BYOL listing in Azure Marketplace.
Select Get It Now.
Azure redirects you to the Azure portal.
Select Create.
On the Basics tab, configure the VM:
Setting
Description
Subscription
Select the Azure subscription for the deployment.
Resource group
Select an existing resource group or create a new one.
Virtual machine name
Enter a name for the Access Server VM.
Region
Select the Azure region where you want to deploy Access Server.
Image
Leave the OpenVPN Access Server Azure Marketplace image selected.
VM architecture
Select the architecture appropriate for your deployment.
Size
Select an available VM size that meets your Access Server capacity and performance requirements.
Authentication type
We recommend SSH public key.
Username
Enter the administrative username used to connect to the VM over SSH. Azure defaults to
azureuser.SSH public key source
Select an existing key, use an existing public key, or create a new key pair.
SSH key
Complete the SSH key configuration for the option you selected.
Note
Azure VM size availability depends on your subscription, region, quota, and current Azure capacity. If your preferred size isn't available, select another suitable VM size or region.
Configure any additional Azure settings required for your environment.
Select Review + create.
Review the deployment configuration.
Select Create.
Wait for Azure to deploy the required resources, including the VM, network interface, public IP address, and network security groups.
When the deployment completes, select Go to resource.
Record the new instance's private and public IP addresses.
Connect to the VM with SSH.
Complete the initial Access Server command-line configuration if required.
Tip
Refer to Azure BYOL for the complete BYOL deployment process.
Transfer the configuration backup to the new instance, then restore it.
Copy the
.bakfiles from/usr/local/openvpn_as/on the Azure Tiered instance to a safe location on your local machine. You can use SCP, WinSCP, or another SSH-based file transfer tool.From your local machine, transfer the
.bakfiles to the home directory of your SSH user on the new Azure VM:scp ./*.bak <username>1@<new-vm-public-ip>2:/home/<username>/
Replace
<username>with the SSH username you configured when you deployed the VM.Replace
<new-vm-public-ip>with the new VM's public IP address.Tip
Azure uses
azureuserby default. For example:scp ./*.bak azureuser@203.0.113.25:/home/azureuser/
Connect to the new Azure VM with SSH.
Get root privileges.
Copy the backup files to the Access Server directory:
cp /home/<username>1/*.bak /usr/local/openvpn_as/
Replace
<username>with the SSH username, for exampleazureuser.Run the following commands to stop Access Server, restore the configuration databases and
as.conf, and start Access Server again:Required for Azure PAYG: Run the command below to grab and activate your subscription license key:
sacli -v $(grep '^license=' /var/lib/cloud/instance/user-data.txt | cut -d'=' -f2-) LoadSubscription
Verify that Access Server starts successfully:
systemctl status openvpnas
The new instance now contains the restored Access Server configuration, including the configuration databases and certificates from the Azure Tiered deployment.
Important
The backup files contain your server certificates and user data. After you’ve verified the migration, delete the copies from your workstation and from the home directories on both VMs.
Verify that the new instance is using the licensing model you selected.
Azure PAYG
For an Azure PAYG instance:
Open the Admin Web UI for the new instance.
Sign in with your administrative credentials.
Navigate to the Access Server licensing information.
Verify that the server is associated with the Azure PAYG deployment.
Verify that the expected connection amount is available.
In Azure, verify that the expected Access Server PAYG subscription and plan are active in Azure Marketplace.
The replacement instance uses Azure PAYG and displays the expected number of licensed connections.
Access Server Subscription
For an Access Server Subscription:
Sign in to the Access Server Hub.
Select Subscriptions.
Locate the Access Server Subscription you want to use.
Copy its license activation key.
Open the Admin Web UI for the new instance.
If the Activate your Access Server page displays, paste the activation key and select Activate. If you already have access to the Admin Web UI, navigate to Activation, select Activate License Key, paste the activation key, and activate it.
Wait for Access Server to validate and load the subscription.
Verify that the expected connection amount displays.
Refer to subscription activation for the complete procedure.
Restoring the Access Server configuration doesn't recreate or update Azure networking. Verify the Azure resources and settings your deployment requires.
Verify that the new VM is connected to the expected Azure virtual network and subnet.
Verify the network security group rules required for Access Server traffic.
Verify the new VM's private IP configuration.
Verify its public IP configuration.
If Access Server uses NAT for VPN traffic, verify connectivity before proceeding to the next step.
If Access Server uses routing instead of NAT, verify that IP forwarding is enabled on the new VM's network interface.
Review the Azure route tables associated with the networks that need to reach VPN clients.
Update routes whose Next hop address references the old Access Server VM's private IP so that they point to the new VM's private IP.
Verify any additional Azure networking dependencies, such as firewalls, load balancers, or network appliances.
Important
When Access Server uses routing, enable IP forwarding on the new network interface and update any route whose next hop is the old VM’s private IP.
Point the address your VPN clients use at the replacement instance.
The restored configuration includes the Azure Tiered instance’s hostname or IP address setting. Access Server uses that address in the connection profiles it generates and in its web interfaces. If clients keep using the same address after the migration, existing connection profiles keep working without changes.
Choose the option that matches how your clients connect:
Hostname: Update the DNS record.
Static Azure public IP: Move the public IP resources to the new VM.
Neither, or the address can't be preserved: Update the address in Access Server and redistribute connection profiles.
If you use a hostname
Record the new Azure instance's public IP address.
Update the hostname's DNS A record to point to the new public IP address.
Allow time for the DNS change to propagate, depending on your DNS configuration.
Resolve the hostname and verify that it returns the new IP address.
Open the Admin Web UI using the hostname and verify that it reaches the new instance.
You don’t need to change the hostname setting in Access Server, since the restored configuration already uses it.
If you use an Azure static public IP
You can move a public IP address to the new VM only if its Azure Public IP address resource uses Static assignment. A dynamic public IP is released when you remove it from the VM and can’t be moved.
Important
Removing the public IP from the Azure Tiered VM immediately disconnects VPN clients and makes that VM unreachable at that address. Do this during your maintenance window. To keep SSH access to the old VM, use its private IP from within the virtual network, or another method such as Azure Bastion.
Confirm the address is static
In the Azure portal, open the Azure Tiered VM and select Networking.
Select the public IP address to open its Public IP address resource.
Under Settings, select Configuration.
Verify that Assignment is set to Static. If it’s Dynamic, you can’t preserve this address; follow If the address changes instead.
Confirm that the public IP is in the same Azure region and subscription as the new VM.
Remove the public IP from the Azure Tiered VM
Open the network interface attached to the Azure Tiered VM.
Select IP configurations, then select the IP configuration that uses the public IP (usually
ipconfig1).Remove the public IP address association, then select Save.
Attach the public IP to the new VM
The new VM already has its own public IP from deployment, and each IP configuration can hold only one public IP address. Replace it with the original address:
Open the network interface attached to the new VM.
Select IP configurations, then select its IP configuration.
For the public IP address, select the original public IP resource from the Azure Tiered VM, then select Save.
Verify that the new VM’s overview page shows the original public IP address.
Verify that the Admin Web UI and VPN services are reachable through the address.
Delete the public IP resource that Azure created for the new VM if you no longer need it, so you don’t keep paying for it.
If the address changes
If you can’t preserve the hostname or public IP, update Access Server to use the new address. Existing connection profiles still point to the old address and need to be replaced.
Sign in to the Admin Web UI on the new instance.
Navigate to VPN Server.
Update DNS hostname (or IP address) to the new instance's hostname or public IP address.
Select Save and Restart.
Tip
You can also set it from the command line with root privileges:
sacli --key "host.name" --value "<new-hostname-or-public-ip>" ConfigPut sacli start
If the web certificate was issued for the old address, install a certificate for the new address. Otherwise, browsers display a certificate warning.
Have users download new connection profiles from the Client Web UI, or distribute new profiles or installers.
Note
Connection profiles include the server address. Clients using profiles from the Azure Tiered instance continue trying to reach the old address until they import a new profile.
Verify the Access Server configuration, license, networking, and client connectivity before retiring the Azure Tiered instance.
Sign in to the Admin Web UI on the new instance.
Verify the expected licensing model:
Azure PAYG, or
Access Server Subscription.
Verify the expected number of available VPN connections.
Verify that the expected users and groups are present.
Verify your authentication configuration.
Verify the Access Server web and VPN certificates.
Verify the VPN network and access-control configuration.
Connect with an existing connection profile.
Verify that the VPN connection succeeds.
Verify access to the expected private resources.
If you use routing, verify connectivity through the updated Azure route tables.
Review the Access Server logs for unexpected errors.
Expected result: Existing users can connect to the replacement Access Server using the migrated configuration, and the server operates with the new PAYG or Access Server Subscription licensing model.
Important
Don't delete the Azure Tiered instance until you've verified the replacement instance and are confident you don't need to roll back.
After you've verified the migration, retire the old Azure Tiered deployment.
Ensure production VPN traffic is using the new instance.
Stop the Azure Tiered VM.
Test the replacement instance again with the old VM stopped.
Confirm that:
Users can connect.
Authentication works.
Private-resource access works.
Licensing is correct.
Azure routing works as expected.
Keep any backups you need for your retention or rollback requirements.
Delete the old Azure Tiered VM and resources you no longer need.
Cancel or remove the old Azure Tiered Marketplace subscription as needed so you don't keep incurring charges.
The benefit of this one-time migration is that future connection changes don't require moving Access Server to another Azure VM.
Azure PAYG
After migrating to Azure pay-as-you-go (PAYG), change the connection amount through the Azure Marketplace PAYG plan instead of launching another Access Server instance.
Open your Access Server PAYG subscription in Azure.
Change the PAYG plan to the connection amount you need.
Confirm the plan change.
Verify the updated connection amount in Access Server.
Access Server Subscription
After migrating to an Access Server Subscription, change the subscription connection amount through the Access Server Hub.
Sign in to the Access Server Hub.
Open your Access Server Subscription.
Select the option to modify the subscription.
Change the number of VPN connections.
Confirm the subscription change.
Verify the updated connection limit in Access Server.
Helpful migration notes
PAM authentication: PAM passwords are stored in the operating system and aren't included in the Access Server configuration backup.
Clusters: If your Access Server cluster uses an external MySQL-type database, use the cluster migration approach rather than copying the SQLite databases.
Azure infrastructure: The configuration backup restores Access Server data, not Azure network interfaces, security groups, route tables, IP forwarding, or other Azure resources.
Hostnames and addresses: If the address users connect to changes during migration, update the Access Server hostname or IP address setting and redistribute connection profiles. Preserving the existing hostname or static public IP avoids this. Refer to Step 7: Move the hostname or public IP to the new instance.
Rollback: Keep the Azure Tiered instance until you've verified authentication, VPN connectivity, private-resource access, licensing, and Azure networking on the replacement instance.