AWS Client VPN endpoint DNS: why pinning the resolved IP fails

Last week dig +short gave you one address for the endpoint name in your AWS Client VPN profile, and the tunnel connected. This week the same profile sits at "Connecting" on your laptop while a colleague's untouched copy still works. Nothing was blocked and the certificate did not expire. Someone replaced the endpoint hostname with that resolved address, and the service no longer answers there. The exported name is the part built to survive that change.

The name in your profile may not be the name being queried

Profiles exported from Client VPN commonly carry remote-random-hostname. With that option on, the client builds a throwaway label, joins it to the endpoint name with a dot, and resolves the combined name. A wildcard record on the endpoint's zone answers any label, which is why an invented prefix still resolves and why the trick stays invisible when you try to reproduce the query by hand.

So when you paste the endpoint name into a terminal and get an answer, you have resolved a different name from the one the client uses at connect time. That mismatch is not a defect to correct in the profile. The label is regenerated on purpose: the option keeps caches from holding a stale answer, and it never identifies your machine or your session.

I have hit the compatibility case where a client ignores the option outright. AWS documents the workaround: keep the real endpoint name and prepend a random string plus a dot, treating it as a naming pattern rather than a value to paste. Applying that to an old client is reasonable; hard-coding the prefixed string as the endpoint is not.

Why a saved answer cannot stay correct

Client VPN endpoint addresses are managed by AWS and change over time, which the best-practices documentation states plainly. A captured answer is a snapshot of one resolution. A profile that hard-codes it becomes a profile aimed at a decommissioned host as soon as the service moves, and the failure rarely looks like DNS: you get a connect timeout or a stalled handshake, so people chase routing and certificates.

The same answer in /etc/hosts inherits the same expiry with an extra problem attached. A hosts entry survives reboots, re-exports and "reinstall the client" fixes, so the failure returns every time the address moves. I have watched one sit harmless for weeks, then take out every machine carrying it while fresh installs connected normally. That split, one group failing and another group fine on the same account, is the cheapest clue you will get.

Scope the randomization correctly too. It happens per connection attempt. An established tunnel does not re-resolve its endpoint, does not switch servers mid-session, and individual application requests do not each pick a new VPN host. Only the next attempt resolves again, which is why a session that works all afternoon says nothing about tomorrow morning.

What the service checks when the tunnel comes up

Client VPN requires the address you are connected to to match an address resolved for the endpoint's DNS name. That one requirement explains several failures that look unrelated: a custom DNS record pointing somewhere else, a custom frontend that forwards to the real endpoint address, and a profile rewritten to a raw address. AWS documents the custom-record-plus-forwarding arrangement as a failure with recent AWS-provided clients. The check is narrow; it is not a ruling that every alias is forbidden.

It is not a general rule about VPN protocols either. A numeric remote is perfectly valid in an ordinary OpenVPN deployment, and plenty of them run that way. The constraint comes from the managed arrangement, not from the protocol underneath it.

Which makes relaxing certificate verification the wrong reflex. If a profile fails after an address swap, disabling server verification moves the error instead of fixing resolution or the address-match requirement, and leaves a client that will trust anything. Keep the exported CA, server verification and mutual-auth settings exactly as they came.

Allowlists, egress, and private DNS are three separate problems

A firewall rule that must permit a destination before a laptop connects is about the outer listener. Give the network owner the endpoint name, the transport and the configured port, then ask whether their control can follow the service's DNS behavior. A rule holding one captured address is a snapshot with an unwritten expiry. If the control only accepts immutable destinations, settle that gap before rollout rather than quietly hard-coding an answer.

A partner who needs a fixed source address for requests made after the tunnel is up has a different requirement: egress. What a website observes depends on the application route and the split-tunnel policy, not on the address the client connected to. Split-tunneled traffic may never touch AWS at all.

Private DNS inside the tunnel is a third layer. The resolver handed to clients answers internal names after connection; it cannot resolve the public endpoint before the tunnel exists. Endpoint resolution failure and internal application resolution failure happen at different stages, and mixing them sends you to the wrong log.

Address family belongs in the same list. An IPv4 answer says nothing about an IPv6 or dual-stack endpoint's permitted path, so a snapshot taken in one family is not evidence for the other.

Check a connection without pinning anything

Start from the profile as exported and read what it actually asks for:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Then compare three things: the endpoint name the profile holds, the address the client reports for a fresh attempt, and what the name resolves to right now. A name that resolves proves only that the record answers; transport and authentication are separate, and the endpoint need not reply to a ping. The client's own log is the only source for the middle item, so capture it during the attempt rather than afterwards.

An address that answers today is evidence about today; the name is the thing the service keeps valid. Record the observation, send it to whoever owns the endpoint, and leave the profile pointing at the name.

Two habits to drop: disabling certificate checks to get past a stalled handshake, and stacking labels in front of the endpoint name hoping one sticks. A label resolves through the wildcard record or the problem is elsewhere. If a correctly configured profile still fails, send the exact query and the connection event, not a longer hostname.

Before you close it out: the profile still carries the exported endpoint name, no hosts file pins the address, the client log's remote matches a current resolution, and the firewall rule names the endpoint rather than an address. That is also the state to hand to the next person.