OpenVPN LAN Access Broken? Check Zones, Routes, Return Path

The tunnel reports a successful connection, the router's own page loads, and a drive mapping to a machine behind it still times out. Nothing in that combination is contradictory: the router is answering as itself, and reaching anything behind it is a different decision made in a different place. Work the checks below in order and stop at the first failure, because each one rests on the one before. When all four pass, the fault sits above the tunnel rather than in it.

Which filter sees a packet bound for the LAN

A packet addressed to the router is consumed locally; a packet addressed to a host behind it must be forwarded, and firewalls judge those two cases separately. Permission to reach the router therefore says nothing about permission to cross it. Firmware that hides its rule sets still implements both, usually as a selector offering the LAN, the internet or both. If the selector leaves out the LAN, no later check will matter.

OpenWrt makes the split inspectable, and the distinction is worth reading once. The zone that terminates the tunnel needs a forward rule pointing at the LAN zone, while an input rule governs only services running on the router itself. A working administration page next to a dead LAN is the ordinary result of that missing forward rule.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Look at the forward target of the zone that carries the tunnel: accept is what the ladder needs, and reject explains every timeout below. Two neighbouring settings produce the same symptom, so rule them out while you are here. Wireless isolation hides wired hosts from wireless clients, and a router that treats idle LAN hosts as offline can drop the replies even after forwarding works.

Why a split tunnel needs the prefix pushed

A client that sends all traffic through the tunnel already holds the LAN prefix through its default route, so there is nothing to add. A split tunnel is the case that needs the prefix stated explicitly, because nothing else in the configuration mentions it. Add the directive to the server configuration and reload the service.

push "route 192.168.50.0 255.255.255.0"

Profiles containing route-nopull ignore pushed routes, so the same prefix belongs in the client file instead. Either way, confirm the entry arrived rather than assuming it did, since a silent override looks identical to a firewall problem.

ip route show | grep 192.168.50

A site-to-site peer asks for more than a push. The server has to learn which prefixes sit behind that peer, which is what an iroute line in its client-config-dir file does, and its own table needs a matching route into the tunnel.

The reply needs an address it can reach

Forwarding the request is only half of an exchange, because the LAN host has to answer an address in the tunnel pool. Small routers usually arrange that by translating the source on the tunnel zone, so the reply is addressed to the router and needs no configuration elsewhere. Remove that translation and the host requires its own route to the pool, which it gets for free when the router is its default gateway. A host with a hand-set address and a different gateway answers through that gateway instead, and the client watches a session open and then stall.

tcpdump -ni tun0 host 192.168.50.20

Run that on the router while the client repeats its request, and read the destination of the reply rather than the request itself. A reply addressed to the pool means the return path works and the failure is further in. No reply at all means the host never accepted the packet, which sends you back to the rule set.

A ladder that ends in the right place

Four checks locate the layer, and each one is a single command rather than a judgement call. Run them in order and stop at the first failure. The order matters more than the commands do, because a passing later step hides the reason an earlier one failed.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Names belong at the end of the ladder, never at the start. A share that answers as 192.168.50.20 but not as nas.local points at resolution or at a search suffix, and firewall edits cannot change either one.

Record the first failing step, then give service ports their own pass, because a listener and a host permission are separate requirements. File sharing, remote desktop and camera streams each need both, and a host firewall that trusts the LAN subnet but not the tunnel pool drops the client while ping still succeeds. When every check passes and the application still fails, the fault is above the tunnel: a service bound to one interface, or a proxy configured on the client.