Home VPN Server Not Reachable: Walk the NAT Chain

The server answers on the LAN, the port-forward rule looks right, and an outside client still cannot connect. Walking outward one boundary at a time is faster than editing the rule a fourth time, because each boundary leaves its own evidence: the router's WAN page, the ISP's translation, and the listener on the host. Start at the admin page you already have open and finish with a test from a network you do not control. Write each result down as you go, since the sequence is the diagnosis and a remembered number is not evidence. If all you need is an outbound tunnel, translation is not your problem: only unsolicited inbound is blocked.

Start at the Router's WAN Page

Log in to the router and read the status page rather than the port-forward list. Note the WAN address, the interface it belongs to, and whether the connection type is DHCP, PPPoE or something the ISP provisions. Then compare that address with what an external service reports, using a phone on mobile data so the observation does not travel back through the same router. The two numbers answer different questions, and comparing them is the whole point of this step.

A WAN address that differs from the observed public address means at least one translator sits upstream of the router. That is not yet a fault, because many providers translate by design and the service still works. If the two match, the router probably owns the address and the problem has moved inside your network. Either way, write the pair down with the date, since providers reassign addresses and a comparison against last month's notes is worthless.

Walk One Hop Upstream

Run a traceroute from the router itself and read the first few hops. Repeated public addresses, a first hop that answers with a private address, or an address inside the shared 100.64.0.0/10 range all point at an upstream translator. RFC 6598 defines that range for exactly this kind of deployment, which is why seeing it in the WAN field is a strong signal rather than a curiosity. Two translators in the path make the trace less obvious, so read the pattern rather than a single line.

Some providers expose the assigned address only in the customer portal, so look there before concluding that the router is lying. A portal address that matches your external observation while the router reports something else is the clearest proof of an upstream translator. Capture both pages into the change record, because the argument about who owns which boundary goes a lot faster with two dated images.

Confirm the Listener and the Forward

A LAN test proves the service works locally and proves nothing about inbound reachability. Many routers answer their own forwarding rule from inside, so a hairpin test succeeds while the external path is still closed. Confirm that the daemon is bound to the address and port you believe it uses, then test from outside. Everything below is read-only.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

If the outside test shows no packet arriving at the router, the drop happened upstream and no local rule will fix it. If packets arrive and nothing responds, the listener or the host firewall is the next boundary. A packet capture on the host settles which of the two you are looking at, and it takes less time than another round of rule guessing. Keep the listener and its transport unchanged while you compare, or the next test answers a different question.

Change the Topology, Not the Same Rule

When the translator belongs to the ISP, the fix is a different path rather than another forward. A small VPS with a public address, joined by an outbound tunnel from the home side, puts a reachable endpoint in front of the service. A provider-supplied public address is simpler where it exists and usually cheaper than running a machine. IPv6 removes translation entirely, provided the client network, the DNS records and the firewall policy all support it.

Dynamic DNS only updates a name; it does not create reachability, and pointing it at a shared address sends clients to a provider gateway other subscribers also use. That failure looks exactly like a dead server, which is why the record from the earlier steps matters. Note which address the name resolved to when the test failed, and keep the answer with the test result.

Rewrite the plan around the boundary you control: the listener, the tunnel and the routes. Keep the old forward in place only while it still describes something true, because a rule that no longer matches the topology is worse than no rule. Record which layer was actually blocking and what evidence showed it. Otherwise the next person to open the admin page repeats every step of this walk from the beginning.