LAN router plus VPN client: two devices, two route tables

Two devices forward the packet and each keeps its own table. The LAN router knows that the remote prefix belongs to the VPN client, and the VPN client knows how to reach that prefix through its tunnel. Configure only the first table and the packet arrives at a machine that has no matching route, so it leaves again by the default. That is the whole failure, and it looks like a routing loop from the LAN side because it very nearly is one.

Draw the two hops before touching a route

Take an illustrative layout: LAN hosts on 192.168.50.0/24, the ordinary router at 192.168.50.1, a dedicated client at 192.168.50.15, and a remote LAN at 10.60.0.0/24 reachable only through the tunnel that client holds. Neither private range overlaps the other, and the tunnel has its own address plan.

Both private ranges matter because they decide which device can answer. The remote side will see the packet arrive from the client's tunnel address, and its reply has to find a way back to 192.168.50.0/24. If only the outbound direction is configured, the request may work while the response disappears.

Step 1: point the router at the client, not at the tunnel

On the LAN router, add a destination route whose next hop is the client's LAN address:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

That record says "deliver it to the machine that can tunnel". It says nothing about how the tunnel is built, and it is not a substitute for the client's own route. On a managed router the equivalent lives in the device's static-route page; on a Linux router it belongs in the interface configuration that owns the LAN, not in a shell you will close.

Check the second command's answer. If it reports the client as gateway and the LAN interface as device, the first hop is correct and the remaining work is on the other machine.

Step 2: give the client a tunnel-side route of its own

The client now receives a packet for 10.60.0.0/24 and consults its own table. If its tunnel configuration installed a route for that prefix, the packet continues encrypted. If it did not, the packet matches the ordinary default and goes back to 192.168.50.1, which sends it to the client again.

Look before you add anything:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

A missing prefix route in every table is the finding you are looking for. Add it through the tunnel's own configuration, so the next reconnect reinstalls it; a manual ip route add disappears with the session and makes the fault return at the least convenient time. The next hop is the tunnel interface or the address the VPN assigns as its peer, depending on the client, and the peer address should come from the current profile rather than an old note.

The loop, when it happens, is not infinite in practice: the TTL falls on every pass and the packet dies with a time-exceeded message. That is why a repeating traceroute can suggest a cycle while a client that simply is not forwarding drops the same packet silently.

Step 3: permit forwarding and choose the return path

Receiving and forwarding are different permissions. net.ipv4.ip_forward=1 on the client allows transit at the kernel level, and a firewall rule still has to allow it between the LAN interface and the tunnel. A rule that permits access to the client's own management page will not permit transit to the remote LAN, and the distinction is easy to miss when the same host answers pings locally.

The remote side has the mirror problem. It must know that 192.168.50.0/24 is reachable through this authenticated client. With OpenVPN that usually means a per-client route pushed by the server configuration, or a client-specific file on the server that declares the LAN behind the client. Without it, the remote LAN either drops the reply or sends it to its own default gateway, which is the internet.

Source translation is the alternative when the LAN prefix cannot be advertised. A scoped masquerade rule on the client rewrites the source to the tunnel address, and replies then return naturally. It also hides which LAN host made the request, and it does not by itself allow the remote side to initiate connections inward. Choose that trade-off deliberately rather than adding a blanket masquerade and discovering the side effect later.

Step 4: persist both decisions, then test the real path

Each route has an owner, and the owner is the configuration that regenerates at boot or at reconnect. On the router that may be a static route entry; on the client it may be the VPN profile, NetworkManager, or systemd-networkd. Verify by reconnecting the tunnel and rebooting the client, then reading the table again rather than trusting the edit.

Keep the default route that carries the tunnel's outer connection intact. Replacing it to "simplify" the setup breaks the encrypted path before any inner traffic can use it, and the symptom is a tunnel that never re-establishes after the change.

Test from an ordinary LAN host, not from the client, because a request originated on the client never exercises the router's first hop. Fetch a service that exists only on the remote LAN and confirm the reply body, then check the client's counters or logs to see the transit happen. An inner traceroute that shows private hops proves forwarding, not encryption: the outer path is a separate observation, and only the tunnel's own interface counters show what left through it.