"NAT type: Strict" is one of the most common support tickets an ISP running CGNAT will see. A games console or a VoIP app reports the NAT as Open, Moderate or Strict, and the subscriber blames the connection. The label hides two separate questions, and sorting them out is the difference between a fix and a week of guessing.
Mapping and filtering are different things
RFC 4787 describes NAT behaviour as two independent properties, and a console's "NAT type" is really a summary of both.
- Mapping is what external address and port the NAT gives an internal flow. With endpoint-independent mapping (EIM), one internal
(ip, port)always maps to the same external(ip, port)no matter which destination it talks to. That predictability is what lets STUN and ICE, the discovery protocols games and VoIP use, learn a reachable address for the peer to connect back to. - Filtering is whether the NAT lets an inbound packet through from a remote the subscriber has not already contacted. With endpoint-independent filtering (EIF), once an internal host has sent anything out, any external host can reach it on that mapping.
"Full-cone" NAT is EIM plus EIF. It is what consoles call Open, because the external address is predictable and peers can reach it.
| Mapping | Filtering | Console reports | Peer-to-peer |
|---|---|---|---|
| Endpoint-independent (EIM) | Endpoint-independent (EIF) | Open | Works |
| Endpoint-independent (EIM) | Address/port-dependent | Moderate | Works with a cooperating peer |
| Address/port-dependent (symmetric) | Any | Strict | Often fails |
What Netavo's CGN does
Netavo's CGN implements endpoint-independent mapping and endpoint-independent filtering, and it hairpins. In plain terms: a subscriber's outbound flow keeps a stable public address and port, remote peers can connect back to it, and two subscribers sharing the same public address can reach each other directly through it. That is the permissive, full-cone behaviour that gaming and VoIP want from the carrier NAT.
So if the carrier NAT is doing its job, why do subscribers still see Strict? Because the CGN is only one of two NATs in the path.
The CPE is the other NAT
Almost every subscriber has a NAT in their own router. A console sits behind the CPE, which sits behind the CGN. The console's reported NAT type is the combination of both, and a Strict result very often comes from the CPE, not the carrier. A home router in a symmetric NAT mode, or with UPnP disabled, produces a Strict result even when the CGN upstream is full-cone.
This matters for triage. Before you touch the CGN, establish whether the subscriber's own router is the limiting NAT. A quick way is to compare two subscribers on the same CGN egress pool: if one reports Open and the other Strict, the difference is in the home, not the carrier.
Timeouts and port budget
Two CGN settings still affect gaming and VoIP even with full-cone behaviour:
- UDP mapping timeout. A game session or a call holds a UDP mapping open with keepalives. If the CGN ages the mapping out faster than the application refreshes it, the session drops mid-game or the call goes one-way. The UDP idle timeout needs to be comfortably longer than the application's keepalive interval.
- Port budget. Each subscriber has a block of ports on the public address. A household with many simultaneous flows can exhaust its block, and new mappings then fail, which looks exactly like a NAT problem. The port-block sizing that sets your address-sharing ratio also sets this ceiling (see the note on CGNAT port-block maths).
A diagnostic matrix
| Symptom | Likely cause | Check |
|---|---|---|
| Console reports Strict | CPE NAT, not the CGN | Compare two subscribers on the same egress pool |
| One-way audio on VoIP | Filtering or mapping on the CPE; or UDP timeout | CPE NAT mode; CGN UDP idle timeout vs keepalive |
| Game session drops after idle | UDP mapping aged out | Lengthen the CGN UDP idle timeout |
| New connections fail under load | Port-block exhaustion | Per-subscriber port-block occupancy |
| Cannot host a server / accept unsolicited inbound | No static inbound without a prior outbound | Offer IPv6 or a dedicated public IPv4 |
When CGNAT is not the right answer
Full-cone CGNAT makes peer-to-peer connectivity work, but it does not give a subscriber a stable, publicly reachable address for unsolicited inbound traffic, the kind you need to host a game server or reach a home CCTV system without a relay. Netavo's CGN does not ship operator static port-forwards or PCP, so the honest answer for a customer who genuinely needs inbound reachability is a different one: give them IPv6, where every device has a routable address, or a dedicated public IPv4. CGNAT is the right default for the many; a routable address is the right tool for the few.
Before changing anything on the CGN, rule out the CPE. The single most common cause of a Strict result on a full-cone carrier NAT is the subscriber's own router, and no amount of CGN tuning will fix a symmetric NAT in the home.
Test it on your own pool
The free evaluation build runs the production CGN with endpoint-independent mapping, filtering and hairpinning. Stand it up, put a console or a SIP client behind it, and confirm the NAT type and the UDP timeout behaviour before you size it for subscribers. Start at netavobng.com/evaluation; the CGN behaviour is documented in the manual.