How does DNS work with my AWS Client VPN endpoint?

Resolution

Note: If you receive errors when you run AWS Command Line Interface (AWS CLI) commands, then see Troubleshooting errors for the AWS CLI. Also, 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 operation to specify the IP addresses in the "DNS Server IP address" parameter. Use the console, the modify-client-vpn-endpoint command, or the ModifyClientVpnEndpoint API operation to change an existing endpoint.

Configure the "DNS Server IP address" parameter

For high availability, specify two DNS server IP addresses. If the primary DNS server is unreachable, the client attempts to resend 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, consider the following:

• You can resolve the resource records of the Route 53 private hosted zone that's associated with the Amazon Virtual Private Cloud (Amazon 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 Amazon VPC interface endpoint.
• Confirm that DNS Resolution and DNS Hostnames are activated for the associated Amazon VPC.

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

DNS behavior by tunnel type

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: The client adds a route for all traffic through the VPN tunnel. All traffic, including DNS queries, is routed through the tunnel. If the Amazon VPC doesn’t have a route to the DNS servers, lookups fail.
• Split-tunnel: The client adds only routes from the Client VPN route table. To route DNS traffic through the VPN, add a route for the DNS server IP addresses to the Client VPN route table.

The following examples apply to both Windows and Linux environments. On Linux, the examples assume that the client uses a generic network manager.

Scenario 1: Full-tunnel with no DNS server IP addresses specified

Example 1:

• End user client's IPv4 CIDR: 192.168.0.0/16
• 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 and no DNS server IP addresses are specified

Because the DNS server IP address parameter isn’t configured, the end user's host machine uses the local DNS server to resolve domain names.

This Client VPN endpoint is configured in full-tunnel mode. To send all traffic over the VPN (0/1 from utun1), the client adds a route that points to the virtual adapter. However, DNS traffic isn’t sent over the VPN because the endpoint doesn’t push DNS server configuration. Instead, the client uses the static route for the local DNS server address (192.168.1.1/32 over en0). After the domain name is resolved locally, the application traffic to the resolved IP address travels through the VPN tunnel.

$ 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:

• End user client's IPv4 CIDR: 192.168.0.0/16
• Client VPN endpoint VPC's CIDR: 10.123.0.0/16
• Local DNS server is configured as a public IP (8.8.8.8)
• The DNS Server IP address parameter is turned off and no DNS server IP addresses are specified

In this example, the client uses the public DNS server at 8.8.8.8. Because there’s no static route for 8.8.8.8 over en0, the DNS request travels through the VPN tunnel. If the Client VPN endpoint doesn't have internet access, the DNS server is unreachable, and the query times 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

• Client's IPv4 CIDR: 192.168.0.0/16
• Client VPN endpoint's Amazon VPC CIDR: 10.123.0.0/16
• DNS Server IP address parameter is turned on, and set to 10.10.1.228 and 10.10.0.43 (Route 53 Resolver's inbound endpoints)
• Resolver endpoints are in an Amazon VPC (10.10.0.0/16) that is connected from a transit gateway
• The Amazon VPC has Route 53 private hosted zone (example.local)
• DNS resolution and DNS hostnames are active

This Client VPN is configured in split-tunnel mode. The Client VPN route table contains:

$ 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. The DNS request is then forwarded to the Route 53 Resolver inbound endpoint over a transit gateway. After the domain name is resolved to an IP address, the application traffic also travels through the VPN tunnel. This flow continues as long as the resolved destination IP address matches a route in the Client VPN endpoint route table.

With this configuration, end users can resolve external domain names using standard DNS resolution. It also allows resolution of records in private hosted zones that are associated with the Amazon VPC containing the Route 53 Resolver inbound endpoints.

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