Routed VPN Client Reaches the Server but Not LAN Hosts

The tunnel comes up, the client pings the VPN server, and a share on a machine one hop further away never answers. Nothing in the client configuration explains it, because the request did leave the client and did arrive. What failed is the trip back, and the device that failed is usually the LAN gateway rather than the VPN host. Tracing the reply packet explains the whole class of symptoms.

Follow the Reply, Not the Request

The VPN server decrypts the client packet and forwards it onto the LAN with the client address still in the source field. The destination host answers that address, and now its own routing table decides everything. Its default gateway knows nothing about the tunnel pool, so the reply leaves toward the internet provider and is discarded somewhere along that path.

On the client the symptom is a silent timeout: no refusal, no reset, just nothing. A share browse hangs, a ping reports no reply, and the server logs look healthy because the server did its job.

Put the Return Route Where the Hosts Look

Every LAN host consults its default gateway, so the gateway is the one device that needs to know where the tunnel pool lives. Add a static route there and each host inherits the correct path without being touched.

If the gateway hands out its own address as a DHCP option, distribute the route that way so new machines pick it up automatically. Otherwise the route lives in one configuration file and disappears at the next rebuild.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Why Source NAT Appears to Repair It

Masquerading the client pool behind the VPN server address removes the problem by removing the client address from the packet. Replies then come back to the server, which already knows how to reach the tunnel, and everything works. The cost is that internal hosts can no longer see who the client is, and every connection looks like it originates from one machine.

That trade is sometimes correct, for example when a vendor appliance cannot be given a static route. Make the rule no wider than the current pool, because a rule written for a /24 stops matching the day the pool is renumbered to a /16, and the first sign is a batch of new clients that connect and reach nothing.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

The Cloud Path Needs Three Settings

In a VPC the same gap returns in a different shape, because the subnet has no route for the client range at all. The route table needs an entry for the tunnel pool that targets the instance's network interface, and the interface needs source and destination checking turned off so the platform accepts packets whose source is not its own address. Security groups and network ACLs must also admit the pool in both directions.

Each omission produces a distinct partial failure. Skip the route table entry and private instances answer into a subnet that cannot carry the reply back to the pool. With checking still enabled, the platform drops the reply after the instance has already sent it. Without the security group rule, the request itself never arrives, and the client sees the timeout one layer earlier.

Run the Checks in This Order

Confirm forwarding and the filter policy before blaming routing, because a host that will not forward fails in the same silent way. Then read the effective reverse-path setting on the interface that carries the tunnel, since a strict filter can discard replies that arrive from an unexpected direction.

Finish with a capture taken on the LAN host while the client pings it. A request that arrives with no matching reply proves the return path, and a request that never arrives moves the fault back to the server or the tunnel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

The source and destination check is documented in the elastic network interface guide. Set it on the interface that actually carries the tunnel traffic, not on an unrelated adapter attached to the same instance.