Why a VPN Server Behind CGNAT Never Accepts Connections

A 100.64 address, a dynamic DNS name that resolves elsewhere and no inbound handshake are one problem: carrier NAT. Confirm it, then relay outbound.

The router reports a WAN address starting with 100.72, the dynamic DNS name resolves to a different public address, and the VPN server on that router never completes a handshake from outside. Port forwarding is configured, the service is running, and a test from the LAN still works. Nothing in the router log looks like an error. That combination is carrier-grade NAT, and no firewall rule can open a port on an address the ISP holds.

Confirming the shared address takes two minutes and prevents a week of configuration changes.

The Signs That Point at Carrier NAT

Compare the WAN address in the router's status page against the address an external lookup reports. A WAN address inside 100.64.0.0/10 is the usual sign, and the private ranges 10/8, 172.16/12 and 192.168/16 mean the same thing. If traceroute shows the same public hop repeated, or an early hop answering with a private address, another translator sits between the router and the internet. Some ISPs list the assigned address only in the customer portal, so export that value alongside the traceroute.

Changing protocols or ports does not help, because the problem is inbound reachability rather than a closed port.

Why Forwarding and Dynamic DNS Cannot Fix It

A port-forward rule maps a port on the router's WAN interface, but inbound traffic never reaches that interface: the ISP translates it first and only forwards what its own table allows. Publishing the shared address in dynamic DNS points clients at an ISP gateway used by many subscribers, which is why the name resolves and the handshake still fails. Hairpin tests succeed because the router answers its own rule from inside, and UPnP has exactly the same blind spot.

Reconfiguring the client will not help either, since the failure happens before any client setting is read.

Relay Through a VPS With Explicit Routes

Put a public address in front by renting the smallest VPS that can carry the traffic, then make the home router dial out to it. Outbound UDP from the home network passes carrier NAT, so the tunnel establishes from the inside and the VPS becomes the reachable endpoint. The home side becomes a client with a fixed tunnel address, not a server.

On the VPS, add a client-specific directory entry so the server knows which peer owns the home subnet, and add a matching kernel route.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

The iroute line tells OpenVPN which client receives traffic for the home subnet; the route line puts that subnet in the VPS kernel table so packets enter the tunnel at all. For a published service, add a destination NAT rule that forwards the public port to 10.8.0.10 and enable net.ipv4.ip_forward.

Test the Path From Outside

Verify each hop on the public side, because a successful tunnel does not prove the service is reachable. Listen-state and packet capture on the VPS separate nothing arrived from arrived and dropped.

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

If the capture shows packets from the phone but no reply, the server configuration or firewall is the next stop. If the capture shows nothing, the client is still resolving or sending to the wrong address.

Alternatives Worth Pricing First

A dedicated IPv4 address from the ISP is the shortest fix and is usually a small monthly fee. Native IPv6 removes translation at both ends when the VPN, the client network and the DNS records all carry it. A mesh overlay with a subnet router inside the home network achieves the same relay without a VPS, at the cost of depending on a coordination service.

Pick the relay when the requirement is stable inbound access and every rule should stay under your control. Pick the ISP address when the budget allows and the goal is simply to stop thinking about it.

Ingingo zihuye