AWS Client VPN Intermittent Access: Audit Each Associated Subnet

A user connects, opens the internal app and gets an answer; a colleague on the same endpoint gets a timeout from an identical laptop on the same Wi-Fi. That pattern is the signature of a client VPN endpoint with more than one associated subnet, where the paths are not equivalent. I walk this from the console outwards, because two tabs decide whether the rest of the investigation is worth doing. Nothing in the client configuration explains it.

Start at the endpoint and list the associations

In the VPC console, open Client VPN endpoints, pick the endpoint and read the Associations tab. Each association is a subnet in an Availability Zone, and a client lands on whichever one the service picks when the connection is built. Note the subnet IDs and the route table each one actually uses, because those two lists are the comparison you are about to make.

If the endpoint shows a single association, this theory is wrong and the client is the better suspect.

Compare the endpoint route table with every association

Open the Route table tab on the same endpoint. Every destination CIDR there has a target, and for a client VPN the target is an association rather than a gateway. AWS requires a destination entry for each associated subnet, so a route that targets only one of them makes access depend on where the session landed. Check the destination you actually care about, then check its authorization rule, since a route supplies the path and a rule decides who may use it.

Once you tabulate both layers, the failure is hard to miss.

Row two is the whole bug in most tickets. The endpoint route is present, so nobody looks further, and the packet dies one hop later inside the VPC.

Follow each subnet into its effective route table

A subnet with no explicit route table association inherits the VPC main table. Read the table that is actually in effect, not the one whose name looks right, and compare destination and target rather than the label on the row.

The AWS intermittent access guide frames this as route coverage across associations, which is the right model. The endpoint gets the packet to a subnet, and that subnet's table still has to know where the application network lives.

Fix the missing row in the table that owns it. Copying an entire route table from a working subnet also copies internet, appliance and isolation choices that were never meant for this one, and that trade is usually worse than the outage you started with.

Check authorization rules, then the path back

Authorization rules are per destination and per group, evaluated separately from routes. A destination with routes everywhere but no rule for the user's group behaves like a black hole with a healthy-looking route table.

The return path deserves the same attention. A peering connection needs a route in the application VPC pointing back at the client CIDR, security group rules that allow the traffic at both ends, and network ACLs that do not drop it. One-way reachability, where ping works and the TCP handshake does not, usually points at an ACL or a security group rather than at the VPN.

The endpoint's own security groups sit on the association elastic network interfaces, so a rule that allows the application port from the client CIDR has to be attached to the association, not only to the instance.

Verify with a reconnect, not one lucky request

With split tunnel, endpoint routes are pushed when the connection is established, so a changed route set never reaches a client that stays connected. Disconnect and reconnect through the supported client, then confirm the new routes are present on the machine.

Finally, correlate the connection log with the address the client received, and repeat the test enough times to hit more than one association. A single successful request after a fix proves that one path works, and the ticket was about the other one.