Setting up an OpenVPN Access Server cluster

Introduction

This document provides an overview of setting up a cluster of OpenVPN Access Servers to both horizontally scale and provide active-active redundancy. A typical setup consists of multiple Access Servers that store configuration files on a shared database, clients connecting to nodes based on a round-robin DNS record, and VPN connections accessed from one global subscription licensing pool.

How clustering works

OpenVPN added the clustering feature to Access Server in version 2.7.3. Clustering provides a high-availability solution to load-balance VPN connections and data communications across multiple servers. A clustering setup consists of multiple Access Servers, or nodes, that all provide active connections for VPN clients.

The cluster architecture for multiple OpenVPN Access Servers requires certificates and credentials stored in a central database — a MySQL, MariaDB, or Amazon RDS database system. Some configuration stays locally on the individual cluster nodes such as which interface to listen on and how to connect to the central database system. The database system can be a single server or a cluster of servers; for example, Amazon RDS offers a fault-tolerant solution for its database system.

Note: Ensure that all nodes of a cluster run the same version of Access Server.

In a simple setup, a DNS-based round-robin system ensures that VPN clients have a single address to connect to while trying different servers in sequential order. If one of the Access Servers fails, a temporary connection failure occurs for the connected clients until they automatically connect to one of the other servers in the cluster.

Note: For MariaDB, we recommend using MariaDB 10.5.8 or newer. A known issue exists in MariaDB 10.4.13, which is due to a bug in the MariaDB code that causes connectivity issues.

Failover vs. cluster

A standalone OpenVPN Access Server manages the user credentials, certificates, services, and access rules for connecting VPN clients. These are stored in SQLite3 database files.

For high-availability environments, OpenVPN Access Server offers both failover and cluster architecture setups.

Failover

The LAN-model UCARP/VRRP based failover system involves running a standby secondary server that can, in the event of a primary server failure, take over processing tasks. The Access Server configuration is synchronized between the primary and secondary servers. This setup can only run on a local network that supports pass-through VRRP/UCARP traffic. Generally speaking, Amazon AWS and other cloud solution providers don’t allow this type of traffic on their networks, so this type of failover setup won’t work.

Cluster

The cluster architecture setup stores Access Server configuration files and certificates in a central database system such as MySQL, MariaDB, or Amazon RDS. Each Access Server node connects to the database system to access the configuration and certificates — and each node actively handles VPN client connectivity. A VPN client can connect to any of these nodes with the same client configuration profile.

Each Access Server node in a cluster can be licensed individually, or you can use a single subscription that allows all of the nodes to share the available VPN connections from that subscription. Each node has its own VPN client subnet, which means that in a cluster, a VPN client connected to node A can’t reach a VPN client connected to node B. The use case for a cluster solution is ideal for large scale access to resources that are only reachable through your VPN server with high-availability, and/or to protect internet access for large numbers of users with high-availability.

If you are currently using the failover setup and want to convert to the cluster architecture, you can turn off failover, which makes the primary node a standalone server again, and then use the cluster setup to convert that server to be a cluster node. Then, you can add any new standalone servers as new nodes in the cluster.

Note: You must first turn off the failover functionality before switching from a LAN-model UCARP/VRRP type failover system to the cluster architecture.

Before you begin

If you are converting an existing Access Server to use cluster architecture, make sure to first back up your settings using the backup commands on the command line. If you’ve never made a backup before, we strongly recommend setting up an automated backup plan.

Purchasing a subscription

The subscription model is ideal for setting up clustering. With a single subscription you can handle the licensing needs for all of the Access Server nodes in your cluster. The nodes simply share the available connections from the subscription as needed. The subscription can be adjusted at any time from the OpenVPN Access Server billing portal. With the fixed license key model, you must purchase a separate key for each Access Server and determine in advance the maximum number of connections each server needs to support. Also, fixed license keys can’t be easily altered once they are implemented.  OpenVPN strongly recommends the subscription model for its simplicity of license management and its flexibility, particularly for the clustering use case.

