- Newest
- Most votes
- Most comments
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:
-
Renew the SAML signing certificate on your Identity Provider (Okta, Azure AD, OneLogin, PingFederate, etc.) for the application associated with this Client VPN endpoint
-
Download the updated IdP metadata XML file from your IdP
-
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
-
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.
-
Recreate all routes that were removed during the disassociation
-
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:
Hello.
The following answers may be similar to your situation.
https://repost.aws/questions/QUi9NogiQSRWWDMPgHrFwfOA/client-vpn-endpoint-dns-returns-nxdomain-despite-available-state-and-associated-subnets-saml-federated-auth-waiting-for-identity-forever
Relevant content
asked a year ago
asked a year ago
