What Is CGNAT? Why Port Forwarding Fails and How to Work Around It

When a Correct Port Forward Still Goes Nowhere

Your NAS opens normally at home. The service is running, and the port-forwarding rule points to the right local address. Then you switch your phone to mobile data, try again, and get a timeout. The same pattern can affect a home game server, VPN server, CCTV feed, or self-hosted app.

The fast answer is that the rule may be correct but sit behind another boundary. With Carrier-Grade NAT (CGNAT), the ISP shares public IPv4 addresses and makes the first inbound decision upstream. You control the rule on your home router, but a new internet connection never reaches it unless the provider’s translator knows where to send it.

That does not prove CGNAT is responsible; local problems can look identical. The service may listen only on localhost, or a host firewall may block it. A router rule may use the wrong TCP/UDP protocol or an outdated target address, while a second local router may add another boundary. First identify the boundary, distinguish CGNAT from ordinary and double NAT, then choose a workaround for the access you need.

Quick Keywords: What CGNAT Is and Why ISPs Use It

These terms are enough to follow where that missing connection stops.

RFC 6888 defines a Carrier-Grade NAT (CGN)—also called Large-Scale NAT (LSN)—as a provider-side function that lets multiple subscribers share an IPv4 address. Subscribers do not manage it. “Carrier-grade” describes placement and scale, not higher quality.

The ownership boundary looks like this:

YOU CONTROL                         ISP CONTROLS
device → home router / NAT → ISP CGNAT → shared public IPv4 → internet

The home router controls the customer’s local network. The ISP’s CGN maps subscriber connections to its shared public address. Normal browsing still works because a device starts the conversation and both translation layers can track the reply.

Think of the public IPv4 address as a building’s street entrance and a port as a buzzer. Your router is the inner reception desk. CGNAT adds an outer desk shared by many customers and operated by the ISP. Ports help that outer desk track active conversations; they do not give each customer permanent ownership of every buzzer on the shared address.

ISPs use this design because globally routable IPv4 space is constrained and the IPv6 transition remains incomplete. Regional free pools are effectively exhausted, although existing addresses can still be transferred and reused. CGNAT preserves IPv4 compatibility by sharing scarce addresses. IPv6 provides the larger long-term address space, but it is not available end to end everywhere.

NAT vs Double NAT vs CGNAT

The decisive questions are not “How many boxes do I see?” but “Where does translation happen, and who can change it?”

📝 Note: CGNAT often results in two IPv4 NAT layers when a home router is present, but “CGNAT” names the ISP-operated function while “double NAT” only describes the topology.

That ownership distinction changes what you can fix. With two local gateways, you may be able to use bridge/AP mode or configure both layers. A provider translator sits outside those controls, and some CGNAT designs do not include a second customer-operated translator at all.

Console labels such as “open,” “moderate,” or “strict NAT” are separate. They summarize connectivity behavior for that platform; they do not identify who owns the translators or prove that CGNAT exists.

Why Port Forwarding Fails Behind CGNAT

Outbound traffic works because each translator creates state: a temporary record linking an internal flow to an external address and port. When your device starts a request, the home router and ISP CGN each record it, allowing matching replies to return.

A new inbound connection has no such state. It reaches the ISP’s shared public IPv4 first, where the CGN has no subscriber-specific mapping:

OUTBOUND WORKS
device → home NAT [state created] → ISP CGN [state created] → internet
device ← home NAT [state match]   ← ISP CGN [state match]   ← reply

NEW INBOUND CONNECTION STOPS
outside user → shared public IPv4 → ISP CGN
                                      X — no subscriber mapping
                                      home router is never reached

That is why CGNAT port forwarding fails. Your home-router rule may be valid, but it belongs to the inner reception desk. Changing that desk’s visitor list cannot tell the ISP’s shared outer desk which subscriber should receive an unexpected visitor. The packet never reaches your rule.

