Tutorial: Smart Routing with Access Server Clustering and AWS Route 53⁠

Overview⁠

This document provides steps for setting up smart routing for VPN clients connecting to a cluster of Access Server nodes through Amazon’s Route 53 DNS routing. This configuration forwards OpenVPN connections to the nearest Access Server node, minimizing latency. With our configuration example, we launch an Access Server cluster with nodes in the United States and Europe. When users connect, their OpenVPN Connect app automatically connects with the closest node.

Setup⁠

Our configuration consists of the following:

Access Server node in North Virginia	203.0.113.54
Access Server node in Frankfurt	198.51.100.18
Route 53 hosted zone	companyname.com
Round-robin DNS hostname	openvpn.companyname.com

Requirements⁠

Both Access Server nodes must be deployed on AWS cloud.
The DNS zone that includes the endpoint for OpenVPN connections must be hosted on AWS Route 53.

Start by launching Access Server on nodes in two different global locations. You can launch with our pre-built images in AWS or with a basic Linux instance where you install Access Server.

Launch with our pre-built guide: Amazon Web Services EC2 BYOL Appliance Quick Start Guide.
Create a basic Linux instance using your preferred distribution, then manually install Access Server packages using our software repository: Installation and Setup.

Ensure that you launch Access Server on a node in each region. For our example, we deployed a node in North Virginia (us-east-1) and the second node in Frankfurt (eu-central-1).

Next, configure both nodes as an Access Server cluster. In a cluster, both Access Servers share users, configuration, and certificates databases on a database server — and you can manage them all from a single web UI.

Set up and configure your cluster: Setting up an Access Server cluster.

Next, configure Route 53 to route incoming OpenVPN connections to the nearest cluster node. This configuration requires two A records on Route 53 pointed to the elastic IP addresses of each Access Server node and defined with the routing policy and data center where the node is located.

Create a record for the first node⁠

Sign in to your AWS console.
Click Services > Networking & Content Deliver > Route 53.
Click Hosted Zones and select your DNS zone.

Create a new record for the first node in the Frankfurt region:

Record name	The same name you use for RRDNS hostname in cluster settings (‘openvpn’ in our example).
Record type	A
Value	This is the elastic IP address assigned to the Frankfurt node.
TTL	We recommend 60 seconds. Keep it as low as possible if you want to use failover. If you don’t use failover, you can set a higher value to decrease the count of DNS requests (and lower the cost of the Route 53 service).
Routing policy	Latency
Region	Select the region where the node is deployed (‘eu-central-1’ in our example).
Record ID	Enter a value uniquely identifying each record with the same name and type. For example, you might assign a date/time stamp or a sequential counter.

Create a record for the second node⁠

Click Add another record.
Enter the necessary information for the second node.
Click Create records and save changes.

Verify the new records⁠

Review the details for the records in the hosted zone for accuracy.

Next, test the smart or latency-based routing to each node using the commands below. The test consists of pinging the IP addresses of the nodes to determine which one is closer, and then pinging the hostname to verify that it resolves to the IP address of the closer node. We recommend running this test from a computer that is connected to the cluster via OpenVPN Connect.

Ping the elastic IP addresses of both nodes:

ping 198.51.100.18 -c 2
ping 203.0.113.54 -c 2

You should see results similar to these:

bash-3.2$ ping 203.0.113.54 -c 2
PING 203.0.113.54 (203.0.113.54): 56 data bytes
64 bytes from 203.0.113.54: icmp_seq=0 ttl=236 time=117.304 ms
64 bytes from 203.0.113.54: icmp_seq=1 ttl=236 time=117.971 ms

--- 203.0.113.54 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 117.304/117.638/117.971/0.333 ms
bash-3.2$
bash-3.2$
bash-3.2$ ping 198.51.100.18 -c 2
PING 198.51.100.18 (198.51.100.18): 56 data bytes
64 bytes from 198.51.100.18: icmp_seq=0 ttl=231 time=29.210 ms
64 bytes from 198.51.100.18: icmp_seq=1 ttl=231 time=30.567 ms

