Fix AWS Client VPN DNS NXDOMAIN Issue Despite Active State and SAML Auth

Select Language:

If you’re running into issues with your AWS Client VPN that uses federated (SAML) authentication through Microsoft Entra ID (Azure AD), and users report that the VPN client application hangs on “Waiting for identity,” your SAML login window never appears, here’s a step-by-step guide to troubleshoot and resolve the problem.

First, check the client VPN logs on the user’s machine. These logs are located at %APPDATA%\AWSVPNClient\logs\ovpn_aws_vpn_client_YYYYMMDD.log. In many cases, you might see the VPN client looping at DNS resolution, unable to resolve the server’s hostname, with an error similar to “Cannot resolve host address: [random-hex].cvpn-endpoint-EXAMPLE.prod.clientvpn.us-east-2.amazonaws.com:443.” This suggests that the client can’t reach the VPN endpoint due to DNS issues.

Next, verify if DNS is the real culprit. Use tools like Resolve-DnsName or dig to test DNS resolution for the endpoint’s hostname from various resolvers, including public ones like 1.1.1.1 and 8.8.8.8. If these tests return NXDOMAIN, it’s clear that the hostname isn’t publicly published. You can also try resolving inside AWS CloudShell using Python’s socket library. If all tests fail with “Name or service not known” or “NXDOMAIN,” the wildcard DNS record isn’t accessible publicly or within AWS, which is a key clue.

Despite this DNS issue, it’s important to check whether the AWS side considers the endpoint healthy. Use the AWS CLI to describe the client VPN endpoint:

bash
aws ec2 describe-client-vpn-endpoints –client-vpn-endpoint-ids [your-endpoint-id] –region us-east-2 –query ‘ClientVpnEndpoints[0].[Status.Code,Status.Message,DnsName]’

Make sure it shows “available” and confirms the DNS name. Verify subnet associations are also active:

bash
aws ec2 describe-client-vpn-target-networks –client-vpn-endpoint-id [your-endpoint-id] –region us-east-2 –query ‘ClientVpnTargetNetworks[*].[TargetNetworkId,Status.Code]’

If all these look good, and the API reports the endpoint as healthy, but DNS isn’t resolving or the client still hangs, consider the following:

– Reinstall the VPN client, clear the cache at %APPDATA%\AWSVPNClient, and re-import your profile.
– Ensure your default web browser is set correctly (Chrome in this case), and no conflicting VPN or network processes are running.
– Confirm your .ovpn configuration file is current and contains the necessary directives like ‘auth-federate’ and the correct ‘remote’ hostname.
– Try disassociating and then re-associating subnets. Sometimes, the re-association process gets stuck in “associating” for extended periods—this can be a clue pointing to underlying issues.

If after all these steps your endpoint still shows “available,” subnets are correctly associated, but DNS resolution continues to fail, it’s likely the wildcard DNS record isn’t published publicly or within AWS’s environment. This discrepancy prevents the VPN client from resolving the hostname needed for SAML login, causing the hang.

In summary, focus on verifying DNS propagation and accessibility, ensure your VPN setup is correct and current, and confirm AWS endpoint health. Addressing the DNS publishing issue is often the key to resolving the “Waiting for identity” hang.