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.

You can specify DNS server IP addresses when you create a new Client VPN endpoint. To do this, specify the IP addresses in the "DNS Server IP address" parameter using the AWS Management Console, the AWS CLI, or the API.

You can also modify an existing Client VPN endpoint to specify DNS server IP addresses. To do this, modify the "DNS Server IP address" parameter using the AWS Management Console, AWS CLI, or the API.

Considerations for configuring 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, the end user device resends the query to the secondary DNS server.
  Note: If the primary DNS server responds with "SERVFAIL," the DNS request isn't sent again to the secondary DNS server.
• Confirm that both of the specified DNS servers can be reached by end users after they connect to the Client VPN endpoint. DNS lookups depend on the "DNS Server IP address" parameter. If the DNS servers are unreachable, then DNS requests might fail and cause connectivity problems.
• The "DNS Server IP address" parameter is optional. If there's no DNS server specified, then the DNS IP address configured on the end user's device is used to resolve DNS queries.
• When using AmazonProvidedDNS (or the Route 53 Resolver inbound endpoint) as the Client VPN DNS server:

• You can resolve the resource records of the Amazon Route 53 private hosted zone associated with the VPC.
• The Amazon Relational Database Service (Amazon RDS) public hostnames and AWS service endpoint names that are accessible from the VPC interface endpoint (with "Private DNS" enabled) resolve to a private IP address.
  Note: Be sure that "DNS Resolution" and "DNS Hostnames" are enabled for the associated VPC.

• Remember that 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. It is applied whether it's 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. This causes all traffic (including DNS traffic) to be routed through the Client VPN tunnel. The DNS lookup might fail if the Client VPN's associated VPC (subnet) and the Client VPN route table don't have an appropriate route to reach the configured DNS servers.
• Split-tunnel: When the Client VPN tunnel is established, only the routes present 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 Client VPN's associated VPC, be sure to add a route for the DNS server IP addresses in the Client VPN route table.

Note: The following examples demonstrate how DNS works in a few common scenarios. These examples apply to both Windows and Linux environments. However, in a Linux environment, the examples function as described only if the end user's host machine uses the generic networking setting.

Scenario #1: Full-tunnel with the "DNS Server IP address" parameter disabled

Example 1:

• 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 disabled (there are no DNS server IP addresses specified).

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

This Client VPN is configured in full-tunnel mode. A route pointing to the virtual adapter is added to send all traffic over the VPN (destination 0/1 over utun1). However, DNS traffic still doesn't travel over the VPN, because the "DNS Server IP address" parameter is not 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 IP (dest. 192.168.1.1/32 over en0) to make that the local DNS resolver is reachable. After the domain name is resolved to the respective IP, the application traffic to the resolved IP travels over the VPN tunnel.

Below is a snippet of this example:

$ cat /etc/resolv.conf | grep nameserver
nameserver 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:

• 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 disabled (there are no DNS server IP addresses specified).

In this scenario, rather than using the local DNS server at 198.168.1.1, the client uses a public DNS as their local DNS server IP address (in this example, 8.8.8.8). Because there's no static route for 8.8.8.8 using en0, traffic destined to 8.8.8.8 travels over the Client VPN tunnel. If the Client VPN endpoint isn't configured to access the internet, then the public DNS (8.8.8.8) is unreachable and request queries time out.

$ cat /etc/resolv.conf | grep nameserver
nameserver 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 enabled

In this example:

• 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 enabled 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 present in another VPC (10.10.0.0/16) connected with a transit gateway to the Client VPN endpoint's associated VPC.
• The associated VPC has "DNS Hostnames" and "DNS Support" enabled, 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 route table of the end user's host machine:

$ 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
(...)

Because the "DNS Server IP address" parameter is enabled, and 10.10.1.228 and 10.10.0.43 are configured as the DNS servers, these DNS server parameters are pushed to the end user's host machine when the client establishes the VPN tunnel:

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

A DNS query issued by the client machine travels over the VPN tunnel to the Client VPN VPC. Next, the DNS request is source NATed and forwarded to the Amazon 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 (as long as the resolved destination IP matches a route from the Client VPN endpoint route table).

Using this configuration, end users can resolve:

• External domain names using standard DNS resolution.
• Records from private hosted zones associated with the Route 53 Resolver VPC.
• 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)
(...)