Home VPN server vs cloud server: which one reaches your NAS?

The tunnel comes up, the client shows a green dot, and ssh 192.168.1.20 still hangs until it times out. I hit exactly that after renting a small cloud instance and putting WireGuard on it: handshake fine, DNS fine, and the NAS on my desk as unreachable as if it sat on the moon. Nothing was wrong with the tunnel. The endpoint was parked in a network that has no route to my house. Endpoint location decides which networks are adjacent, so pick it by the resource you need to touch first and compare hosting second.

A tunnel only reaches networks the endpoint can route

A VPN hands your client an address inside the endpoint's own routing domain. When the client sends a packet to 192.168.1.20, the endpoint has to know where that goes. A cloud VM's table knows the provider's VPC subnets; it has never heard of your LAN. Connected and reachable are two different facts, and most of the home-versus-cloud confusion comes from treating the first as proof of the second.

One command settles it. On the endpoint, ip route get 192.168.1.20 either names a LAN interface or points at the default route. On a home box the answer is the LAN side. On a cloud instance the packet leaves toward the internet and dies. Turning on net.ipv4.ip_forward=1 and adding a MASQUERADE rule does not change that, because there is nothing to forward to until something on the home side terminates a link into the cloud.

The home case has a second half: the return path. Packets leaving the LAN through the tunnel box get NATed, or the LAN needs a static route back to the tunnel subnet. When only one direction works, check sysctl net.ipv4.conf.all.rp_filter. Strict reverse-path filtering drops replies that arrive on a different interface than the route predicts, and the symptom looks exactly like a firewall rule.

Read the symptom before touching the config

Tunnel will not establish: keys, endpoint address, or a blocked UDP port. Tunnel up but LAN hosts dead: placement and routing. Tunnel up but browsing dead: forwarding, NAT, or DNS. Those are three layers, three different checks, and rewriting a config that was already correct wastes an evening.

Home inbound reachability deserves its own check, because it decides whether hosting at home is possible at all. Compare the WAN address your router reports with the address an outside host sees. If it lands in 100.64.0.0/10, or the two disagree, you are behind carrier-grade NAT and no port forward will ever work. The real options are a relay, a cloud link that dials outward from home, or moving the endpoint.

What home hosting buys you, and what it costs

Home is the only placement that sits inside the LAN by default, and that is the whole reason to put a server there. Devices that answer only on the local segment, such as printers and NAS admin pages that reject non-local subnets, work without extra routing. You also operate the machine, the router and the uplink yourself.

The costs are physical. Home upload is the ceiling for every client at once, so a video call and a backup compete for the same pipe. Power, disk wear, patching, a dynamic address that needs DDNS, a router that has to forward UDP inward, and possibly double NAT all land on you. The one people skip is recovery: if the box dies while you are away, your only path into the house dies with it. Keep a second device with the same keys, or at least a plan for physical access.

If you want LAN access without the box at home, build a link instead of pretending. The cloud endpoint becomes a router: a tunnel from the home side with AllowedIPs = 192.168.1.0/24 on the cloud peer, plus forwarding and NAT on the cloud box. strongSwan's forwarding how-to walks through the return-route half of that setup, which is where most of these attempts fail. The home peer now has to be up for anything to work, so you traded one dependency for another and should write that down.

What a cloud endpoint is actually for

A cloud endpoint changes your public exit. Traffic leaves from the provider's address range, and sites see that address rather than your home one. That is the value, and it is also why a cloud VPN does not hand you the NAS: you moved the exit, not the LAN.

You still run the guest system, the VPN service and its credentials while the provider runs the hypervisor and the physical network, and the split matters when something breaks at 2am. A public endpoint is scanned continuously, so keep the management port closed, allow only the VPN port, and patch on a schedule. Security groups and provider firewalls must permit that port, and some clouds drop forwarded traffic unless you adjust source and destination checking on the instance.

A small instance covers a handful of clients, but encryption is CPU work, and a burstable instance that runs out of credits behaves unevenly under sustained load. Watch the path you actually use rather than the spec sheet.

A decision you can write down

The task decides placement, not the label on the box. If you need a device on your home LAN, the cheapest correct answer is an endpoint at home; a cloud box only works after you build the link back. If you need a different public exit, cloud is the answer and the LAN question never arises. Wanting both is legitimate, but it means two endpoints, two sets of keys and two documented routes.

Verify from the client in order: handshake, peer address, a LAN host, then the exit IP. curl -s https://ifconfig.me shows what the internet sees, and ip route get 192.168.1.20 shows what the endpoint believes. When the exit check passes and the NAS check hangs, you already have your answer about placement; adjusting AllowedIPs on the client will not conjure a route. A split line such as 10.8.0.0/24, 192.168.1.0/24 only keeps LAN traffic inside the tunnel once that route genuinely exists.