Your CGNAT pool already gives every subscriber Open NAT. That's not why they're getting kicked from the lobby.
The problem: mapping churn happens even when NAT type is Open
Ask any gamer behind CGNAT and the complaint isn't "Strict NAT" — most operators today run full-cone + EIF, so every subscriber already reports Open NAT. The complaint is "I get randomly kicked from the lobby" or "my voice chat drops for no reason." An Open NAT type does not prevent this. The cause is mapping churn: a gaming or voice UDP flow goes quiet during a natural lull — between rounds, a paused match, a muted mic — and that idle period exceeds the CGNAT's UDP idle timeout. The mapping is reaped as stale, and its external port block becomes eligible for reuse. When traffic resumes, the flow gets a different external port. The remote peer or matchmaking server is still sending to the old mapping, which no longer exists. The connection is dead, and from the subscriber's point of view they were just "kicked" for no reason. This happens on full-cone + EIF pools exactly as it happens on symmetric pools — it is a session-lifecycle problem, not an openness problem, which is why simply running an open pool doesn't fix it.
What breaks today
Match goes quiet for a minute; UDP mapping ages out; port recycled; traffic resumes on a new port the peer doesn't know about. Console/app shows a dropped connection or lobby kick. NAT type was Open the whole time on a full-cone + EIF pool — it didn't matter.
What flow-aware mapping stability changes
Detected gaming/RTC UDP flows get an extended, capped idle timeout and their port block is protected from recycling while quiet. The mapping survives the lull. When traffic resumes, it's still there, on the same port, for the same peer.
Mapping stability: how it works
Flow-aware mapping stability runs in the same CGNAT data path as ordinary session tracking, on full-cone + EIF pools exactly as on symmetric ones. It uses a lightweight signal: the flow's destination port, which the CGNAT data path already records for every session — no deep packet inspection is needed. When a UDP flow's destination port matches the known gaming/RTC port set:
Lull survives instead of reaping the mapping
- Normal UDP CGNAT idle timeout is short — tuned for typical query/response traffic
- Detected gaming/RTC flows get a longer idle allowance
- Timeout is capped — see honest bounds below
The port block itself is held
- Normal reaping frees the port block for reassignment to a new flow
- Protected flows' port blocks are held during their extended-idle window
- Prevents a race where the old port gets reassigned before the gamer's traffic resumes
Pool rebalance defers, doesn't yank
- Self-heal steering (F5) can migrate a subscriber off a pressured pool IP
- Flow-aware makes steering skip a subscriber with an active game in progress
- Deferred, not cancelled — see honest bounds below
Why this matters on full-cone + EIF, not just symmetric NAT
Most CGNAT operators running gaming-sensitive subscriber bases already default to full-cone + EIF — it's the pool configuration that avoids the NAT-type support tickets in the first place. That choice solves the openness problem, but it does nothing for mapping churn: idle timeout and port-block recycling are session-lifecycle mechanics that apply identically regardless of how open the NAT filtering is. A full-cone + EIF pool with no flow-aware protection still reaps a quiet gaming flow's mapping on schedule. Flow-aware mapping stability is built for exactly this case — the architecture most operators actually run — not as a niche add-on for symmetric-NAT deployments.
Honest bounds
Operator commands and illustrative counters
Also: Auto Open-NAT for symmetric deployments
Flow-aware mapping stability assumes the pool is already full-cone + EIF — the common case. Some operators still default to symmetric or restricted-cone NAT, and on those deployments consoles report Strict or Moderate NAT, breaking STUN-based party chat and P2P hosting. For that case, bngxdpd includes a secondary capability: Auto Open-NAT watches for the STUN binding magic cookie 0x2112A442 or a known game-port match in the XDP upload path and promotes just that flow's CGNAT entry to full-cone + EIF, so the console reports Open NAT without opening the whole pool. no-op on full-cone + EIF
Interaction with the CGNAT feature set
| Feature | Interaction with Gaming/RTC-Aware CGNAT |
|---|---|
| PCP / NAT-PMP | PCP and NAT-PMP explicit mappings always take precedence over Auto Open-NAT. Auto Open-NAT acts only on flows with no existing explicit mapping. Flow-aware mapping stability is orthogonal — it protects whatever mapping a flow already has, explicit or automatic. |
| Per-subscriber health (F1) | The per-subscriber CGNAT X-Ray (bngxdpctl check sub) includes flow-aware's protected-flow and deferred-steer counts, plus Auto Open-NAT's promoted-flow count where relevant, so operators can see both at the subscriber level. See the Per-Subscriber CGNAT X-Ray brief. |
| Abuser isolation (F3) | A subscriber moved to a penalty IP by abuser isolation retains both capabilities — isolation affects which pool IP they are on, not the per-flow NAT behaviour or mapping stability. See the Abuser Auto-Isolation brief. |
| Self-healing steering (F5) | This is the direct integration point for steering immunity: flow-aware mapping stability adds an "active game" check to the F5 steering decision so a rebalance defers rather than migrating a subscriber mid-match. Bounded — see Bound 2 above. See the Self-Healing CGNAT brief. |
Open NAT type was never the whole story
Most CGNAT operators already run full-cone + EIF — every subscriber reports Open NAT today. And gamers on those pools still get randomly disconnected mid-match, because the cause was never NAT type. A gaming or voice UDP flow that goes quiet during a lull ages past the CGNAT idle timeout, gets reaped, and comes back on a different external port that the peer no longer knows about. Flow-aware mapping stability closes that gap directly on the architecture operators actually run: a capped, extended idle timeout, port-block recycle protection, and steering immunity so a pool rebalance never yanks a subscriber mid-match.
For the smaller set of operators still defaulting to symmetric or restricted-cone NAT, Auto Open-NAT handles the openness problem the same way — promoting only the flows that need it, automatically, with the pool default untouched for everything else.
Together: detected gaming/RTC flows get exactly the mapping stability — and, where needed, exactly the openness — they need, automatically, in the XDP fast path, with capped, bounded protections that can never create a port-exhaustion or stuck-steering risk. No operator configuration per subscriber. No support tickets.
Want to see observe mode in action? We'll show the detection logs and live counters against real traffic, explain the gaming/RTC port, STUN cookie, and mapping-stability matching logic, and walk through the observe-to-enforce transition on a test subscriber.
0x2112A442) or a known game-port match in the XDP CGNAT upload path and promotes matching flows to full-cone NAT with endpoint-independent filtering (EIF) for that CGNAT session entry; all other traffic retains the operator's configured default NAT behaviour. Auto Open-NAT is intentionally a no-op when the CGNAT pool is already configured for full-cone + EIF globally — there is nothing to promote if every subscriber is already Open — and exists for operators whose default NAT is symmetric or restricted-cone. QUIC (UDP/443) is explicitly excluded from promotion by design. PCP and NAT-PMP explicit mappings always take precedence over Auto Open-NAT's automatic promotion. All modes can be changed live without daemon restart. Console NAT-type output, "before/after" examples, and the bngxdpctl cgnat flow-aware counters shown above are illustrative of typical observed behaviour and CLI output format — not real customer data. Related briefs: Per-Subscriber CGNAT X-Ray, Abuser Auto-Isolation, Self-Healing CGNAT Pool Steering.