What is CGNAT?

Published Aug 13, 2026

← All glossary terms Jump to C

Carrier-Grade NAT (CGNAT) is a large-scale network address translation technique that maps many private IPv4 addresses to a small pool of public IPv4 addresses, using network address and port translation (NAPT) to conserve address space. ISPs and enterprises deploy it to extend limited public IPv4 allocations across large subscriber bases.

Key takeaways

  • CGNAT shares one public IP pool across many subscribers via NAPT.
  • Only the source address and port are translated for outbound traffic.
  • Versa CGNAT also supports NAT64, DNS64, and network obfuscation.
  • Address pools and rules on VOS devices define how translation applies.
  • Twice-NAT modes translate both source and destination in one pass.

On this page: Why it mattersHow it worksTypesCGNAT & VersaFAQ

Why is CGNAT important?

IPv4 address exhaustion made CGNAT unavoidable. The public IPv4 address space ran out of new allocations years ago, but the internet keeps growing – more subscribers, more devices per subscriber, more IoT endpoints. Carriers cannot buy enough public addresses to give every device its own, so CGNAT shares a small pool of public ones, extending IPv4’s useful life without an immediate cutover to IPv6.

The payoff goes beyond conservation. CGNAT also hides internal topology: an outside device sees only the shared public address, not the private addressing behind it, reducing the attack surface. On Versa VOS devices, CGNAT handles internet breakout for branch traffic, supports twice-NAT for combined source-and-destination translation, and enables network obfuscation, masking a server’s real IP behind a dynamically allocated one.

What is CGNAT?

CGNAT operates like ordinary NAT, at a much larger scale. A network device – a carrier’s edge router or, in Versa deployments, a VOS device – maintains a pool of public IP addresses and rules defining which private traffic gets translated and how. When a private host sends traffic outward, the device rewrites the source IP address, and usually the source port, to one drawn from the public pool, then tracks the mapping (the binding) so return traffic finds its way back.

Because thousands of private addresses share a comparatively small public pool, port allocation – not address allocation – becomes the resource to manage: each public address supports many concurrent sessions across different ports. Configurable timeouts for ICMP, TCP, and UDP mappings reclaim unused bindings, and schemes such as round robin spread load across the pool. Endpoint-independent mapping and filtering control whether a binding is reused across remote destinations, which matters for VoIP and gaming traffic.

Types of CGNAT

Three broad approaches address different translation needs. NAT44, also called large-scale NAT, is the core CGNAT function: many private IPv4 addresses share a pool of public IPv4 addresses through NAPT, with basic, dynamic, destination, and twice-NAT variants covering everything from static one-to-one mappings to fully dynamic source-and-destination translation in a single pass. NAT64/DNS64 solves a different problem – letting IPv6-only clients reach IPv4-only servers by synthesizing an IPv6 address for the destination and translating the resulting traffic back to IPv4 at the gateway. NPTv6 (Network Prefix Translation) is a stateless IPv6-to-IPv6 alternative: it swaps internal address prefixes for external ones using a checksum-neutral algorithm, trading NAT’s flexibility for simplicity and end-to-end reachability.

CGNAT & Versa

Versa implements CGNAT natively on VOS devices as a service built from address pools and rules. In Director, administrators configure CGNAT pools and rules per device template – address ranges, port allocation schemes, mapping timeouts – then apply NAT modes from Basic NAT-44 and NAPT-44 through twice-NAT variants, NPT-66 for IPv6 prefix translation, and NAT64/DNS64 for IPv4-IPv6 interworking. In Concerto, the same function is exposed as CGNAT policies built into SD-WAN main templates, adding a Port Forwarding mode that simplifies exposing an internal service through one rule.

Versa CGNAT also supports network obfuscation – allocating a dynamic destination address so a DNS query returns a decoy address instead of a server’s real one – and endpoint-independent mapping for NAT-sensitive applications. Operators troubleshoot CGNAT from the CLI, checking pool statistics, per-tenant rule state, and active session counters through the vsmd daemon.

Frequently asked questions

What is the difference between CGNAT and regular NAT?

Regular NAT maps one private address to one public address for a household or office. CGNAT shares a small pool of public addresses across thousands of subscribers, using port-level translation to multiply capacity – the shared, carrier-operated pool is what makes it “carrier-grade.”

Does CGNAT break applications that rely on incoming connections?

It can. Because subscribers share one public address, an external host cannot reliably reach a specific subscriber without prior outbound traffic establishing a binding – this complicates hosting and some VoIP or gaming traffic unless port forwarding is configured.

Why do internet service providers use CGNAT?

IPv4 exhaustion left ISPs without enough public addresses to assign one to every subscriber. CGNAT lets a provider serve a large subscriber base from a much smaller public IPv4 pool, delaying full IPv6 migration while keeping subscribers connected to the IPv4 internet.

What is twice-NAT in CGNAT?

Twice-NAT translates both the source and destination addresses of a packet in one rule – for example, dynamically translating the source while statically rewriting the destination. Versa CGNAT supports Twice Basic, Twice Dynamic, and Twice NAPT-44 for these scenarios.

How does NAT64 relate to CGNAT?

NAT64 is a CGNAT mode that lets IPv6-only clients reach IPv4-only servers: DNS64 synthesizes an IPv6 address for the destination, and the gateway translates the resulting traffic back to IPv4 – the mechanism behind IPv6-only access to a legacy IPv4 internet.

More on CGNAT

If you want to learn more, these are sources we trust.

RFC 6888: Common Requirements for Carrier-Grade NATs RFC 6146: Stateful NAT64
The IETF’s baseline requirements for CGN devices: logging, address-pooling behavior, and application compatibility. The stateful IPv6-to-IPv4 translation standard behind CGNAT’s NAT64 mode, letting IPv6-only clients reach IPv4 servers.

If you’re reading about CGNAT, these are worth looking at next.

Network Address Translation Network Denial of Service
The general address-translation process CGNAT scales up – Versa supports basic, dynamic, destination, and carrier-grade NAT types. The VOS object that groups interfaces on a routing instance; CGNAT pools and rules are scoped to one. An attack that floods a target to deny service to legitimate users; CGNAT logging profiles help trace abuse to a subscriber.