Understanding clustering with OpenVPN Access Servers

Clustering: creating a cluster of Access Servers

What is clustering? You can think of it like a team of Access Servers delivering privacy and security to your users. They work together to manage connections and they remove the single point of failure from a traditional setup through one Access Server. If you need to increase the availability and load capacity of your OpenVPN Access Server environment, this is exactly what you need. Introduced in version 2.7.2, this new feature allows you to create this high-availability setup. Here’s how to get started, where to find detailed resources, and FAQs.

The benefits of Access Server’s cluster configuration

  • Deploy a team of Access Servers
  • Provide consistent up-time
  • Increase load capacity across multiple servers
  • Create your high-availability solution
  • Store certificates and credentials in a central, high-availability database server
  • Remove a single point of failure with one Access Server
  • Can be deployed entirely in the cloud
  • Provide users a single address for VPN connections

Getting started with an OpenVPN Access Server cluster

Setting up an OpenVPN Access Server cluster gives you the ability to spread the traffic load across multiple servers. We continue to add improvements to this solution with each new version of the product and are very open to feedback from our customers. To do so, please use our support ticket system.

Here’s a brief overview of what the setup entails:

  1. Online interfaces and connect clients: Administrators and users connect using the address of your Access Server through the web admin interface and connect clients.
  2. Round-robin DNS server: The interfaces and connect clients use the same DNS to connect to the round-robin DNS server which then makes the connection to the cluster of OpenVPN Access Servers. It tries to connect to a random server in your cluster, and if it is unavailable, it moves on to the next server automatically.
  3. Cluster of OpenVPN Access Servers: Multiple servers are configured with OpenVPN Access Server to handle traffic load.
  4. Configuration file saved on a database: All OpenVPN Access Servers use the configuration files saved on a MySQL-type database such as Amazon RDS, MariaDB, or MySQL. Such a central database allows multiple Access Server nodes use the same credentials, certificates, and other settings across the cluster. This would ideally be set up on a high-availability solution as well to eliminate that as a single point-of-failure.

We provide in-depth instructions for setting up an OpenVPN Access Server cluster. When you follow that link, you’ll be led through these six steps:

Step 1: Set up your database

You’ll need a MySQL-type database and we provide a guide for using Amazon RDS, as this is a suitable solution that comes with high-availability as an option.

Step 2: Set up your OpenVPN Access Server cluster node and login to the Web Admin UI

You’ll either upgrade your current version of Access Server or install a new server. After completing the upgrade or install, you’ll configure clustering options with the Web Admin UI.

Step 3: Configure the firewall

You’ll need to open up one additional port (TCP 945) for cluster communication. The other well-known ports that must be opened with any Access Server include TCP 443, TCP 943, and UDP 1194.

Step 4: Configure your database server connection

Connect Access Server with your MySQL-type database.

Step 5: Set up a new cluster

Create your configuration files on your database server and connect each Access Server.

Step 6: Integrate a round-robin DNS

Set up one URL that clients connect to in order to access any of the Access Servers available.

We provide 24/7 support with our global team of professionals to assist you with any steps or questions, if needed. Simply login with your free OpenVPN account and create a support ticket.

Frequently Asked Questions

A cluster is an active-active, high-availability setup — which means that all nodes within your cluster are active and thus all allow incoming connections at the same time.

At this time, it is required that each node has its own purchased license key(s) to unlock a certain amount of concurrent connections.

For example, you could have four active nodes within a cluster and a total of 100 connections spread across those four nodes. So you would purchase a separate license key for each of your nodes — you could have four separate keys with 25 connections each for a total of 100 connections.

Yes. In this first phase of implementation, cluster support is primarily aimed at Amazon AWS where adding a new node can be automated with tiered instances. Amazon also offers high-availability database services necessary for the clustering setup, meaning you can run the entire solution with Amazon AWS.

Note: Amazon AWS tiered instances work without separately purchased license keys, but are licensed through Amazon automatically when such a node is launched.

We are developing a new licensing system that will let you connect multiple Access Servers to a central pool of licenses, making this solution even more attractive to deploy. We will continue to improve features with each new release of Access Server.

If the server cannot be repaired, remove it from the DNS records. Set up a new Access Server, attach it to the cluster, and add it to the round-robin DNS record to replace the failed node.

Access Server comes with a built-in failover mode which can be deployed on a local area network (LAN). The design is such that you have one primary Access Server, or node, with a secondary standby node that comes online automatically should your primary node fail. Think of it like having your All-Star athlete in the game and if something happens, you sub in your bench player. When this happens, the secondary node becomes the new, primary mode.

This setup uses Virtual Router Redundancy Protocol (VRRP) that stores a virtual IP and MAC address so the client doesn’t need to know if it’s connecting to the primary or secondary node. The VRRP triggers the standby Server if the primary fails. This setup is not compatible with Access Server deployments through Amazon AWS, as they block this traffic. You can read more detail about this high-availability failover mode at the link.

In contrast, a cluster is accessed through a DNS round-robin server. Through it, the VPN client makes a connection with any one of the nodes in the Access Server cluster. If that connection fails, it attempts the next connection after a brief pause. For the client, the user experience is the same, whether it’s a clustering or a failover setup. Either way, they connect with the same address and are indifferent which server makes the connection. Clustering works very well with Amazon AWS.

Set up a new Access Server, install the latest Access Server build on it, and log on to the Admin UI. From there, go to Cluster and choose Join existing cluster. You will then enter the database credentials to connect and join the cluster.

If you are using an existing Access Server with users and configurations, adding it to a cluster will then wipe this node clean. It will get its user certifications and other information from the cluster instead.

Additionally, you can automate this with a command line script. For specific details, please submit a request for support.

We address these frequently asked questions right here: Frequently Asked Questions.

Share this story: