CGNAT, or carrier-grade NAT, is address translation operated by an internet provider so multiple subscribers can share public IPv4 addresses. It can prevent ordinary home-router port forwarding from accepting new internet connections because your router does not control the provider's upstream mapping.［1］［2］

Key Takeaways

A home-router rule controls that router, not the ISP's NAT.

A WAN address in 100.64.0.0/10 is a useful clue, not sufficient proof by itself.［1］

Double NAT, a VPN exit and an inbound firewall can produce similar symptoms.

Public IPv4, working end-to-end IPv6 or a controlled relay address different parts of the problem.

How does carrier-grade NAT change the connection path?

A typical home router translates private device addresses into its WAN address. With CGNAT upstream, the provider translates that WAN-side connection again into a public IPv4 address shared with other subscribers. The two translations have separate state and separate administrators.

For example, your laptop might use 192.168.1.20, while the router receives 100.64.12.34 on its WAN interface. The provider then exposes a different public address to the remote service. These are illustrative addresses, not a measured connection or a recommended configuration.

The diagram shows an outgoing connection creating state through both NAT layers. Replies that match that state can return to the device; a new inbound connection without an applicable mapping cannot simply be delivered to your chosen home server. This explains why ordinary browsing can work while hosting fails.

What is the address actually telling you?

RFC 6598 reserves 100.64.0.0/10 as Shared Address Space, distinct from RFC 1918 private space. The range runs from 100.64.0.0 through 100.127.255.255; an address elsewhere in 100.x.x.x is not automatically part of it. Shared space is not globally reachable as an ordinary public address.［1］

Do not confuse an address on the laptop with the router's internet-facing address. A private LAN address is normal and says little about the ISP's upstream design. The guide to address categories explains why private, shared, public and static describe different properties.

The VPN foundations overview provides the separate tunnel model. NAT translates network addresses and ports; a VPN carries traffic through another path. Neither term alone says that an outside device can initiate a connection to your home machine.

Why does CGNAT port forwarding fail?

A port-forwarding rule on your router tells it what to do with matching traffic that reaches its WAN interface. With an upstream CGN, a packet addressed to the shared public IPv4 first reaches equipment owned by the ISP. Without an applicable provider mapping, it may never reach your router at all.

That creates an administrative boundary. You can control the home rule, device firewall and listening service, but not an arbitrary upstream mapping. Repeating the same rule or choosing another local port does not create permission on the provider's device.

Replies are different from new connections

An outbound game client or browser creates a connection from inside the network. NAT can remember enough information to return the remote peer's replies. Hosting a service asks an unrelated outside client to begin a new connection, so it needs a reachable address and an accepted inbound path.

Some applications negotiate connectivity or use a relay instead of requiring simple inbound forwarding. Their success does not demonstrate that every port is reachable. Likewise, a failed game invitation does not prove CGNAT: an application server, firewall or another NAT layer may be responsible.

RFC 6888 includes requirements for CGN behavior and subscriber control of mappings. A provider may offer a supported mapping mechanism or another service option; the standard does not promise that every subscriber can configure one. Ask what your ISP actually implements rather than describing all CGN deployments as permanently unchangeable.［2］

Router features stop at the router

UPnP or a manually configured forward may affect only the home router. A “DMZ host” setting there does not eliminate upstream NAT and can expose more of the local device if public reachability later becomes available. Disabling a firewall is therefore a poor substitute for finding the missing boundary.

The gaming port-forwarding discussion covers when a game's inbound requirement justifies a narrow rule. First establish that the required packet can reach the router; then use the game's documented protocol and ports, rather than opening a broad range speculatively.

How can you distinguish ISP NAT from similar problems?

Compare the router's actual WAN IPv4 with the internet-visible IPv4 using the same connection and the same address family. Use your router's status page and check the current internet-visible address while a VPN or proxy is disconnected for this diagnostic comparison. If you cannot disconnect a managed tunnel, record that limitation instead of treating its exit as the ISP address.

A mobile hotspot, a second router or an ISP modem/router can add another translation. Draw the devices you physically control before concluding that a mismatch belongs to the provider. Read-only status information is enough for the first comparison; do not change bridge mode or erase router settings just to gather a clue.

Clue	What it cannot prove	Next confirmation
WAN IPv4 is in `100.64.0.0/10`	Which equipment or administrator uses the shared range	Ask the ISP whether the connection uses CGN and what inbound options exist
WAN IPv4 is RFC 1918 private space	That the ISP, rather than another home router, performs NAT	Inspect the upstream modem/router and confirm the topology
WAN IPv4 differs from visible IPv4	That the difference is CGN rather than a VPN, proxy or another NAT	Repeat without an optional tunnel and compare the same IPv4 path
WAN and visible IPv4 match	That a service is listening or the ISP allows inbound traffic	Check service binding, router rules and both firewalls
IPv6 works while IPv4 hosting fails	That IPv6 peers can reach the service through its firewall	Confirm a global address, listener and authorized outside IPv6 test
Traceroute contains private addresses	A definitive boundary or mapping policy	Treat it as supporting context and obtain provider confirmation

An address comparison is a clue, not a complete port test. A checker cannot find a service that is stopped, bound only to loopback or listening on a different protocol. UDP and TCP are separate tests; an empty UDP response is especially easy to misinterpret.

Avoid testing the wrong path

Testing your own public address from inside the home network can depend on router loopback support. A local failure may therefore differ from the result for a genuine outside client. Use an authorized external connection for the specific service, and limit the test to equipment you own or have permission to administer.

Record the router WAN address, visible address, date, access type and upstream devices privately. Avoid publishing screenshots containing account identifiers, router credentials or a complete administration page. An ISP support ticket can use a concise topology description without exposing sensitive details to a public forum.

What does CGNAT affect in games and remote access?

It commonly matters when an application needs a new inbound connection: hosting a game server, accepting a peer session or reaching a home service remotely. Browsing, streaming and other outbound uses can work because their return traffic matches existing state. Different applications handle that boundary differently.

A “strict NAT” label is an application-specific result, not a diagnosis of the provider's network. If you only join a hosted game, a direct inbound path may not be required. If you host, check the application's connectivity model and whether a relay or managed server is available before buying a different connection.

Separate reachability from performance

Opening a port does not automatically lower ping, remove Wi-Fi interference or increase bandwidth. A hosted service can be reachable and slow, or unreachable with an otherwise fast connection. The PC NAT troubleshooting sequence helps keep platform-specific failures separate from this address-sharing explanation.

At the VPN boundary, AethoVPN forwards outgoing traffic through an encrypted connection; that changes the path used for internet access, but is not a promise of a public inbound address or a configurable forwarding port. The VPN port-mapping explanation shows why inbound support must be an explicit provider feature rather than an assumption about a tunnel.

If an ISP confirms CGNAT but the application still works through a relay, there may be nothing to change. Choose a remedy for the required task rather than trying to obtain an “open” label as an end in itself. Keep the application's own server status and account permissions in the diagnosis.

Which alternatives fit your inbound requirement?

Select the smallest option that supplies the required reachability. None removes the need for authentication, updates and firewall rules on the exposed service. A public address is a routing capability, not evidence that a home device is safe to publish.

Option	Required condition	Boundary and risk
ISP public IPv4 or CGN opt-out	Provider offers a reachable address and permits inbound traffic	Router and host firewall still apply; a dynamic address can change
Provider-supported mapping	ISP exposes a documented mapping service	Ports, lifetime and protocol may be restricted
End-to-end IPv6	Both peers and the service support IPv6	Explicit inbound firewall permission remains necessary
Controlled relay or overlay	Both ends can establish allowed outbound connections	Trust, authentication, access controls and relay availability matter
Hosted server	The application can run on a suitable remote host	Separate administration, costs and exposure replace the home-host task

Public IPv4 does not have to mean static IPv4

Ask whether the address is publicly reachable and whether inbound traffic is allowed. A static address is convenient for a stable endpoint, but a dynamic public address can also support inbound access with suitable discovery. A static shared or private address still leaves the upstream boundary unresolved.

Do not order an upgrade solely because its name contains “static.” Describe the service you need to host and ask about protocol, port restrictions and acceptable use. After a change, verify the actual WAN path rather than relying only on the sales label.

IPv6 and relays require their own review

IPv6 can avoid the IPv4 CGN path when both peers have usable connectivity and the service listens on IPv6. A global IPv6 address does not bypass a firewall, and an IPv4-only remote client cannot directly use it. Expose only the needed service, keep authentication and encryption, and revoke temporary access afterward.

A controlled relay lets the home device initiate an outbound connection that a trusted service uses to carry authorized remote access. Review who operates it, who can join, where credentials are stored and how access is revoked. Prefer a service-specific permission over publishing the entire home network.

If the ISP offers no suitable option and the application has no supported relay, stop router experimentation and choose a different hosting arrangement. Keep a record of changes and remove speculative forwarding rules once the diagnosis is complete.

Summary

CGNAT adds a provider-controlled translation upstream of your router.
Compare WAN and visible IPv4, then confirm topology and policy with the ISP.
A home rule cannot configure an arbitrary upstream mapping.
Match public IPv4, IPv6 or relay options to the actual service and retain security controls.

FAQ

Is CGNAT the same as double NAT?

CGNAT is provider-operated address sharing; double NAT describes multiple translation layers. Two routers at home can create double NAT without proving that your ISP also uses CGNAT.

Does every address starting with 100 indicate CGNAT?

No: RFC 6598 reserves only 100.64.0.0/10, ending at 100.127.255.255, for shared space. Even an address in that range needs topology and provider confirmation before you assign the cause.［1］

Can a home-router forward work through CGNAT?

A local forward alone cannot create the ISP's mapping. It can be useful if the provider also supplies a supported inbound arrangement, which you must confirm rather than assume.［2］

Does matching WAN and public IPv4 prove a port is open?

Matching addresses removes one clue for upstream translation, but does not prove a listener or firewall permission. Check the service, protocol, router rule and an authorized outside test separately.

Will a VPN automatically solve the inbound problem?

An ordinary outbound tunnel is not a public port-mapping entitlement. Only a service with explicitly supported inbound reachability can supply that part of the path, and host security still applies.

Should I disable the firewall or use DMZ?

Those changes do not remove provider NAT and can expand exposure. Diagnose the upstream boundary first and allow only the documented service through the necessary firewall when the path is established.

Can IPv6 avoid CGNAT?

A working end-to-end IPv6 path can avoid IPv4 CGN translation. Both peers and the service must support it, and the inbound IPv6 firewall must permit the intended connection.

Is CGNAT responsible for slow internet?

CGNAT is primarily an address-sharing and reachability issue in this diagnosis. A slow connection needs separate evidence about network load, Wi-Fi, routing and the application; a NAT label alone does not identify its cause.

Disclaimer: The addresses and topology are explanatory examples, not measurements of your connection. Confirm provider policy and secure any service you expose; this article is general technical information.

Sources:

Sources checked 5 October 2026.

Related Articles:

What Is CGNAT, and Why Does It Break Port Forwarding?