OpenVPN Client Reaches the Server but Not LAN Hosts: Checklist

The client says connected, the tunnel address answers a ping, and nothing on the office LAN responds. I see this after almost every client upgrade, and the first instinct is to open the firewall, which is usually the wrong move: the tunnel is fine, and the break is one of three hops the packet has to cross. Walk the path in the order the packet takes it, client route first, then server forwarding, then the return trip, and you will find the owner of the fault in a couple of minutes.

Step one: watch the client routing decision

Before touching the server, prove the client sends the packet into the tunnel. Ask the kernel which interface it would use for one specific LAN host, instead of reading the whole table:

ip route get 192.168.50.10

If the answer names your physical adapter and the office gateway, no server-side change can help. OpenVPN hands out routes only when the server pushes them, so look for push "route 192.168.50.0 255.255.255.0" in the server configuration, and reconnect the client afterwards. Most clients apply pushed routes at connect time, not when you reload the profile.

On Windows the same question has a different command. Find-NetRoute -RemoteIPAddress 192.168.50.10 prints the interface and next hop the stack would choose, and route print -4 shows whether the pushed prefix exists at all.

Step two: confirm the server will forward the packet

If the client route is right, the packet reaches the server and the server has to agree to forward it. The kernel switch is the first gate, and sysctl net.ipv4.ip_forward has to return 1. Setting it with echo 1 > /proc/sys/net/ipv4/ip_forward works until the next reboot, which is exactly why the same complaint returns weeks later.

Write it down somewhere that survives a restart:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

The second gate is the filter table. A host with Docker installed often carries a FORWARD policy of DROP, and the tunnel inherits that decision. iptables -L FORWARD -v -n shows both the policy and the packet counters; if the policy is DROP, forwarding needs an explicit accept for the tunnel-to-LAN direction and one for the reply.

Step three: follow the packet onto the LAN and look for the reply

Watch both sides of the server at once. Capture on the tunnel and on the LAN interface, filtered to one client and one host so the output stays readable:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Requests that show up on tun0 and again on eth0 with a source of 10.8.0.x, followed by silence, mean the packet arrived and the answer went somewhere else. The LAN host replies to its default gateway, that gateway has no route for the VPN pool, and the reply dies on the LAN router. Pinging the LAN host from the server proves nothing about this path, because that traffic never crosses the tunnel.

Step four: choose between translation and a return route

Two repairs close the hole, and the choice has consequences beyond whether ping works. Source translation makes the server the apparent sender:

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

Scope the rule to the pool and the LAN interface, then persist it, or the next firewall reload quietly removes your fix. The cost is identity: every client looks like the VPN server in LAN logs and access rules, and per-client policy becomes guesswork.

A static route for 10.8.0.0/24 on the LAN router, pointing at the VPN server, keeps client addresses visible and is the better long-term answer when that router is yours. Plenty of sites run both for a while, NAT for the immediate repair and the route once firewall policy is written. If the server is a site-to-site peer rather than a pool, the server side also needs an iroute for the remote subnet, otherwise the peer route exists but client traffic is never associated with it.

Step five: verify from the client and record what changed

Close the loop from the client, not the server. Connect to a real service on the LAN host, then confirm the translation counters moved with iptables -t nat -L POSTROUTING -v -n, because a rule with zero packets is a rule that never matched. conntrack -L -s 10.8.0.5 shows the flow and its state when you need proof that the return direction is tracked.

Leave a note in the server config: which subnet, which interface, which rule, and whether the LAN router carries a route back. The next time a client upgrade clears a pushed route, that note turns a firefighting session into a one-line fix.