Smart Routing with Access Server Clustering and AWS Route 53

Upgrade to Latest Version

Introduction

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. A configuration such as this 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 Virginia203.0.113.54
Access Server node in Frankfurt198.51.100.18
Route 53 hosted zonecompanyname.com
Round-robin DNS hostnameopenvpn.companyname.com

Requirements:

  • Both OpenVPN 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.

1. Deploy OpenVPN Access Server Nodes in AWS Regions

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

Ensure that you launch OpenVPN 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).

2. Configure an OpenVPN Access Server Cluster

Next, configure both nodes as an OpenVPN 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.

Note about database instance placement: We recommend one of two options for choosing the region to deploy your RDS MySQL DB instance for the cluster setup:

  1. Use the same region where you deployed one of your cluster nodes, selecting the node where you expect the most connections.
  2. 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.

3. Configure DNS Records in AWS Console

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 datacenter where the node is located.

Create a record for the first node:

  1. Sign in to your AWS console.
  2. Click Services > Networking & Content Delivery > Route 53.
  3. Click Hosted Zones and select your DNS zone.
  4. Create a new record for the first node in the Frankfurt region.
Record nameThe same as is used for RRDNS hostname in cluster settings (‘openvpn’ in our example).
Record typeA
ValueThis is the elastic IP address assigned to the Frankfurt node.
TTLWe 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 policyLatency
RegionSelect the region where the node is deployed (‘eu-central-1’ in our example).
Record IDEnter a value that uniquely identifies 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:

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

Verify the new records

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

smart routing with AWS route 53

4. Test Smart Routing

Next, test the smart routing — or latency-based routing — to each node using the following commands. 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.

Note: 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.

5. Test OpenVPN Access Server Connection

Ensure you have the hostname defined for the cluster

During the configuration steps for setting up your cluster of Access Servers, you had the option to 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:

  1. Sign in to the Admin Web UI for your cluster.
  2. Click Configuration > Cluster.
  3. Enter the hostname in the field Define a cluster round-robin DNS host name.
  4. Click Save Settings and Update Running Server.

Connect to VPN cluster with client app

  1. Sign in to the client 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.)
  2. Download an OpenVPN Connect app or a connection profile and import it into OpenVPN Connect.
  3. Establish connection using the newly downloaded app or newly imported profile.

Check which node the client connects to

You can check which node your VPN connection communicates with one of two ways, depending on your configuration. Note: Perform this test on a machine with OpenVPN Connect app 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 in OpenVPN Connect:

  1. Click the Log File icon (<>).
  2. 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 either the online service or the log file should be the IP address of the closest node.

6. Configure node health check in Route 53 for failover purposes (optional)

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.

  1. Sign in to the AWS console.
  2. Click Services > Networking & Content Delivery > Route 53.
  3. Click Health checks in the sidebar and click Create health check.
  4. 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
  5. Repeat the steps above to create a health check for the second node.
  6. Click Hosted Zones on the sidebar and select your DNS zone.
  7. Click the record that points to the Frankfurt node and click Edit record.
  8. Select the new health check from the Health check - optional dropdown.
  9. Click Save.
  10. 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:

  1. Sign in to the AWS console.
  2. Click Health checks on in the sidebar.
  3. 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 resolve to the second node.

Restart the openvpnas service on the closest cluster mode:

sudo su
service openvpnas start

Verify the health check again:

  1. Sign in to AWS console.
  2. Click Health checks on in the sidebar.
  3. Wait for the health check for the closest node to change to “healthy”.

Ping the cluster hostname:

ping openvpn.companyname.com -c 2

You should see the hostname resolved to the closest node.

Important note: 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. We recommend setting the DNS TTL as low as possible for this reason.

(Optional) Connect with a directory service using LDAP or RADIUS

You can set your users to authenticate against a directory service using LDAP or RADIUS. Refer to the following documentation for the configuration that suits your needs:

LDAP:

RADIUS:

Conclusion

Configuring a cluster of OpenVPN 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 OpenVPN Access Server.

Additional resources