VPN Connects but Cannot Reach LAN Devices: What to Check

Traffic enters the tunnel, the gateway answers at its own address, and nothing behind it responds. That pattern is common and it is not a contradiction: a reply from the gateway proves the tunnel terminated, and it proves nothing about what happens to a packet addressed past it. The two tests exercise different code paths on the same machine.

Test something on the far side of the gateway from now on. The gateway's own address will keep answering however broken forwarding is.

The Gateway Answers From Its Own Stack

A packet addressed to the gateway is delivered to its local input path, where the kernel decides whether a listening socket accepts it. A packet addressed to a host behind the gateway is delivered to the forwarding path instead, where a different set of checks applies. Forwarding can be disabled entirely, or enabled by the kernel and then rejected by a filter rule that never mentions the tunnel. None of that affects the gateway's own reply, which is why the symptom misleads so reliably.

Administration pages reached through the tunnel belong to the first category as well. They are evidence about the tunnel, not about the network behind it.

Follow the Flow to the First Boundary That Drops It

Start at the client and confirm the route and the source address the flow will use. Then watch the gateway for that exact flow arriving, and again for the same flow leaving toward the LAN. If it never arrives, the client side or the tunnel's allowed prefixes are the problem. If it arrives and never leaves, forwarding or a forward-path filter is the problem, and the capture has already said which.

Running the same test from the gateway hides the interesting half, because a gateway-originated packet has a different source and a different return requirement. Use the client's flow, carrying its own source address, for every step. A capture taken on the wrong interface produces confident nonsense.

Return Routes and Host Firewalls Fail Separately

Once the packet reaches the host, three more things have to hold. The service must be listening on the address the packet was sent to, the host firewall must accept it, and the reply must have a route back toward the client pool. That last one fails often, because the host's default route points at a router that has never heard of the tunnel range. The result is a connection that establishes from the host's point of view and dies silently in the other direction.

Test the reply path deliberately by sending from the client and watching for the return. A one-directional capture settles in seconds what an hour of speculation will not.

Confirm Each Hop With the Client's Source

Run the checks in order and keep every output, because the value sits in the comparison rather than in any single line. The commands below pin the source address, show the chosen route, and capture both sides of the forward. Substitute your own LAN host and tunnel interface.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

The route query shows whether the client would even send that packet into the tunnel, and the ping shows whether anything came back from the host. Comparing the two captures separates arrival from egress, since a frame on the tunnel interface with no counterpart on the LAN interface is a forwarding decision rather than a service failure. When both captures show the request and only one shows the reply, the return route is the remaining suspect.

Record which address answered and which forwarded destination failed. That sentence makes the report actionable instead of a claim that the server is unreachable.