How does DNS work with my AWS Client VPN endpoint?

Resolution

Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you're using the most recent AWS CLI version.

When you create a new Client VPN endpoint, specify a DNS server IP address. Use the AWS Management Console, create-client-vpn-endpoint AWS CLI command, or CreateClientVpnEndpoint API to specify the IP addresses in the "DNS Server IP address" parameter. Or, modify an existing Client VPN endpoint. Use the AWS Management Console, modify-client-vpn-endpoint AWS CLI command, or the ModifyClientVpnEndpoint API to modify the "DNS Server IP address."

Configure the "DNS Server IP address" parameter

For high availability, it's a best practice to specify two DNS servers. If the primary DNS server becomes unreachable, then the end user device resends the query to the secondary DNS server.

Note: If the primary DNS server responds with SERVFAIL, then the DNS request isn't sent again to the secondary DNS server.

Confirm that end users can reach both of the specified DNS servers after the end users connect to the Client VPN endpoint. If the DNS servers are unreachable, then DNS requests might fail and cause connectivity issues.

The "DNS Server IP address" parameter is optional. If no DNS server is specified, then the DNS IP address that's configured on the end user's device is used to resolve DNS queries.

If your Client VPN DNS server is the AmazonProvidedDNS or the Amazon Route 53 Resolver inbound endpoint, then follow these guidelines:

• You can resolve the resource records of the Route 53 private hosted zone that's associated with the virtual private cloud (VPC).
• If "Private DNS" is activated, then Amazon RDS public hostnames that are accessible from the VPN interface appointment resolve to a private IP address. This is also true for AWS service endpoint names that are accessible from the VPC interface endpoint.
  Note: Be sure that "DNS Resolution" and "DNS Hostnames" are activated for the associated VPC.

The Client VPN endpoint uses the source NAT to connect to resources in the associated VPCs.

After the client device establishes the Client VPN tunnel, the "DNS Server IP address" parameter is applied to the full-tunnel or split-tunnel:

• Full-tunnel: After the client device establishes the tunnel, a route for all traffic through the VPN tunnel is added to the end user device's route table. Then, all traffic, including DNS traffic, is routed through the Client VPN tunnel. If the associated VPC doesn't have a route to reach the DNS servers, then the lookup fails.
• Split-tunnel: When the Client VPN tunnel is created, the routes in the Client VPN route table are added to the end user device's route table. If you can reach the DNS server through the associated VPC, then add the DNS server IP addresses' route in the Client VPN route table.

The following examples demonstrate DNS in common scenarios. They apply to both Windows and Linux environments. In a Linux environment, the examples function as described only when the end user's host machine uses the generic networking setting.

Scenario 1: Full-tunnel with the "DNS Server IP address" parameter turned off

Example 1 configuration:

• The end user client's IPv4 CIDR = 192.168.0.0/16.
• The Client VPN endpoint VPC's CIDR = 10.123.0.0/16.
• Local DNS server IP address = 192.168.1.1.
• The "DNS Server IP address" parameter is turned off. No DNS server IP addresses are specified.

Because the "DNS Server IP address" parameter is turned off, the end user's host machine uses the local DNS server to resolve DNS queries.

This Client VPN is configured in full-tunnel mode. To send all traffic over the VPN (destination 0/1 over utun1), a route that points to the virtual adapter is added. However, DNS traffic still doesn't travel over the VPN because the "DNS Server IP address" parameter isn't configured. DNS traffic between the client and the DNS server remains local. The client machine already has a preferred static route to the local DNS server address (dest. 192.168.1.1/32 over en0) to reach the DNS resolver. After the domain name is resolved to the respective IP address, the application traffic to the resolved IP address travels over the VPN tunnel.

Example snippet:

$ cat /etc/resolv.conf | grep nameservernameserver 192.168.1.1

$ netstat -nr -f inet | grep -E 'utun1|192.168.1.1'0/1                192.168.0.1        UGSc           16        0   utun1
192.168.1.1/32     link#4             UCS             1        0     en0
(...)

