Deep Dive into CGNAT

Guest Contribution to RouterFreak by Simon Orlov, Senior Engineer, NFWare

The IPv4 Address Problem

IPv4 addressing, the foundation of the internet, has long reached its limits — there are simply no more available addresses. Regional registries are exhausted, and new companies or service providers are forced to look for alternatives. The shortage affects both new and existing service providers that need to expand their networks.

Techniques such as address sharing, reclamation of unused pools, and different flavors of network address translation (NAT) have been successfully applied to extend the life of IPv4 and remain among the most efficient tools available while the shortage persists.

At the same time, IPv6 was designed to solve this problem, yet the global transition has been gradual: not all applications, devices, and networks support it fully. In practice, this creates a dual‑stack world where IPv4 remains essential. As a result, operators, enterprises, and service providers continue to rely on efficient use of IPv4 resources while steadily preparing for eventual IPv6 adoption.

What is CGNAT?

CGNAT (also known as large-scale NAT for non-carriers) is a specialized router that mitigates address exhaustion via large-scale address and port translation. The technology remaps a private address space into a public IP address space, and vice versa, by modifying network address information in packet headers when they are forwarded by a switch or router.

With this translation, each one of an organization’s users gets a different IP address space on the public Internet than the one they use on their private network. NAT changes transport layer port numbers so that many private addresses can be mapped to public IP spaces without impacting their Internet experience. CGNAT can map dozens or even hundreds of users to a single IPv4 address.

Key use cases:

• Telecom operators — mobile and fixed-line providers that need to connect millions of subscribers simultaneously
• Large enterprises — companies needing to provide internet access for thousands of employees across campuses and branches
• Cloud data centers — infrastructures that must scale services while conserving IPv4 resources and maintaining flexibility
• Web companies — online platforms, streaming providers, e-commerce, and social networks with large user bases requiring efficient IP address management

In all of these environments, CGNAT helps extend the value of IPv4 resources while ensuring that services remain available and performant for end users.

Where and How CGNAT is Deployed

In many cases, CGNAT in operators’ networks is integrated into broadband remote access server (BRAS) platforms. Small companies are also deploying it sometimes on general‑purpose routers or firewalls.

However, best practice is often to deploy it as a dedicated standalone server, either as a physical appliance or virtualized function.

The reason is that CGNAT is a stateful component that requires storing millions of sessions, which makes it resource‑intensive. Stateful devices demand significant CPU and memory, and their throughput is generally lower compared to stateless functions. When CGNAT is enabled on general‑purpose routers (for example, MikroTik), scalability and feature availability issues often appear.

For these reasons, companies usually separate CGNAT into its own appliance or virtualized solution, ensuring better performance, scalability, and resilience.

CGNAT Functionality

CGNAT is more than just NAT on a bigger scale. Network teams rely on advanced functions to make it viable:

• Logging: Recording which subscriber used which external IP and port at a given time. This information is critical for regulatory compliance and can also assist in troubleshooting and security investigations.
• Port Block Allocation (PBA): Allocating a block of ports per subscriber for efficiency. This reduces overhead in state tables and helps maintain predictable behavior under heavy loads.
• Deterministic NAT: Predictable mapping of addresses and ports, simplifying traffic analysis. It also makes it easier for lawful intercept and monitoring systems to track subscriber activity.
• Endpoint-Independent Mapping (EIM) / Endpoint-Independent Filtering (EIF): Mechanisms ensuring applications work properly behind NAT. These features improve compatibility for peer-to-peer, VoIP, and gaming applications that depend on consistent endpoint handling.
• Flexible Exclusions: The ability to exclude specific IPs from translation in real time (e.g., VIP clients or key services). This can be used to provide direct connectivity for latency-sensitive or high-value customers.
• Hairpinning / NAT Loopback: Allowing devices behind the same NAT to reach each other using the public address. This is especially useful for internal services or collaboration tools that must resolve through public DNS entries.
• Application Awareness: Support for protocols that embed IP/port information (such as SIP or FTP) to ensure compatibility. Without this, such protocols can break when translated through NAT.
• High-Availability Modes: Redundancy and state synchronization between devices to avoid session drops during failover. This is vital for maintaining seamless user experience during maintenance or hardware failures.
• IPv6 Transition Features: Support for NAT64, which translates IPv6 traffic to IPv4 and back, allowing IPv6‑only clients to communicate with IPv4 services. This is an important bridge technology that helps service providers move gradually toward IPv6 while still serving users and applications that depend on IPv4.

Virtual vs. Hardware CGNAT

There are several approaches to deploying CGNAT, depending on network design and requirements.

Hardware CGNAT is delivered as purpose-built appliances with fixed throughput and capacity. These solutions are often easier to integrate and provide predictable performance, but they can be costly and rigid, with limited scalability.

Bare metal CGNAT represents a middle ground between hardware and virtual approaches. It is deployed directly on dedicated Intel architecture servers without a hypervisor, which eliminates virtualization overhead and maximizes performance. This makes it attractive for operators that need high throughput at lower cost, but it comes with tradeoffs: bare metal deployments are harder to manage at scale and do not provide the same flexibility as virtualized solutions.

Virtual CGNAT is software-based, running on standard Intel architecture servers, sometimes within virtual environments such as OpenStack. Virtual and bare metal deployments allow flexible scaling on commodity hardware, and virtual solutions in particular are rising in popularity thanks to its cost-efficiency. They give companies the agility to expand capacity as needed.

Containerized CGNAT is packaged as containers for deployment on Kubernetes or other orchestration platforms. This approach aligns with automation-first strategies and cloud-native architectures, but it is only suitable for small deployments. For large telecom operators it is usually not a practical option, since CGNAT is a resource-intensive application that demands predictable high performance at scale.

In practice, the right deployment model depends on the type of organization and its goals: hardware still makes sense in some cases, virtual is becoming the mainstream choice for flexibility and cost efficiency, and containers work perfectly for smaller-scale or cloud-native projects. Each has its place, but virtual CGNAT is steadily emerging as the option many providers lean toward today.

Conclusion

CGNAT remains one of the most effective ways to address the continuing shortage of IPv4 addresses. By enabling many users to share a limited pool of public IPs, it helps operators, enterprises, and web companies maintain connectivity at scale. Looking ahead, the long‑term goal is a full transition to IPv6. Yet given the slow pace of that shift, CGNAT will remain an essential part of network design for years to come. It will continue to serve as a reliable bridge, ensuring that services stay accessible and that networks can scale smoothly until IPv6 is universally deployed.