Setting up the database server

The first step in setting up clustering is to configure your database server. We provide example information for using Amazon RDS and DigitalOcean MySQL. Most other MySQL or MariaDB systems work, with the exception of MariaDB version 10.4.13, which has a known issue that is due to a bug in the MariaDB code that causes connectivity issues.

The term cluster applies to database systems that are fault-tolerant, and it also applies to an active-active setup of multiple Access Servers. To set up a fully fault-tolerant system, you must have both a cluster database setup and an Access Server cluster setup with multiple nodes.

Launch a database server

Start by creating a new database server. We provide some brief steps, but for further information refer to AWS or DigitalOcean for their documentation.

AWS

1. Create a new managed relational database service (RDS) from the AWS service.
2. Follow the configuration steps to select options, specify the instance size and fault-tolerance settings, define the DB instance identifier, and Master username and Master password.
3. Take note of the username and password because you will need them later. 
4. Select your VPN and subnet, public accessibility, optional settings, and complete the launch.

DigitalOcean

1. Create a new database cluster.
2. Choose your required cluster configuration, datacenter, and VPC network.
3. Enter a unique name and select a project.

Database connection information

Take note of this information to connect your Access Server nodes to your database server(s):

AWS

1. Endpoint
2. Master username
3. Master password

DigitalOcean

1. Username
2. Password
3. Host
4. Port
5. Database

Once your database server is up and running, you can use these connection details to set up your first Access Server in the cluster. You can do this with an existing server and turn on clustering, or launch a new server from scratch.

Initial setup of the first Access Server cluster node

Note: Whether you launch a new Access Server or use an existing one, you should ensure that it’s running on the latest version.

To install a new Access Server, sign in to your OpenVPN.net account and click Get Access Server in the portal. There are quick start installation guides available for many platforms: OpenVPN Access Server installations options.

After completing the installation of your new Access Server — or if you are using an existing installation — check that you have the latest version and upgrade if necessary. For detailed upgrade steps, refer to Keeping OpenVPN Access Server updated. Note that when you upgrade an existing Access Server, the subscription, users, and settings are retained.

Firewall configuration — ports to open

The following ports must be open on each Access Server node:

• TCP 22 — SSH access
• TCP 443 — Web interface access and OpenVPN TCP connections
• TCP 943 — Web interface access
• TCP 945 — Cluster control channel
• UDP 1194 — OpenVPN UDP connections

These five ports assume you are implementing a standard configuration. If you have changed your ports previously, adjust the installation as necessary.  Current OpenVPN appliances on Amazon AWS have a default security group that opens up the standard ports.

Database security

Note that Amazon RDS databases are protected by security groups, which is an Amazon-specific security system that functions like a firewall. Therefore, you must adjust the security group settings so that your Access Server nodes can reach the Amazon RDS database.

For DigitalOcean, you must adjust the trusted sources to improve the database security and allow incoming connections from each of your nodes.

Note: If you skip this step, you won’t be able to test any connections to the database server.

Configure and test database server connection

You must first sign in as a root user or get root privileges on your Access Server to run the following commands.

Note that these instructions work for Ubuntu/Debian — you’ll need to adapt them if you’re using a different Linux distribution.

First, install the MySQL and client library packages:

apt-get update
apt-get install mysql-client libmysqlclient-dev

Next, connect to your database instance using the MySQL command line tool, replacing the values with those from your database connection information when you setup your database instance:

AWS

mysql -h [Endpoint] -u [Master username] -p

DigitalOcean

mysql -h [Host] -u [username] -P [port] -D [database] -p

When prompted, provide the Master password (AWS) or password (DigitalOcean). For your DigitalOcean user, you may need to edit the password encryption to support Legacy, MySQL 5.x.

Upon successful connection, you should receive a message similar to this:

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 13
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

You can now exit with the exit command.

Once your system can connect to the database instance, you can proceed with configuring your first node.

Set up a new cluster

Sign in to the Access Server Admin Web UI using the IP address of the server or the custom hostname, if you have configured it, along with /admin.

