The failure always looks the same. A service is running on a machine at home, the port forward is configured on the router, the firewall rule is there, and from inside the house everything answers. From anywhere else the service does not exist. Connections time out rather than getting refused, which rules out most of the usual suspects, and every troubleshooting guide sends you back to a router page where the settings are already correct.
At that point the problem is usually not on your side of the wire. Your provider has put a second layer of address translation between your router and the internet, and on that layer you have no configuration at all. The technique is called carrier-grade NAT, usually shortened to CGNAT or CGN, and it changes something fundamental about the connection: the address your router holds is not an address anyone can send packets to.
Your router never had a public address
A home router has always done address translation. One public IPv4 address arrives from the provider, and every phone, laptop and console behind it shares that address through NAT. Port forwarding works in that arrangement because the router owns the public address. When a packet arrives for TCP port 25565, the router has been told which internal machine should receive it, and it rewrites the destination accordingly.
Carrier-grade NAT inserts a second translation before that. Instead of a public address, the provider hands your router an address from an internal pool, then translates the traffic of many subscribers onto a smaller set of public addresses at its own equipment. The industry name for the two-layer arrangement is NAT444, because a packet is translated twice on its way out.
The IETF allocated a dedicated range for the subscriber-facing side of this in RFC 6598, published in April 2012: 100.64.0.0/10, running from 100.64.0.0 to 100.127.255.255. A separate block was needed because providers were already using RFC 1918 space internally, and a subscriber whose home network sat on 192.168.1.0/24 would collide with a provider using the same range. The RFC is unambiguous about what this space is for, and about what it is not: "Packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links."
So the port forward on your router is not broken. It is forwarding traffic that arrives at an address the rest of the internet is required to discard.
How to check in about a minute
Three observations settle it, and none of them need special tools.
- Read the WAN address on your router. It appears on the status or internet page of the admin interface, usually labelled WAN IP, internet address, or public address.
- Compare it with your address as seen from outside. Any site that echoes back the source address of the request will do. If the two values match, your router holds a public address and CGNAT is not in the path.
- Read the range. A WAN address between 100.64.0.0 and 100.127.255.255 is shared address space and means carrier-grade NAT by definition. Some providers use 10.x.x.x, 172.16.x.x through 172.31.x.x, or 192.168.x.x on the WAN side instead, which points the same way.
A traceroute adds confirmation. Behind a CGN the first few hops are private addresses before anything routable appears, which is the provider's internal network on the way to its translation equipment.
Mobile and fixed-wireless connections are the awkward case, since there is often no router page to read. There the address reported by the device, or by the modem's own status screen, is what to compare against an external lookup.
A matching public address today is not a guarantee for next month. Providers commonly migrate subscribers to CGNAT in batches, and new customers are frequently placed behind it while long-standing ones keep the public address they already had.
How likely this is to be you
The most thorough public measurement of the practice remains a 2016 study presented at the ACM Internet Measurement Conference, which combined crawls of the BitTorrent DHT with instrumented client tests so that two independent methods had to agree. Looking only at networks that primarily connect end users, it found carrier-grade NAT in 18.0% of fixed networks and 94.2% of cellular ones.
Two practical rules follow from that split. If the connection is mobile, fixed-wireless or satellite, assume carrier-grade NAT until a check proves otherwise. If it is fibre or DSL, it depends heavily on the operator and on when you signed up, so the check is worth running rather than guessing.
The same study surveyed providers directly and found 38% already operating CGNs with a further 12% considering it, and noted that most deployments are partial rather than network-wide. That partial quality is what makes the experience so inconsistent between two customers of the same company.
Why the provider cannot simply give you a port
The instinct is to ask the provider to forward a port. Understanding why that request usually goes nowhere makes the rest of the options easier to judge.
A public IPv4 address has 65,536 TCP ports and the same number of UDP ports. A carrier-grade NAT divides that budget among the subscribers sharing the address, typically by handing each one a fixed chunk. The 2016 measurements recovered real chunk sizes from live networks and found them ranging from 512 ports up to 16,384, with three of the observed networks sitting at the bottom of that range. The arithmetic that follows is simple division.
Those ports are the ephemeral source ports used for outbound connections, and even for ordinary browsing the budget is tighter than it looks. The study's authors call 512 ports "a scarily small number given that loading a single Web page can result in many dozens of TCP connections".
Inbound is a different problem, and a harder one. A well-known port is not divisible. There is exactly one TCP port 443 on a given public address, and if a hundred subscribers sit behind that address, at most one of them can own it. RFC 7021 puts the constraint plainly: some applications "try to open a particular fixed port through the CGN; while service will work for a single subscriber behind the CGN, it fails when multiple subscribers try to use that port."
Standards did anticipate the need. RFC 6888, published as BCP 127 in April 2013, states in REQ-9 that "a CGN MUST implement a protocol giving subscribers explicit control over NAT mappings", and recommends the Port Control Protocol for the job. Thirteen years later the requirement is largely unmet on consumer networks, and even where PCP is available it allocates a port from within your chunk rather than the one your service needs.