Router in VPN Client Mode: Why LAN Devices Disappear
LAN devices vanish after a router enters VPN client mode: test the forward path inspection feature, then the LAN range the firmware changed underneath you.
Believing that client mode itself kills LAN access sends people into the wrong settings menu, and the real causes are usually two. The tunnel does not remove the LAN bridge or stop wired and wireless clients from reaching each other. What breaks local access is either an inspection feature sitting in the router's forward path or a LAN address range that moved when the firmware did. Both produce the same complaint, and neither is fixed by reinstalling the VPN profile.
The myth, and what client mode really changes
Client mode adds a tunnel interface and a default route that points through it, then forwards LAN traffic into that tunnel. The bridge between the wired ports and the wireless radios is untouched, and so is local switching. What changes is policy: which traffic is forwarded, where it is translated and which resolver the clients receive.
That distinction matters because a broken LAN usually means one of those three policies changed, not that the router stopped being a switch. A router that still answers its own administration page is proof the LAN interface is alive. A router that answers nothing at all has a different problem, such as a changed LAN address or a client on the wrong subnet.
So the useful first move is to find which layer broke, not to change the layer you suspect.
Probe three targets before you touch a setting
From a wired client, probe three targets separately and write down each result: the router's own LAN address, one other device on the same switch by IP, and something reachable only through the tunnel. Do them in that order, because each result rules out a different layer. Use addresses rather than names for the first pass, since a name failure mixes DNS into a connectivity question.
The pattern of answers is the diagnosis. A router that answers while local devices do not points at local switching or a filtering feature rather than routing. Local devices that answer while the tunnel side does not point at the tunnel route or the remote firewall. Everything answering by address while names fail is a resolver question, and no amount of route editing will fix it.
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
Keep the table next to the test results. It turns a vague complaint into one line you can act on.
The security layer inside the forward path
Consumer routers increasingly ship an inspection feature that watches forwarded traffic, and it runs in the same path that carries LAN-to-tunnel packets. When that inspection cannot classify the tunnel traffic, forwarding can stall while the tunnel itself stays up and the router reports a healthy connection. Nothing in the VPN log shows this, because the VPN did connect.
The diagnostic is a controlled experiment rather than a permanent change. Note the current setting, turn the feature off for the length of one test, bring the tunnel back up, and probe a single local host by address. Forwarding that comes back is the proof you needed, and the trade-off then becomes a decision instead of a guess. If nothing changes, re-enable it immediately and move to the addressing cause.
Leaving a paid security feature disabled so a tunnel keeps working is a trade to make deliberately and to write down. It is also worth asking whether the tunnel belongs on a different device, because a router that must inspect everything and a router that must forward everything are two different jobs.
The second cause: the LAN range moved
Firmware updates routinely reset the LAN address to the vendor default, and some routers have an explicit mode switch that decides whether the LAN keeps a private range or inherits one from the upstream device. A client that expects 192.168.8.x can end up on 10.64.0.x, at which point an SSH session to a host times out even though the tunnel is perfectly healthy.
ipconfig /all
ip addr show
ip route get 192.168.8.20Read the prefix and the gateway from the lease before you open the router page. The first two commands show what the client actually received, and the third shows which interface the client would use for a local address, which is how a leftover route or a stale subnet reveals itself. Then compare that with the LAN page and the mode the router is in.
If the range cannot go back, update every object that names it: DHCP reservations, any static route pointing into the old subnet, and each firewall rule that carries the previous prefix. A range that collides with the tunnel's remote subnet is the nastier variant, because local devices stay reachable while remote destinations are silently misrouted into the LAN.
Reconnect and retest in packet order
After either change, reconnect the tunnel and repeat the probes in packet order: router, local host, remote host, then names, then the application. Testing the application first hides which layer is still broken, and a browser retry against a cached name can look like a routing failure.
Record the firmware version, the LAN prefix and the state of the inspection feature next to the VPN profile. All three are configuration that the next update may overwrite, and two lines of notes save the hour you just spent.