AWS Client VPN DNS: Use the VPC Resolver, Not the Subnet

The endpoint sits in 10.0.8.0/24, so the resolver must be 10.0.8.2. That is the reasoning I hear most often, and it is wrong twice. Route 53 Resolver answers on the primary VPC IPv4 range plus two, which for a VPC of 10.0.0.0/16 is 10.0.0.2 no matter which subnet the endpoint uses. The second error is quieter: putting the right address in the endpoint does not mean the client operating system ever asks it anything. Both mistakes produce the same symptom, name resolution that works for some clients and fails for others.

The myth starts with the subnet association

Association is about where the elastic network interfaces for client connections live, not about which resolver address exists. The endpoint's subnets give clients an address inside the VPC, and they do not each carry a resolver of their own.

Once you separate those two ideas, the arithmetic stops being mysterious and the troubleshooting moves to the client, where most of these cases actually end.

Compute the address from the primary VPC range

Take the VPC's primary IPv4 CIDR and add two to the network address. 10.0.0.0/16 gives 10.0.0.2, 172.31.0.0/16 gives 172.31.0.2, and a VPC with a secondary range keeps the resolver on the primary one. A subnet of 10.0.8.0/24 inside that VPC does not move it. Write the address next to the VPC ID before you touch the endpoint, because the number is a property of the VPC and not of the connection.

The VPC also answers on the link-local address 169.254.169.253. That address is reachable from inside the VPC, but it is not a general-purpose routed destination for a laptop on the other end of a tunnel.

So there are two valid resolver addresses, and neither of them is the subnet plus two.

What the endpoint setting does and does not do

The Client VPN endpoint has DNS server fields, and where the console offers a VPC resolver option it fills in the same idea. Setting them changes what the service hands to clients during connection setup. It does not change what an unmanaged OpenVPN client does with that value, because the client still has to apply it to the operating system. That gap is where "it works on my Mac but not on the Linux box" comes from.

On Linux, the resolver integration is owned by the connection manager rather than by the user. Editing /etc/resolv.conf by hand proves the address works for one session and then vanishes on reconnect, which is why so many fixed cases come back the next morning.

Check the active resolver on the client after connecting, not the endpoint configuration page.

Split tunnelling can defeat a correct resolver

With split tunnelling, only routes pushed into the tunnel are used. If the resolver address is not covered by a route, the query leaves through the local interface and gets answered by your home router instead. The address in the endpoint is still correct and the lookup still fails. Add the route for the resolver, then test again.

Overlapping local ranges produce the same result in a nastier way: the query is answered, just by the wrong server.

Do not open security groups for the Amazon DNS address

The instinct when lookups time out is to add a rule allowing UDP 53 to the resolver address. AWS documents that security groups and network ACLs do not filter Amazon DNS traffic the way they filter traffic to a custom DNS instance. Opening those rules changes nothing for the VPC resolver and widens the boundary for no reason. A resolver you run yourself is a different case and does need its own rules.

If both appear in your design, check which one the client is actually pointed at before you edit any rule.

Verify the path, then measure something else

Resolve a public name, resolve a private name registered in a private hosted zone associated with the VPC, and read the client's active resolver between the two. That sequence separates "the resolver address is wrong" from "the zone is not associated" from "the client ignored the setting". Each has a different fix, and none of them is a throughput problem.

A successful lookup says nothing about sustained transfer speed, so keep those two conversations apart when you report back.