You set a port forward on the router. The rule looks right. The PC is on. Outside tools still time out. On many home lines the problem is not a typo in the port number — it is CGNAT. The internet never gets a private map from the shared public IPv4 down to your gateway.
This post is about why inbound port forwards fail on CGNAT: the broken inbound path, the symptoms people hit, and what actually restores reachability. For what CGNAT is, see What Is CGNAT? Shared Public IP Explained. To check your own line first, use How to Tell If You're Behind CGNAT.
Short answer
On CGNAT, a home router port forward usually cannot make your service reachable from the open internet over IPv4. Outbound traffic still works. Inbound “call me on this port” does not, because outsiders hit a shared public address that the ISP does not forward to your modem for arbitrary ports.
A consumer VPN alone does not fix that. It changes the exit sites see when you browse; it does not open inbound ports on your CGNAT home path.
How a normal port forward is supposed to work
Without an extra ISP NAT layer, a classic home setup looks like this:
- Your router has a unique public IPv4 on the WAN.
- You map an external port to a LAN device (camera, NAS, game host).
- Someone on the internet sends packets to
your-public-ip:port. - Your router matches the rule and delivers them inside.
The critical assumption: the public address outsiders use is the same address your router owns on the WAN, and the ISP delivers those packets to your line. That is the public vs private split working as people expect — private LAN inside, one public face outside.
Where CGNAT breaks the inbound path
With carrier-grade NAT, the ISP puts many customers behind one shared public IPv4. Your router’s WAN is often Shared Address Space (100.64.0.0/10) or another non-unique address. Websites still see a normal-looking public IP — the ISP’s shared exit — when you browse. That is fine for outbound.
Inbound is different:
| Hop | What happens on CGNAT |
|---|---|
| Remote user | Sends to the shared public IPv4 + port |
| ISP CGNAT | Owns that public address for many subscribers; has no per-customer map for your arbitrary forward |
| Your router | Never receives the unsolicited packets for that port |
| Your service | Stays unreachable from outside |
Your router rule only controls traffic that already arrives at your WAN. Under CGNAT, those packets often never leave the ISP’s shared edge toward you. The forward “succeeds” in the admin UI and still fails in the real world.
Compare the public address on What Is My IP with your router WAN. On CGNAT they frequently disagree. Naming the provider on the exit with ISP Lookup helps a support ticket; it does not make the inbound map appear.
Symptoms people actually hit
These are common when the line is CGNAT (or double NAT — same family of pain):
- Port-check sites report the port closed or filtered after a correct router rule
- Game hosts show strict / Type 3 NAT; joining others works, hosting does not
- Remote camera / NAS apps fail unless they use a vendor cloud relay
- “Hairpin” tests from home look fine; a phone on mobile data cannot connect
- UPnP or “automatic port mapping” never sticks because the ISP layer ignores it
Outbound browsing, streaming, and apps you initiate still feel normal. That mismatch — everything works out, nothing answers in — is the classic CGNAT inbound story.
Rule out a second home router first (modem + Wi‑Fi router both NATing). Then run the CGNAT home check. If WAN sits in 100.64.0.0/10 on a single-router setup, treat ISP CGNAT as likely.
What does not fix inbound on CGNAT
Honest list, because these get recommended constantly:
- Re-saving the same port forward — the rule is not the missing piece
- DMZ to one PC — still only helps traffic that reaches your router
- Disabling the router firewall alone — does not create an ISP-side inbound map
- A consumer VPN client — sites see the VPN exit; your home IPv4 stays unreachable for inbound. Details: what a VPN changes on your IP
- “Static IP” language without asking “unique public IPv4?” — some “static” products are stable within CGNAT and still shared. Ask for a unique public assignment, not only a lease that does not rotate. Related: static vs dynamic IP at home
If the path is CGNAT, local router tweaks rearrange furniture in a room the mailman never enters.
What actually restores inbound reachability
Pick the fix that matches the goal:
- Ask the ISP for a unique public IPv4 (often a paid public/static add-on). Confirm in writing that it is not still CGNAT. Recheck WAN vs What Is My IP after it lands.
- Use IPv6 when the ISP gives a global prefix and the remote side supports it. Some plans are CGNAT on IPv4 while IPv6 is end-to-end reachable.
- Prefer vendor relays / cloud for cameras, NAS, and similar — many products already assume CGNAT and never need a raw forward.
- Tunnel or VPS when you truly need an inbound endpoint you control (you connect out to a machine that is reachable). That is a product choice, not a free router checkbox.
- Stop needing inbound when the use case allows — outbound sync, push, or a hosted service may be enough.
Do not buy an add-on until you know you are on CGNAT (or double NAT). The detection guide and the CGNAT overview exist so you ask the ISP the right question once.
Bottom line
Port forwarding fails on CGNAT because the shared public IPv4 is not a door to your house. Outsiders knock on an ISP address that is not mapped to your router for arbitrary ports. Fix the path (unique public IPv4, IPv6, relay, or tunnel) — or accept that inbound IPv4 was never part of the plan. A VPN for privacy is a separate tool; it does not open home ports on a CGNAT line.