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 2You 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 2The 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 VPN Server.
The Network Settings tab displays.
Click the Edit Cluster tab.
Enter the hostname in the field Cluster round-robin DNS hostname.
Click Save and Restart.
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.
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 openvpnasVerify 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 2You should see the hostname resolved to the closest node.