Reach a Home Device Over a Remote-Access VPN: Five Gates

A commercial internet-exit VPN hides your address; it does not connect you to your own house. Reaching the NAS or the printer on a home network needs a gateway that sits on that network and a client that builds a tunnel to it. The packet then has to pass five checks, and any one of them failing looks the same from the outside.

Gate 1: the client has to select the tunnel

Check that the destination prefix actually routes into the tunnel on the client. A split-tunnel profile that only pushes the VPN's own subnet will send 192.168.x.x straight out of the local interface, where it goes nowhere. Look at the client's routing table rather than at the profile name.

This is the most common failure with phone clients, which often default to sending only DNS or only one prefix. If the route is missing, the handshake can be perfect and the device still unreachable.

Confirm that the client's pool address and the home subnet do not overlap before going further.

Gate 2: the gateway has to forward

The VPN terminates on a host that must forward the decrypted packet onto the LAN. That requires IP forwarding enabled and a firewall policy permitting the flow from the VPN interface to the LAN interface. On a router appliance this is usually built in; on a Linux box running strongSwan or WireGuard it is two settings people forget. Check both before testing the service, since either one alone produces the same timeout.

Test with a capture on the LAN interface, because a packet that never appears there was dropped or never forwarded.

That is a different failure from a service that refuses the connection, and the distinction saves a lot of time. Keep the permit narrow, scoped to the service and the VPN pool rather than the whole subnet.

Gate 3: the reply path decides everything

The target replies to the source address it saw, which is either the client's pool address or the gateway, depending on whether you translate. If the target's default gateway is the home router and that router has no route to the VPN pool, the reply leaves by the internet and dies. That is the classic one-way connection.

Two legitimate fixes exist: add a route for the pool on the LAN gateway, or source-NAT at the VPN gateway so the target only ever sees the gateway address. The second is easier and loses the original source identity.

Choose one deliberately and write down which, because firewall rules and logs depend on it. The strongSwan forwarding guide walks through the Linux side of that decision.

Gate 4: names and prefix overlap

Local discovery names do not cross a routed boundary, so a device that appears as a friendly name inside the house may be invisible over the tunnel. Provide DNS for the private zone, or document the address. Whatever name you use has to resolve to something the remote client can route. That is why a device can be reachable by address and invisible by name at the same time.

Overlapping prefixes are the other trap: if the client pool is 192.168.1.0/24 and the home network is too, the client treats the destination as local and never sends it through the tunnel.

Renumber one side, or use a pool from a range you will never meet at home.

Gate 5: test from outside the house

A test from the kitchen proves nothing, because the traffic may never leave the LAN. Connect from a mobile hotspot or another network, then walk the gates in order: route on the client, capture on the LAN interface, service response, reply capture, and name resolution. The first gate that produces no evidence is where the work is.

If the service answers but the name does not, you have a DNS problem rather than a tunnel problem.

Keep the working configuration in a note with the pool, the route and the NAT choice, because the next router replacement will reset all three.