Skip to content

Client VPN returns NXDOMAIN with All Users Unable to Connect

2

We are experiencing a complete outage of our AWS Client VPN endpoint. All users are unable to connect, and the AWS VPN Client shows "Waiting for identity..." indefinitely.

The endpoint ID is cvpn-endpoint-0a1b2c3d4e5f67890 in eu-central-1. It uses SAML-based federated authentication with our corporate IdP.

I've verified the following:

  • Endpoint status is "Available" in the console
  • Server certificate (ACM) is in ISSUED status and not expired
  • Both subnet associations are active
  • Security groups and authorization rules are correctly configured
  • No recent changes were made to the endpoint configuration

When I try to resolve the endpoint DNS name, I get NXDOMAIN:

$ nslookup test.cvpn-endpoint-0a1b2c3d4e5f67890.prod.clientvpn.eu-central-1.amazonaws.com
Server:     10.136.129.42
Address:    10.136.129.42#53

** server can't find test.cvpn-endpoint-0a1b2c3d4e5f67890.prod.clientvpn.eu-central-1.amazonaws.com: NXDOMAIN

The OpenVPN client logs show repeated DNS resolution failures:

RESOLVE: Cannot resolve host address: e56a1cbe1286.cvpn-endpoint-0a1b2c3d4e5f67890.prod.clientvpn.eu-central-1.amazonaws.com:443 (No such host is known.)

This is affecting all users. The endpoint was working fine until a few days ago and everything looks correctly configured. Has anyone seen this before?

2 Answers
2
Accepted Answer

Hi Racer,

This is caused by an expired SAML Identity Provider (IdP) certificate. When the SAML signing certificate in your IdP metadata expires, the Client VPN service removes the DNS records for the endpoint, resulting in NXDOMAIN responses for all connection attempts.

This behaviour is not intuitive. You would expect an authentication failure at the login step, not a DNS-level failure. However, the Client VPN service treats an expired IdP certificate as a reason to withdraw the endpoint from DNS entirely, which causes a complete outage rather than a targeted authentication error.

How to confirm:

Check the IdpCertDaysToExpiry CloudWatch metric for your endpoint:

  • Namespace: AWS/ClientVPN
  • Metric: IdpCertDaysToExpiry
  • Dimension: Endpoint = your-endpoint-id

If the value is 0, your SAML IdP certificate has expired and this is your root cause.

Resolution:

  1. Renew the SAML signing certificate on your Identity Provider (Okta, Azure AD, OneLogin, PingFederate, etc.) for the application associated with this Client VPN endpoint

  2. Download the updated IdP metadata XML file from your IdP

  3. Update the IAM SAML Identity Provider in AWS with the new metadata:

aws iam update-saml-provider \
  --saml-provider-arn arn:aws:iam::<ACCOUNT_ID>:saml-provider/<PROVIDER_NAME> \
  --saml-metadata-document file://new-metadata.xml
  1. Disassociate and re-associate the target subnets on the Client VPN endpoint to force DNS re-provisioning. IMPORTANT: document all existing routes in your Client VPN route table before disassociation, as they will be removed and must be manually recreated after re-association.

  2. Recreate all routes that were removed during the disassociation

  3. Verify DNS resolution is restored:

nslookup test.cvpn-endpoint-0a1b2c3d4e5f67890.prod.clientvpn.eu-central-1.amazonaws.com

Prevention:

Set up a CloudWatch alarm on the IdpCertDaysToExpiry metric with a threshold of 30 days to receive advance notification before the certificate expires.

Differential diagnosis:

If IdpCertDaysToExpiry is not 0, other causes of NXDOMAIN on a Client VPN endpoint include:

  • No subnet associations (all subnets disassociated)
  • Expired ACM server certificate
  • Endpoint recently created (wait 5-10 minutes for DNS provisioning)
  • Endpoint deleted

References:

AWS
SUPPORT ENGINEER

answered a month ago

EXPERT

reviewed a month ago

EXPERT

reviewed a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.