VPN Clients Reach the Server but Not the LAN: Which Fix?

The client pings the tunnel address of the OpenVPN server and gets an answer, then tries a host on the server's LAN and gets nothing. That split narrows the fault considerably: the tunnel is up, forwarding is probably working, and the reply is leaving by a door that does not lead back. Three fixes exist, and the right one depends on what you control and what you are willing to give up. Answer the three questions below in order and the choice stops being a matter of taste.

First, confirm which direction is broken

The request arrives on the tunnel interface with a source address from the VPN pool. The server forwards it to the LAN host, and that host replies to whichever gateway its own table names, usually the LAN router. If the router has no route for the pool, the reply dies there or wanders toward the internet.

Test both machines before editing either. On the server, ask the routing table how it would reach a client; on the LAN host, ask how it would reach the same address. The first lookup usually points at the tunnel and the second at the LAN router, and that difference is the fault in one line. Two lookups are cheaper than a firewall audit and they settle the direction of the problem.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

If the LAN host already points at the VPN server, your problem is a firewall rule or an MTU limit rather than a missing return path. Do not add a route to fix a filter.

Question one: can you edit the far LAN's router?

When the LAN router is yours, a static route for the VPN pool with the VPN server's LAN address as next hop is the clean answer. It keeps client source addresses intact, which matters when LAN hosts log, filter or rate-limit by address. It also needs no translation on the server, so the tunnel stays a pure routing path. The obligation it creates is documentation, because the pool, the route and the server configuration have to agree.

It fails quietly the day someone changes the pool. Write the value down once and treat an edit in any of the three places as an edit to all of them.

A NAS or a Layer 3 switch that hosts the service needs the same route unless it sends everything through a router that has one. Check the device that terminates the subnet, not only the one facing the internet. Small networks often have three devices with an opinion about routing.

Question two: can the LAN stop seeing client addresses?

When the router belongs to someone else, translating on the VPN server needs no cooperation. The LAN host sees the server's LAN address, replies to it, and the server translates back. That is why appliances and NAT-based remote-access roles behave this way.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

The cost is attribution: per-client addresses disappear from LAN logs. Any allowlist on the LAN host must then name the server instead of the pool.

Pick translation when cooperation is unavailable, not when it is merely inconvenient. It hides the client from every future investigation, including the ones where you need to know which laptop opened a connection. It can also break protocols that embed addresses in payloads, because the translation lives in the header. Neither option is more advanced; they answer different questions about ownership.

Question three: is the server itself a client of another tunnel?

Picture the other topology: the VPN server also dials a commercial provider, so it has two tunnels and two sets of addresses. Traffic it forwards for its own clients leaves through the provider, which will not route replies back to pool addresses. That is why replies vanish even though both tunnels are healthy.

The fix is to masquerade the outbound tunnel as well, so the provider sees only the server's tunnel address. The reverse direction needs its own rule, because the server initiating a connection to one of its own clients is a different flow. Without that rule, the client answers an address it cannot route. Place the narrow rule before any broad masquerade so the specific translation wins.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Multihomed hosts add a related failure that looks identical from the client. The reply leaves by the lower-metric interface because the source address was chosen from a different table. Check the reply path with a lookup rather than assuming the forward path implies it.

Then verify both directions and both sizes

After the change, ping from the client to a LAN host, then from the LAN host to the client. The second direction is the one people skip, and it is the one that exposes an incomplete translation rule. Record both results with timestamps so a later regression is comparable.

Then move real data, since a small ping that succeeds while a large transfer stalls is an MTU symptom. That failure appears right after you congratulate yourself on fixing the route.

Finally, re-test after a reboot. Runtime route and firewall commands do not survive one, and a fix that vanishes at the next restart will be diagnosed again by someone with less context. Make the change persistent in the way your system already does it, then reboot once on purpose.