Why EC2 Cannot Reach Your AWS Client VPN Laptop
Client VPN translates IPv4 client sources to the endpoint interface. That is why the reply works and a fresh connection from EC2 does not.
A laptop connected through AWS Client VPN reaches an EC2 application without trouble. Then you try the reverse, from EC2 to the address the client was assigned, and it hangs or refuses. That asymmetry is rarely a missing security group rule. On a Client VPN endpoint associated with VPC subnets, AWS translates IPv4 client sources to the endpoint's network interface, so there is no inbound VPC address that represents your laptop.
Start with what the capture shows
Take a capture on the EC2 host while the client connects, and read the source address the application actually sees. If it is the VPC-side endpoint interface rather than an address from the client pool, translation is confirmed before you change a single rule.
The client pool is an allocation range, not a subnet with a return route. That distinction is where most of these investigations go wrong.
The translation that explains the asymmetry
Three flows get confused with each other, and only one of them is the one people test.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
The Client VPN component description spells out that IPv4 client sources are translated to the endpoint interface, which is enough to see why the middle row has nothing to match.
A new connection needs a route, an address resolution step and an authorisation decision. Translation state from someone else's session supplies none of the three.
Why a reply is not a new connection
A TCP reply is matched against an existing entry, which is why the return path works with no inbound rule at all. A fresh SYN from the EC2 host has no entry to match, so it becomes an ordinary outbound attempt to a destination the VPC does not know how to reach.
That is also why describing this as traffic going only one way is misleading. Return traffic flows continuously in these sessions. Initiation is the part without a path.
What still breaks a session that should work
Security groups, network ACLs and the laptop's own firewall all matter for the connections that are supposed to succeed. A failed ping tells you the least, because ICMP policy is frequently separate from the TCP policy you care about.
Write those rules against the translated source, not the client address. Rules keyed to the address that never appears on the wire are the most common self-inflicted failure in this design.
When the VPC really must start the conversation
If a service has to notify a workstation, invert the direction and let the client hold a persistent outbound channel that the service replies on. If an entire remote network must be reachable from the VPC, choose an architecture that publishes its prefixes and access policy rather than assuming Client VPN already does. Client-to-client access is a third, narrower case with its own route and authorisation objects. None of these is a checkbox on the existing endpoint.
Keep the scope of the IPv4 explanation honest, too. Current AWS documentation separates IPv6, where that translation is not applied, and other attachment models that route differently.
Test in three labelled steps: the client opens a permitted session, the VPC service answers that session, and a VPC host opens a new session toward the client. The first two succeeding while the third fails is the expected shape of this design, not a defect to chase with firewall rules.