NAS Unreachable Over the VPN: Address, Return Path or Service?
A private tunnel needs a route to the NAS, a reply path and a permitted service. Decide which of the three failed before changing credentials.
Tunnels come up, clients get an address, and the NAS answers nothing at all. That single symptom covers three unrelated failures, and the order you test them in decides how long the repair takes. Addressing comes first because an overlapping subnet can send your request to a stranger's device. The return path comes second, because a request that arrives without a reply looks identical to a closed service. Service and permission come last, and only after the first two are proven.
Three failures that all read as unreachable
Address selection, return routing and service authorization produce the same user-visible message: nothing happens. They have different evidence, different owners and different fixes, so separating them is the whole task. A ping that fails proves little on its own, and a successful TCP refusal is actually encouraging news.
| Observation | Most likely conclusion |
|---|---|
| Route to the NAS address leaves the wrong interface | Overlapping or missing private route |
| Request visible on the server, no reply seen | Return path, gateway forwarding or translation |
| TCP connection refused rather than dropped | Reachable host, service not listening or filtered |
| TCP works, login or file access fails | Share permission, account or protocol version |
Read the table as an order of tests rather than a list of causes. Each row constrains the next, because a refusal already proves that addressing and the return path work. Spending twenty minutes inside firewall rules before checking which interface the route selected is the most common way to lose an afternoon. Work top to bottom and stop at the first row that matches.
Condition one: is that address the right device?
Write down the NAS subnet and the range the VPN hands to clients, then compare both with the network your laptop is on right now. In this walkthrough the NAS sits at 10.40.7.25 and the VPN pool is 10.40.9.0/24, two separate private ranges inside one site plan; a household that uses 192.168.0.0/24 or 10.0.0.0/24 has a much higher chance of colliding with one of them.
When the local network and the NAS network overlap, the client sends that traffic to its own gateway and can reach an unrelated device that happens to hold the same address. Verify the path before typing credentials into whatever answers.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25The first command names the interface and gateway the kernel would use, and the second shows the first hops that actually respond. If the two disagree, believe the lookup, because that is the path the packet will take. A hop list that stops one hop short of the NAS is also a finding rather than a failure. A lookup that resolves to the physical adapter instead of the tunnel ends the investigation at this point.
Condition two: does the reply come back?
The client needs a route toward the NAS, and the NAS network needs a return path toward the VPN pool. Gateway forwarding, firewall rules and deliberate translation each affect that pair. strongSwan's forwarding notes describe the return-route and translation choices for a private subnet behind a gateway.
When the request arrives and the reply leaves by another gateway, no DNS change repairs the asymmetry. A capture on both sides settles it in one attempt, and it also shows whether translation rewrote the source the NAS replied to. The administrator owns that boundary: permit only the required services and the VPN client range, and write down which of routing or translation was chosen.
Condition three: is the service there and permitted?
A management page and a file-sharing service are different endpoints on the same box, and one can accept connections while the other is blocked by the host firewall, the service configuration or a share permission. A device that replies with a refusal has proven the first two conditions already, which narrows the third considerably.
Test with the account that actually needs the files rather than the administrator account used during setup, since administrative rights cannot repair a missing route and a route cannot grant a share permission. Names belong here too: a NAS name discovered at home often depends on local multicast, which a routed tunnel does not carry, so try the vendor's documented private hostname or the address itself to separate naming from access.
Test from outside the NAS network, then widen slowly
A test performed on the same LAN conceals every incomplete part of the remote path, which is why the first successful remote attempt deserves a note in the change record. Run the checks from a client that reaches the NAS only through the tunnel, and keep the original error text from each attempt.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guestOnce the path works, transfer a harmless file and confirm the read or write behaviour you actually need. If large transfers stall while small ones succeed, the remaining problem is packet-size handling or connection stability rather than addressing.
Do not publish file-sharing or administration ports to the internet to work around an unexplained fault. Repair the private path, keep the NAS software supported, and test the restore of anything you back up across it before you rely on that backup.