This is the one WireGuard failure that is not your fault and not WireGuard's. If your ISP uses carrier-grade NAT, a VPN server at home or in the office is unreachable — full stop. Here is how to know in two minutes, and what to do next.
Every week, someone rebuilds their WireGuard setup three times chasing a problem that lives at their ISP. Check for CGNAT first — the panel above is the whole test. If it fails, this page lays out the real exits, graded honestly: one keeps your setup exactly as the video shows it; the others change the design, and you should know what each trades away.
Illustrative panel — example addresses only. If the two numbers differ, something is NAT-ing you upstream, and port forwarding cannot reach your firewall.
A VPN server is an inbound service: the phone outside must start a conversation with your firewall. Port forwarding works by telling your router, "send arrivals on UDP 51820 to the firewall." With CGNAT (carrier-grade NAT), your ISP has put a second, bigger NAT in front of your router. Your router's "WAN address" is a private address inside the ISP's network — the real public IP is shared with many other customers. Arrivals at that public IP stop at the ISP's NAT, which you do not control and cannot configure. No setting on the Untangle box, the router, or the client can change this. It is not a WireGuard problem; it would break every self-hosted server the same way.
100.64.x.x - 100.127.x.x — you are behind CGNAT. Also common: WAN shows a 10.x or 192.168.x address because the ISP's box is itself a router (double NAT), which at least is fixable locally by bridging or forwarding on both boxes.Do this check before the first tunnel, and the usual symptom — no handshake from outside, perfect behaviour from inside — never gets a chance to confuse you.
The cleanest fix is asking your provider for a public (often sold as "static") IP. Many Indian ISPs will assign one for a monthly fee, and some will move you off CGNAT if you simply ask and explain you run a VPN server. With a real public address on your router, the setup video's flow works exactly as shown, ideally with a DDNS hostname so address changes stop mattering. This is the only option that keeps your current architecture untouched.
If a public IP is refused or too costly, two honest designs remain:
What not to do: pay for "port forwarding unlock" software or follow guides that promise to defeat CGNAT from your side of it. The NAT is the ISP's; software on your PC cannot reconfigure it.
Once your connection has a reachable address, the setup in the video works as shown — watch it with the CGNAT question already answered.
▶️ Watch Full VideoIt affects every inbound server equally — WireGuard, OpenVPN, a camera system, a game server. The app and the firewall are fine; the address they sit behind is simply not reachable from the internet.
A genuine public static IP, delivered to your router, yes — port forwarding and DDNS then behave normally. Confirm with the ISP that the address is public and not itself behind their NAT; a 'static' address inside CGNAT space would not help.
Sometimes. If your ISP gives you real IPv6 and your firewall and the client's network both handle it, the VPN can run over IPv6 and sidestep the IPv4 NAT entirely. In practice, client networks vary, so treat IPv6 as a welcome bonus rather than the plan.