Router VPN Works but LAN Clients Have No Internet

Status says the tunnel is up, a browser on the router itself loads pages, and every device behind it still times out. That combination narrows the problem to a layer most VPN guides never mention: the router is not the only host whose packets need to survive the tunnel. Locally generated traffic and forwarded traffic take different paths through the same box. Test from a client and the difference stops being theoretical.

Read the Failure From a LAN Host

Start at the device that fails, because a diagnostic run on the router answers a different question. Confirm that the client's default gateway is this router, note its source address and subnet, and then look at what leaves the router's tunnel interface.

If the client's address is translated, the remote side sees the tunnel address, and everything looks healthy from there while the client still fails. If it is not translated, the remote side must know a route back to the client subnet, and many gateways have no such route by default. Either way the router's own success is irrelevant, because its packets were generated locally and never traversed the forwarding path.

Local Traffic and Forwarded Traffic Are Different

Linux and most router firmware treat packets originated by the box differently from packets passing through it. The output chain sees the first kind, the forward chain sees the second, and a policy tuned for the router's own traffic can leave forwarding untouched.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Check that forwarding is enabled at all, then read the forward chain rather than the output chain. A rule that permits the encrypted outer connection is not a rule that permits decrypted packets to be forwarded, and confusing the two produces exactly this symptom. The tunnel being up proves only the first.

The Return Path Must Also Exist

Source translation decides whether a return path is needed. With masquerading on the tunnel interface, replies come back to the tunnel address and the router untranslates them. Without it, the remote gateway needs an explicit route to the client subnet, and its own policy must permit that direction.

Record which of the two designs the deployment uses before changing anything, because the repairs point in opposite directions. Adding translation hides a missing return route and breaks applications that need the original source address. Adding a return route without translation fails silently when the remote firewall drops the unfamiliar source. Pick one, document it, and make the other side match.

Client DNS belongs to the same review. The router's resolver can answer while a client pointed at a different server gets nothing at all.

Verify One Allowed Flow and One Denied Flow

After the correction, test a new connection from a client rather than an existing router session. Then confirm that a segment which should not use the tunnel still does not.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Check the observed source address at the far end, since that tells you which design is actually running. Verify a name lookup as well as an address, because resolver behaviour is a separate path through the same box.

Keep rules scoped to the client networks that need the tunnel, and resist disabling the forwarding filter to make one test pass. That change repairs the test and removes the boundary the tunnel was supposed to provide. Write the source address, the translation decision and the return route into one note, with a date.