--- 198.51.100.18 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 29.210/29.889/30.567/0.679 ms
bash-3.2$

In the results above, the node with IP 198.51.100.18 is ‘closer’ than the node with IP 203.0.113.54.
Ping the cluster hostname:
```
ping openvpn.companyname.com -c 2
```
The hostname should resolve to the IP address of the closest node.

Ensure you have the hostname defined for the cluster⁠

During the configuration steps for setting up your cluster of Access Servers, you could define a cluster round-robin DNS hostname. If you didn’t do this at the time, ensure that it is defined for the cluster:

Sign in to the Admin Web UI for your cluster.
Click Configuration > Cluster.
Enter the hostname in the field Define a cluster round-robin DNS host name.

Connect to the VPN cluster with the client app⁠

Sign in to the Client Web UI with a valid user by entering the hostname in your browser, followed by a username and password.
Note
Do not include /admin in the URL, as that takes you to the Admin Web UI.
Download an OpenVPN Connect app or a connection profile and import it into OpenVPN Connect.
Establish a connection using the newly downloaded app or newly imported profile.

Check which node the client connects to⁠

Depending on your configuration, you can check which node your VPN connection communicates with one of two ways.

If you route all traffic via a VPN tunnel, use an online service to find your public IP address:

If you use a split-tunnel configuration, extract the node IP address from the log file in OpenVPN Connect:

Open the OpenVPN Connect app.
Click the log file icon (<>).

Scroll through the log file and check the connection event:

DD/MM/YYYY, 16:25:01 EVENT: CONNECTED openvpn@openvpn.companyname.com:1194 (**198.51.100.18**) via /UDPv4 on utun12/10.100.100.131/ gw=[10.100.100.129/]
2DD/MM/YYYY, 16:25:01 Connected via utun12

The IP address from the online service or the log file should be the IP address of the closest node.

Adding a health check for each node is an optional step in Route 53 that allows forwarding OpenVPN connections to another node if the closest one is offline. In our example, we configure health checks to verify that Access Server accepts connections on port TCP 443.

Sign in to the AWS console.
Click Services > Networking & Content Deliver > Route 53.
Click Health checks in the sidebar and click Create health check.
Configure health check for the first node:
- Name: e.g. EU-node
- What to monitor: Endpoint
- Specify endpoint by: IP address
- Protocol: TCP
- IP address: elastic IP of Frankfurt node
- Port: 443
Click Next and click Create health check.
Repeat the steps above to create a health check for the second node.
Click Hosted Zones on the sidebar and select your DNS zone.
Click the record that points to the Frankfurt node and click Edit record.
Select the new health check from the Health check - optional dropdown.
Click Save.
Repeat the steps above to assign the second health check to the record for the North Virginia node.

Test DNS failover⁠

You can test the health check works by manually stopping the openvpnas service, checking the health check in AWS, and pinging the cluster hostname.

Stop openvpnas service on the closet cluster node:

sudo su
systemctl stop openvpnas

Verify the health check:

Sign in to the AWS console.
Click Health checks on in the sidebar.
Wait for the health check for the closest node to change to "unhealthy."

Ping the cluster hostname:

ping openvpn.companyname.com -c 2

You should see the hostname resolved to the closest node.

You can set your users to authenticate against a directory service using LDAP, RADIUS, or SAML. The following documentation provides the configuration that suits your needs.

LDAP:⁠

RADIUS:⁠

SAML:⁠

Conclusion⁠

Configuring a cluster of Access Servers using Amazon’s Route 53 provides convenient smart routing for your VPN clients. You improve your end user’s experience, basically improving the entire customer experience for VPN clients by connecting them with the closest VPN server. This optimization gives your users, no matter where they connect in the world, one simple URL for connections. And in the backend, Route 53 manages the automation of connections to the nearest server to cut down latency. This gives you full control of a smart routing solution for Access Server.

Can't find what you're looking for?

Our support team will be happy to assist you.

Contact Support Schedule a Demo