Double NAT and Your VPN: Client Works, Server Does Not

Your router sits behind another router, the WAN address is private, and the VPN client still connects. That combination surprises people who expect double NAT to break tunnels, but outbound connections are what translation handles best. Hosting a VPN server behind the same two layers is the case that usually fails. Draw the direction of the connection before you change anything.

Draw the direction of the connection first

Open the inner router's status page and write down its WAN address, then compare it with the address a public service reports for you. If the two differ, at least one translator sits between your router and the internet. If the WAN address falls inside 100.64.0.0/10, the outer translator is probably your provider's, and you do not control it. Those two facts decide which of the later steps can possibly work.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

Double NAT is not double VPN. Translation rewrites addresses and ports; it does not add a second encrypted tunnel, and it does not encrypt anything. Keeping the two ideas apart matters because the fixes are completely different, and one of them involves a conversation with your provider rather than a settings page.

Outbound: the client asks, the translators map

An outbound tunnel starts with a packet from your machine, so each translator can create a mapping and let the reply back in. The protocol, the port and the idle timers decide whether that mapping survives long enough to be useful. Most consumer routers handle this without any configuration at all.

The failures that do appear are usually about timeouts and protocol support rather than about the number of routers. A tunnel that drops after a few minutes of silence is a mapping expiring, and a keepalive is the standard answer. IPsec has standard NAT-traversal extensions, so claiming it cannot cross translation is simply wrong. If the tunnel never establishes at all, look at the endpoint and the credentials before blaming the topology.

wg show
ping -c3 10.8.0.1

Stop if the outbound tunnel works from one network and not another. That comparison is about the networks, not about the count of routers.

Inbound: forwarding only covers equipment you own

Hosting a server is the reverse direction: a new connection arrives from the internet and has to reach your machine through every layer. A port-forwarding rule on the inner router helps only if the outer translator also delivers that traffic to you. Repeating the local rule does not grant control of the provider's equipment.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Check the inner router's WAN address against the public address you observed, and note where each value came from. If the WAN address is private or in the shared range, the outer layer is doing translation you cannot configure. Ask the provider what inbound reachability it supports before you spend an evening on rules that cannot take effect. Removing a router or disabling a firewall broadly is not a diagnosis, and it is a poor trade for one open port.

Stop if the outer layer is the provider's and it does not forward. Then the supported answers are a different access method or a relay, not another rule on your side.

Test one variable at a time

Change one thing per test and record the result, because a double-NAT path has more variables than a single-router one. Keep the profile and the device fixed, then compare a different access network. Note whether negotiation fails, whether the session drops after idle, or whether only private destinations fail. Those three observations point at three different layers.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Overlapping private subnets are a separate trap that no amount of translation fixes. If your home network and the remote network both use the same range, a route conflict appears regardless of how many translators sit in between. Renumbering one side is the only durable answer.

The remote gateway deserves the same attention, because its forwarding rules and return routes can be the missing piece. A tunnel that authenticates can still have no usable application path, and that failure looks identical from the client side. The walkthrough ends when you can say which direction fails and which layer owns it.