LAN Behind One AWS Client VPN Session: What Forwards

The laptop connects to the AWS Client VPN endpoint, reaches the private subnet, and everything looks healthy. The desktop on the same LAN cannot reach anything, even though the Linux host also has a bridge interface and both machines are on the same wire. Nothing is misconfigured in the tunnel; the missing piece is routing, and the bridge is a red herring.

Extending a Client VPN session to a LAN is a gateway role. It is not an Ethernet segment stretched into a managed service.

The host works and the LAN does not

The tunnel interface on the Linux box has an address inside the Client VPN client CIDR, and the endpoint pushed routes for the VPC ranges. A request made on that box is locally generated traffic: it selects a route, leaves through the tunnel, and gets an answer. That path never touches the forwarding code, the LAN interface, or any firewall rule that governs transit.

Traffic from another LAN device is a different flow. It arrives on the LAN interface, needs a route that points into the tunnel, needs forwarding enabled, needs a firewall that permits it, and needs the reply to come back through the same host. Four requirements, and the working laptop test proves none of them. From the desktop the failure looks bizarre: the tunnel is up, the credentials are valid, and the destination simply never answers. The defect is local to the gateway's forwarding path, not to the service.

Not every client can be a gateway

AWS states that its Client VPN desktop application does not support IP forwarding, and that other clients may. That restriction decides the architecture before any command is typed. If the only client available is the official desktop app, a Linux gateway forwarding for the LAN is not a configuration you can finish, and no amount of masquerading will change it.

The replacement client also has to match the endpoint's authentication method and the policy you intend to enforce. Certificate-based, directory-based, and SAML-backed endpoints do not accept the same client configurations, and a third-party client that authenticates but ignores the pushed routes is not an improvement.

Treat the client choice as part of the design review. It determines whether the LAN forwarding pattern is available at all, and it determines what identity the endpoint sees for every device behind the gateway. Record the client and the endpoint configuration it was tested against. A client swap six months later can silently remove the capability the design assumed.

Route the LAN to the tunnel and translate it

With a supported client in place, the rest is ordinary gateway work. The LAN devices need a route for the VPC range pointing at the Linux host, and the host needs forwarding enabled. If you want the VPC to see the traffic as the connected client rather than as an arbitrary LAN address, translate the source on the way out.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Scope the rule to the tunnel interface and the VPC range, as above, rather than masquerading everything the host forwards. The narrower rule is easier to reason about, and it does not quietly change traffic that was supposed to keep its original source address.

Make the LAN route arrive automatically if you can: a DHCP option, a router advertisement, or a static route pushed by whatever manages the LAN. A route that only exists on one test machine will make the design look broken the moment someone else tries it.

The reply needs a path too

Once the request reaches the VPC, the answer has to come back through the same translation states and find the LAN route on the gateway. That part usually works when the masquerade rule is in place, because the mapping lives on the host that performed it. It breaks when the VPC side has a route that sends the reply somewhere else, which is why the client CIDR route and the subnet association on the endpoint both matter.

Watch the counters, not just the ping. A masquerade rule with zero packets tells you the request never reached the tunnel interface, which points back at the LAN route or the client's own routing table. A rule with packets but no replies points at the VPC side, the authorization rules, or a security group that does not accept the translated source. Read both directions before changing anything, because a count that grows on one side only is a one-way path rather than a slow one.

Remember that the endpoint is a managed service. There is no server configuration file to edit and no client-config directive to add, so instructions written for a self-managed OpenVPN server with custom client subnet routes do not transfer. On AWS the levers are subnet association, authorization rules, and the VPC route tables.

Shared identity is the part policy must answer

Every device behind the gateway uses the gateway's VPN session. The endpoint's authorization rules grant access to a user or a group, and from the service's point of view there is exactly one user on that session. Local forwarding does not multiply that identity into per-device authentication, and it does not extend device posture checks to the printer in the corner.

That may be acceptable, or it may be the reason the design is rejected. It depends on what the VPC resources assume about who is calling. A shared identity that fits the authorization model is fine; one that quietly turns a single authenticated session into LAN-wide access is a finding waiting to be written up.

If the requirement is really to connect an entire site to a VPC, compare a supported site-to-site design before extending a remote-access client. The semantics differ, and a NATed client session is a poor substitute for a site link when the VPC needs to initiate connections into the LAN.

Decide the client, the route, the translation, and the identity story in that order. Each one constrains the next, and the order explains why the host works while the LAN does not.