AWS Client VPN: user connects but can't reach the subnet

Your client says Connected, the certificate is valid, and the intranet page still times out. That gap is almost never authentication. AWS Client VPN authorizes destinations separately from login, and the two usual causes are a group value that does not match what the identity provider sent and a more-specific destination rule that wins over the broad one. Both are visible in the endpoint configuration once you know where to look.

The login succeeded; the rule did not match

Authentication answers who the user is. Authorization rules answer which network prefixes that identity may reach. A user can pass the first and fail the second, and the client gives you little more than a connection that stays up while every request times out.

Start by confirming the endpoint has an authorization rule whose destination contains the failing address. If there is no matching rule, the connection is behaving correctly; the policy is missing.

Where the group value actually comes from

With Active Directory, the access-group field holds the group's SID, not its display name. With SAML federation, it holds the group ID or name that the configured SAML group attribute actually carries. Copy the value from the assertion or the directory lookup, not from a wiki page.

An IAM group is a different control plane. Permission to administer a Client VPN endpoint does not make an IAM group a user's VPN group, and pasting an IAM group name into the access-group field does not translate it into an AD SID or a SAML attribute value.

A similarly named group in another directory proves nothing. Check the endpoint's authentication method and the user's membership or assertion in that same system.

Longest prefix wins, including 0.0.0.0/0

Authorization is evaluated by longest prefix match, and the all-destinations rule is evaluated last rather than first. Add a 10.46.0.0/16 rule for Engineering and a 0.0.0.0/0 rule for everyone, and a user outside Engineering still cannot reach 10.46.20.10 through the broad rule.

This is where a "fix" can go wrong. Deleting the narrow rule restores the user's access and also grants that subnet to every identity covered by the broad rule. Build the group-to-network matrix before you delete anything, and write down which groups are supposed to reach which range. These rules are allow-only; there is no deny entry to carve an exception out of a broad allow.

Changes also need a fresh connection to be judged fairly. Reconnect the client after editing rules, then test again.

Separate authorization from the data path

A rule that matches is not a route. The endpoint needs an associated subnet and a route table entry for the destination, and the target resource's security group must accept the traffic. Return traffic and DNS have to work too.

Test a user who should succeed and a user who should stay excluded. Both can log in while only one reaches the subnet, and that difference is the evidence you want.

If an IP address works but a hostname does not, look at the resolver before touching authorization. If no route covers the address, fix the association or route table. If the packet arrives and the service refuses it, that service's policy is the next stop. Widening the authorization matrix to all users hides which of those layers was actually broken.

Before closing the ticket, record the identity source, the exact group value, the destination prefixes, and the route that carries the traffic. That record turns the next "connected but no access" report into a two-minute comparison instead of another round of guessing.