A reverse proxy on the unreachable home side does not change this. It can organize requests after they arrive, but it cannot create the missing route. A reverse tunnel—or a proxy or relay at a reachable edge—is different because the private side establishes an outbound path first.

How to Tell Whether You Are Behind CGNAT

Use the evidence in this order:

1. Disable VPNs and proxies. Turn off anything that changes the public address from which your traffic appears to leave.
2. Identify the ISP-facing gateway. Use the router or modem directly connected to the provider, not a second router farther inside your network.
3. Compare the two addresses. Note that gateway’s WAN or Internet IPv4 address, then use an external service to view your public IPv4 at the same time.

❗ Important: A mismatch between the WAN and public addresses proves that an upstream translation boundary exists, not automatically that it is CGNAT. Make this inference only from the gateway directly connected to the ISP.

4. Interpret the result. Use these signals together:
   • A WAN address in 100.64.0.0/10—100.64.0.0 through 100.127.255.255—is strong CGNAT evidence. RFC 6598 reserves this non-globally routable Shared Address Space for provider use; it is not RFC 1918 private space.
   • An address in 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 also shows a non-public WAN, but it may belong to another local router.
   • Different WAN and public addresses indicate upstream translation. Matching globally routable addresses make ordinary IPv4 CGNAT much less likely on that path.
5. Rule out local causes. Before calling it CGNAT, check that:
   • The service listens on its LAN address, not only on localhost.
   • The host firewall permits the intended port and protocol.
   • The router rule targets the current internal address and correct TCP/UDP choice.
   • A second local router is not adding another translation layer.
   • The test comes from mobile data or another genuinely external network.
6. Confirm with the ISP. Traceroute can support the diagnosis when shared or private hops appear beyond the home gateway, but hidden hops make it inconclusive. Ask the provider whether the line uses CGNAT and whether a dynamic or static public IPv4 is available.

What CGNAT Affects—and What It Usually Does Not

That outbound/inbound split determines what users notice. Browsing, streaming, downloads, and most app clients usually work normally. Problems appear when an outside system must start a new connection to something behind the carrier boundary.

Direct IPv4 hosting and remote access therefore need another reachable path. On a private network, this affects access to a NAS, CCTV system, or internal dashboard. Public websites, webhook receivers, and game servers face the same ingress requirement. A VPN client normally works because it connects outward. A home VPN server is different because remote users start the connection, so it needs reachable ingress, compatible IPv6, or an endpoint on a relay or public host.

Peer-to-peer gaming, voice, and file sharing are less predictable. Some applications find a direct route, while others use a relay through a reachable intermediary. A relay may preserve connectivity at the cost of added latency. When traversal fails, the application may report restrictive NAT or fail to connect. RFC 7021 documents these pressure points without implying universal failure.

Sharing an IPv4 address can merge unrelated subscribers into one reputation. One user’s behavior may cause other subscribers to see more CAPTCHAs or rate limits. The shared address may also land on blocklists, trigger simultaneous-login restrictions, or produce coarse geolocation. A shared or changing residential exit further complicates business allowlists that expect a stable endpoint.

📝 Note: Blocking unsolicited inbound IPv4 by default can reduce accidental exposure, but CGNAT is not a firewall and does not replace authentication, updates, TLS, or access policy.

CGNAT does not stop malicious outbound traffic. It does not secure applications exposed through another path or control who can sign in. A tunnel, public IP, or IPv6 route still requires deliberate security controls.

Five Ways to Work Around CGNAT

The five options solve different access problems. Private meshes, managed tunnels, and VPS relays share one useful pattern: the private side connects outward first.

private service → outbound mesh / tunnel link → reachable edge ← outside user

In the building analogy, you either obtain a usable street entrance or maintain a line to an entrance elsewhere.

📝 Note: “Bypass” is shorthand. These approaches do not disable the carrier NAT; they obtain another public edge, use end-to-end IPv6, or establish an outbound-created path.

Start with the table, then use the details below for the tradeoffs that matter to your setup.

