Strict or moderate NAT type? What it means and how CGNAT affects it
Game consoles and voice or video apps often report a "NAT type": open, moderate or strict. If yours says strict or moderate no matter what you change on your router, your ISP's CGNAT may be the reason.
What "NAT type" is measuring
Those labels aren't an internet standard. Each platform defines its own, but broadly they answer one question: can other players or callers start a connection to you, or only you to them? "Open" usually means others can reach you directly. "Strict" usually means they mostly can't, so some matches, parties or calls fail or have to go through a relay.
The standard behind it describes two NAT behaviors (RFC 4787, section 4.1 and section 5):
- Mapping: does the NAT keep using the same public port when your device talks to different servers? Keeping it the same ("endpoint-independent mapping") is a requirement of that standard, and it helps apps connect peer to peer.
- Filtering: what does the NAT let in? The most open behavior lets anyone reach a port once your device has sent something out from it. Stricter behaviors only let in replies from the exact address (or address and port) you contacted. The standard recommends the open behavior when apps working smoothly matters most, and names gaming as an example.
Why CGNAT makes it worse
- Two NATs instead of one. Your router does NAT, and the ISP's CGNAT does it again. The stricter of the two decides what gets in, and you can only change your own router.
- Port forwarding stops at the ISP. On a normal line, forwarding a port (or letting the router open one automatically) is how you get to "open". Behind CGNAT, the port would also have to be opened on the ISP's NAT, which only the ISP controls (RFC 6269, section 5.2.1).
- Some apps still fail even with a well-behaved CGNAT. An operator test found that apps which wait for incoming traffic without sending first, or which insist on one fixed port, failed behind CGNAT; peer-to-peer gaming between two homes on the same ISP couldn't connect (RFC 7021, section 3.1).
The IETF's requirements for carrier-grade NAT recommend the more open filtering behavior (RFC 6888, section 3), but how each ISP configures its CGNAT isn't something you can see or change.
Check whether CGNAT is the cause
Compare your router's WAN address with your public IP using the CGNAT checker or the step-by-step guide. A WAN address in 100.64.0.0/10 means CGNAT (explainer). If your router does have a public IP, the NAT type is up to your own router and its port settings, not the ISP.
What to ask your ISP
- "Can you move my line off CGNAT and give me my own public IPv4?" With a public IPv4, your own router's settings decide the NAT type again.
- "Do you sell a static IP on residential plans?" A static IP is always your own.
- "Is IPv6 available and turned on?" IPv6 has no CGNAT in the path. It helps with players and services that also use IPv6.
See which providers don't use CGNAT, filter the ISP finder by state, or read hosting a game server behind CGNAT.
FAQ
What does strict NAT mean?
Platforms define their own labels, but strict NAT broadly means other players or callers can't start a connection to you, so some matches, parties or calls fail or go through a relay. Open NAT means they can reach you directly.
Can CGNAT cause strict or moderate NAT?
Yes. CGNAT adds a second NAT at your ISP that you can't configure, and port forwarding on your router doesn't reach through it. That often leaves you stuck at moderate or strict whatever you change at home.
How do I get open NAT behind CGNAT?
Over IPv4, you need your ISP to move you off CGNAT to a public IPv4 or sell you a static IP. IPv6, if your ISP offers it, avoids the CGNAT for players and services that also use IPv6.
How do I know if CGNAT is the cause?
Compare your router's WAN IP with your public IP. If they differ, or the WAN IP is in 100.64.0.0/10, you're behind CGNAT. If they match, the NAT type depends on your own router's settings.
Sources
- RFC 4787: NAT Behavioral Requirements for Unicast UDP (IETF, January 2007)
- RFC 6888: Common Requirements for Carrier-Grade NATs (IETF, April 2013)
- RFC 6269: Issues with IP Address Sharing (IETF, June 2011)
- RFC 7021: Assessing the Impact of Carrier-Grade NAT on Network Applications (IETF, September 2013)
This site sticks to ISP facts. It doesn't review or recommend third-party products or services.