$ dig amazon.com;; ANSWER SECTION:
amazon.com.        32    IN    A    176.32.98.166
;; SERVER: 192.168.1.1#53(192.168.1.1)
(...)

Example 2 configuration:

• The end user client's IPv4 CIDR = 192.168.0.0/16.
• The Client VPN endpoint VPC's CIDR = 10.123.0.0/16.
• The local DNS server IP address is set to public IP = 8.8.8.8.
• The "DNS Server IP address" parameter is turned off. No DNS server IP addresses are specified.

In this example, instead of using the local DNS server at 198.168.1.1. the client uses the public DNS address at 8.8.8.8. Because there's no static route for 8.8.8.8 over en0, this traffic travels over the Client VPN tunnel. If the Client VPN endpoint isn't configured to access the internet, then the public DNS at 8.8.8.8 is unreachable. Then, the request queries time out.

$ cat /etc/resolv.conf | grep nameservernameserver 8.8.8.8

$ netstat -nr -f inet | grep -E 'utun1|8.8.8.8'0/1                192.168.0.1      UGSc            5        0   utun1

$ dig amazon.com(...)
;; connection timed out; no servers could be reached

Scenario 2: Split-tunnel with the "DNS Server IP address" parameter activated

Example configuration:

• The end user client's IPv4 CIDR = 192.168.0.0/16.
• The Client VPN endpoint's VPC CIDR = 10.123.0.0/16.
• The "DNS Server IP address" parameter is turned on, and set to 10.10.1.228 and 10.10.0.43. These IP addresses represent the IP addresses of the Route 53 Resolver's inbound endpoints that are in another VPC (10.10.0.0/16). The IP addresses connect to the Client VPN endpoints that are associated VPC with a transit gateway.
• The associated VPC has "DNS Hostnames" and "DNS Support" turned on, and has an associated Route 53 private hosted zone (example.local).

This Client VPN is configured in split-tunnel mode. The routes in the Client VPN route table are added to the end user's host machine route table:

$ netstat -nr -f inet | grep utun1(...)
10.10/16           192.168.0.1        UGSc            2        0   utun1 # Route 53 Resolver inbound endpoints VPC CIDR
10.123/16          192.168.0.1        UGSc            0        0   utun1 # Client VPN VPC CIDR
(...)

In this example, the "DNS Server IP address" parameter is activated. 10.10.1.228 and 10.10.0.43 are configured as the DNS servers. When the client establishes the VPN tunnel, the DNS server parameters are pushed to the end user's host machine.

$ cat /etc/resolv.conf | grep nameservernameserver 10.10.1.228 # Primary DNS server 
nameserver 10.10.0.43 # Secondary DNS server

The client machine issues a DNS query that travels over the VPN tunnel to the Client VPN VPC. Next, the DNS request is forwarded to the Route 53 Resolver endpoint over a transit gateway. After the domain is resolved to an IP address, application traffic also travels over the established VPN tunnel. This occurs as long as the resolved destination IP address matches a route from the Client VPN endpoint route table.

With this configuration, end users can resolve external domain names that use standard DNS resolution. This configuration also resolves records from private hosted zones that are associated with the Route 53 Resolver VPC. It also resolves interface endpoint DNS names and EC2 public DNS hostnames.

$ dig amazon.com;; ANSWER SECTION:
amazon.com.        8    IN    A    176.32.103.205
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig test.example.local # Route 53 private hosted zone record ;; ANSWER SECTION:
test.example.local. 10 IN A 10.123.2.1
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig ec2.ap-southeast-2.amazonaws.com # VPC interface endpoint to EC2 service in Route 53 Resolver VPC;; ANSWER SECTION:
ec2.ap-southeast-2.amazonaws.com. 60 IN    A    10.10.0.33
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com # EC2 instance public DNS hostname running in Route 53 Resolver VPC;; ANSWER SECTION:
ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com. 20 IN A 10.10.1.11
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)