VPN Cluster Setup — Access Server
High Availability and clustering for business VPN - read through how it works for Access Server from OpenVPN.
Remove the single point of failure from a traditional Access Server setup with a cluster of Access Server.
Set Up Access Server Clustering
To set up a cluster of Access Servers, follow this tutorial:
How Access Server's cluster feature works
Access Server's clustering feature uses a DNS-baed round-robin system to spread the load from connections and data communications. With a cluster setup, you can run a high-availability Access Server deployment that scales horizontally and provides active-active redundancy.
To learn about the benefits of server clustering, refer to Server Clustering - Robust Clustering Feature.
A typical Access Server cluster 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 licensing pool.
Access Server 2.7.3 and newer supports the clustering feature. With it, you can provide a high-availability solution to load-balance VPN connections and data communications across multiple servers.
The cluster database system
The cluster architecture for multiple 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.
Important
Ensure that all cluster nodes run the same Access Server version.
The round-robin DNS
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.
Failover versus cluster
A standalone 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, 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 take over processing tasks in the event of a primary server failure,. 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 shares a single subscription license 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.
Tip
If you're currently using the failover setup and want to convert to the cluster architecture, you can take these steps:
Turn off failover.
The primary node goes back to being a standalone server.
Important
You must first turn off the failover functionality before switching from a LAN-model UCARP/VRRP type failover system to the cluster architecture.
Use the standalone server to configure the cluster setup.
Add any new standalone servers as new nodes in the cluster.