1. Ask the ISP for a Public IPv4

For general inbound IPv4, this is usually the simplest option when the ISP offers it. A dynamic public IPv4 works with updated DNS. Choose a static public IPv4 for stable allowlists, records, or VPN endpoints. Check availability and cost, and secure any service you expose directly.

2. Use Native IPv6

IPv6 traffic avoids IPv4 CGNAT. Direct access requires a global prefix, an IPv6 listener, suitable firewall rules, correct DNS where needed, and IPv6 on the remote side. It does not help IPv4-only clients or expose a service automatically.

3. Build a Private Mesh

A mesh VPN such as Tailscale suits trusted users and devices that can run authenticated client software. It tries direct connections, then may fall back to a peer or DERP relay with some performance cost. It is not intended for anonymous visitors or public webhooks.

4. Publish Through a Managed Outbound Tunnel

A service such as Cloudflare Tunnel connects the origin outward to a provider edge. This works well for web apps, APIs, demos, and controlled private access. Public HTTP visitors may need no client, while private or non-web modes may require provider software. Protocol support, identity, limits, and edge availability remain provider dependencies.

5. Use a VPS as the Public Edge—or Move the Workload

A VPS can relay traffic through an outbound tunnel from home, or host the application directly when it does not need home-LAN data or hardware. This offers a stable endpoint and broad TCP/UDP control. You become responsible for security, monitoring, tunnel reliability, bandwidth, abuse handling, and added latency. An appropriately selected AlexHost VPS can fill this role, subject to its public addressing and network policy.

Which Option Fits Your Use Case?

Choose the architecture by asking four questions in order:

1. Is access limited to trusted people and devices, or open to the public?
2. Can every connecting device install and authenticate through client software?
3. Is the service web-based, or does it require arbitrary TCP/UDP behavior?
4. Do you prefer managed convenience or control of the public gateway?

For trusted NAS, CCTV, or admin access, use a mesh VPN when users can install client software. For public web endpoints and webhooks, use a managed tunnel or public hosting. Move the workload if it does not need the home LAN.

For public TCP/UDP, use an ISP public IPv4, a VPS edge, or IPv6 when all clients support it. Game hosting is title-specific: check its server model, traversal support, and protocols. A generic tunnel cannot promise a better console NAT label.

A public VPN endpoint needs public IPv4, working IPv6, or a VPS host. For business ingress or partner allowlists, choose a static address or controlled gateway instead of a shared residential exit.

Common CGNAT Questions and Misconceptions

Is CGNAT the same as double NAT? No. CGNAT identifies an ISP-operated, multi-subscriber NAT. Double NAT only means that traffic crosses two translators.

Does CGNAT always slow the internet? No. Performance depends more on the provider, application, and whether a relay is involved.

Can dynamic DNS fix CGNAT? No. It tracks a changing address but cannot create an upstream mapping. It helps once you have a reachable dynamic public address.

Does a normal VPN bypass CGNAT? Usually not. It works only when the VPN service provides inbound forwarding, a private overlay, or another reachable entry point.

Can IPv6 solve it? Yes, when both ends have IPv6 and the firewall and DNS permit it. It does not help IPv4-only clients.

Is 100.64.0.0/10 private space? It is special-use, non-globally routable Shared Address Space. It is distinct from the RFC 1918 private ranges used in ordinary local networks.

Is CGNAT a security feature? No. Its inbound behavior is not a security policy. You still need firewall rules, authentication, patching, encryption, and careful exposure.

The Bottom Line: Fix the Missing Public Edge, Not Just the Router

The opening NAS or game server can have a correct local rule and still time out because the connection stops at the ISP boundary. More router changes will not fix a path the router never receives. Start with the audience: use a mesh for trusted private access, while public access needs public IPv4, working IPv6, a managed tunnel, or a controlled host. Check the ISP’s options first, then consider an AlexHost VPS only when a hosted workload or relay fits the design.