WireGuard Behind CGNAT: Why Port Forwarding Fails and How to Fix It (2026)

You installed WireGuard on your home server, opened UDP 51820, forwarded the port on your router - and it still will not connect from outside. Before you re-check the config for the tenth time, suspect the network: the most common reason a self-hosted VPN cannot be reached from the internet is CGNAT, and no amount of router configuration fixes it. Here is what it is, how to confirm it, and the fixes that actually work.

What CGNAT is, and why it breaks self-hosting

CGNAT (carrier-grade NAT) is how many ISPs cope with the shortage of IPv4 addresses: instead of giving each customer their own public IP, they put many customers behind one shared public address. Your router's WAN side gets a private-range address (often in 100.64.0.0/10), and the ISP's own NAT decides what comes in.

The consequence is simple and frustrating: there is no public IP that points to your line, so inbound connections have nowhere to land. Port forwarding on your router only controls traffic that already reached your router - and with CGNAT it never does, because the block is one level upstream, inside the ISP.

How to check if you are behind CGNAT

You can confirm it in a minute. Open your router's admin page and find its WAN IP address. Then look up your public IP at a service like whatismyip. If the two do not match, you are behind CGNAT. A router WAN IP inside 100.64.0.0/10, or a private range such as 10.x.x.x or 192.168.x.x, is a dead giveaway.

The fixes, from cleanest to hackiest

• A VPS with a public IP (most reliable). Host WireGuard on a cheap VPS. It has a real public IPv4, so there is no NAT to fight - your devices connect straight to it. If you also need to reach your home LAN, run a small tunnel from home out to the VPS; that connection is outbound, which CGNAT allows.
• A NAT-traversal mesh (easiest). Tailscale, the self-hosted Headscale, or Netbird use outbound connections and relay servers to link two devices behind NAT, with zero port forwarding. See what Tailscale is and how it works.
• Ask your ISP for a public IP. Some providers will move you off CGNAT or sell a static IP, sometimes for a small fee.
• IPv6. If your ISP hands out real routable IPv6, WireGuard over IPv6 avoids the shared-IPv4 problem - provided both ends have working IPv6.
• Reverse tunnels. Cloudflare Tunnel, wstunnel or an SSH reverse tunnel initiate outbound from home to a public endpoint, so they too work through CGNAT.

Whichever route you pick, you will still want a stable name to reach it; our dynamic DNS guide covers keeping a hostname pointed at a changing address.

Why the VPS route is usually best

For a VPN you rely on, a VPS with its own public IP removes the whole problem class. You get a predictable address, full control of the firewall and port, no dependence on your ISP's goodwill, and it doubles as an exit node if you want one. The honest trade-off is a few dollars a month and the small responsibility of keeping the server updated.

The bottom line

If WireGuard connects fine on your local network but never from outside, suspect CGNAT before your config. Confirm it with the WAN-versus-public-IP check, then choose a fix: a public-IP VPS is the most reliable and the one most self-hosters settle on, a NAT-traversal mesh is the simplest zero-forwarding option, and IPv6 or an ISP public IP work well where they are available. The problem is your ISP's address sharing, not your WireGuard file.