For example: https://123.45.67.89/admin.

1. Click Configuration > Cluster. 
   • For this first step, we are setting up a new cluster. 
2. Click Yes to Set up a New Cluster.

Convert the Access Server default SQLite3 database to a MySQL-type database

1. Enter the Node Name.
   • This is a unique name that displays on the Status Overview page after you complete your cluster configuration — it automatically populates with the existing node name of your Access Server.
2. Enter your database connection information into the MySQL Settings fields.
   • The MySQL Hostname or IP Address is the endpoint (AWS) or host (DigitalOcean). 
   • The MySQL Port is set to the default port of 3306 — change to the port noted above for DigitalOcean.
   • The MySQL Username is the Master username (AWS) or username (DigitalOcean)
   • The MySQL Password is the Master password (AWS) or password (DigitalOcean).
3. Click Save Settings.
   • The local SQLite3 databases are converted to the new MySQL-type databases. Access Server takes a few minutes or more for this conversion. If your user base is large, the conversion will take longer.
   • Once completed, Access Server restarts automatically.
4. Once the Access Server is restarted, sign back into your Admin Web UI.
   • The Cluster Overview displays your single node. With a cluster setup, some Admin Web UI pages are modifiable for the entire cluster, and others require you to click View/Edit Node to make changes on individual nodes. For example, a node-specific setting is the software license for that node.

Note: When you convert your Access Server to a cluster configuration, any existing user certificates and settings are converted and stored in the new database. You can only do this conversion once — you can’t repeat this to combine multiple different Access Servers with users and settings into one cluster. The first Access Server you use to create your cluster is the master data set. Any additional Access Server nodes use that data set. Any changes you make after creating your cluster architecture are applied to the central database that is used by all nodes in the cluster.

Adding more nodes to the cluster

When adding new Access Server nodes to the cluster, you must ensure the security is in place to connect to the database. For example, you’ll need to set up security groups in AWS, or add each new DigitalOcean droplet as a trusted source to your database server.

After launching each node and completing the initial configuration, sign in to the Admin Web UI on each new node. Click Configuration > Cluster and select Join existing cluster. Enter the database connection details and click Save to join the cluster.

Note: Access Servers that are added to an existing cluster lose their own users and configuration, and instead inherit these from the cluster’s centralized database. However, Access Server creates an automatic local backup before joining the cluster, so in the event you have lost your data due to this action, this backup can be retrieved from the node’s filesystem.

Using round-robin DNS

You have the option to create DNS A records for each of your Access Server nodes that resolve to a single hostname. Another option is to use a more intelligent DNS service such as Route 53, which can manage DNS records based on health checks or geolocation data.

However, a DNS round robin is the simplest solution and it gives your users a single address to use for connections. Each VPN client tries each IP address in the DNS round-robin record in sequential order until it successfully connects. Should a server fail, a temporary connection failure occurs for any clients connected to that server until they automatically connect to another server in the cluster.

To set up DNS A records:

1. Add a new DNS record with your web hosting provider.
2. Select Type A.
3. Enter the Hostname (For example, “VPN” or “cluster”).
4. Enter the IP address of the first node in the cluster.
5. Change the TTL, if desired.
6. Click Save.

Repeat these steps to add each Access Server node as an IP address assigned to the same Hostname. Multiple A records on the same subdomain automatically become a round-robin DNS record in almost all DNS management systems.

For example, a setup with four nodes might look like this:

Managing your active cluster with the Admin Web UI

When your Access Servers are running in a cluster, the Admin Web UI displays differently. When you first login, the Cluster Overview displays your node names, IP addresses, versions, VPN connections, and which nodes are active.

You can click More Info to display the activation type, user authentication, IP addresses accepting VPN connections, port for VPN client connections, OSI layer model, and the server cipher.You can click View/Edit Node to make changes for that specific node. Some settings must be done for the entire cluster, such as user management, and some must be done for each node, such as Network Settings.

Click Restart to restart that node.

Click Remove to remove the node from the cluster.