Tutorial: Smart Routing with Access Server Clustering and AWS Route 53
Steps for setting up smart routing for VPN clients connecting to a cluster of Access Server nodes through Amazon's Route 53 DNS routing.
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 to minimize latency. With our configuration example, we launch an OpenVPN 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: Installing Access Server on a Linux system.
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.
Tip
We recommend one of two options for choosing the region to deploy your RDS MySQL DB instance for the cluster setup:
Use the same region where you deployed one of your cluster nodes, selecting the node where you expect the most connections.
Use a region somewhere in-between your two cluster node regions, such as choosing London or Dublin for a location in between North Virginia and Frankfurt.
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 OpenVPN 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 see which is closer, then pinging the hostname to check that it resolves to the IP address of the closer node. We recommend running this test from a computer that will connect with OpenVPN Connect to the cluster.
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.
Important
Testing with the ping tool requires an additional rule to allow ICMP requests and replies. Ensure you’ve adjusted Security Groups to perform this test.
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 host name. 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 VPN cluster with client app
Note
Do not include /admin in the URL, as that takes you to the Admin Web UI.
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.
Important
Perform this test on a machine with OpenVPN Connect installed and a profile to connect to the Access Server cluster.
If you route all traffic via a VPN tunnel, use an online service to find your public IP address:
If you use 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 to forward 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 TCP443.
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 service openvpnas stop
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.
Important
DNS-based failover can cause a delay between marking a node unhealthy and resolving the cluster hostname to a different IP address because of DNS caching on servers between the VPN client and Route 53. For this reason, we recommend setting the DNS TTL as low as possible.
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.