A new approach to an old network staple
Network Address Translation (NAT) is one of the most widely deployed network functions, sitting behind everything from a home router to massive ISP infrastructure. Its job is straightforward: rewrite the source or destination IP address in a packet header. For example, translating a private address like 192.168.0.1 to the publicly routable 192.0.2.1. Organizations rely on it to connect private networks to the Internet, to route traffic between private networks that use overlapping address space, and to conserve scarce IPv4 addresses by mapping many connections to a single public IP. These jobs have traditionally fallen to physical appliances or cloud-managed virtual instances—but those solutions carry real limitations.
Where classic NAT breaks down
Two main scenarios drive most NAT deployments. First, public NAT lets devices on private subnets reach the Internet: an ISP translates the private source IP of an outbound request to a public one, then reverses the translation for responses. Some customers have stricter requirements here—they need egress to come from one or a small set of IPs so remote services can positively identify them, or they want IPs that reflect the client's geolocation so that, for instance, a "pizza near me" search yields locally relevant results.
Second, private NAT enables communication between private networks that reuse the same IP ranges. Imagine retail stores spread across a hundred locations, each running printers on 10.0.1.0/24, point-of-sale devices on 10.0.2.0/24, and cameras on 10.0.3.0/24. When those devices need to reach a central data center, NAT can translate the duplicate source IPs into a different range so that return packets find the right device—or even support direct traffic between mirrored subnets, like a VoIP call between two stores.
The third force behind NAT adoption is IPv4 exhaustion, which has driven ISPs toward carrier-grade NAT that maps many customers to a single address. But regardless of use case, the underlying delivery model is the problem. Physical or virtual NAT devices sit in specific locations—a data center or an availability zone—forcing traffic to be backhauled out of its way. Capacity is bounded per instance, so scaling up means provisioning more boxes and building load-balancing logic across them. Costs stack up too: hardware capex, installation and maintenance, or unpredictable monthly cloud charges that spike with traffic surges. And in hybrid or multi-cloud architectures, you end up managing a separate NAT instance per network, multiplying the complexity.
Introducing Magic NAT
Magic NAT is a new entrant in the "Magic" family of network services, built on the Cloudflare One network-as-a-service platform. It aims to remove the geographic, capacity, and cost constraints of conventional NAT by running on Cloudflare's Anycast architecture, which spans over 275 cities.
Setup
Getting traffic flowing through Magic NAT follows a short path:
- Connect to Cloudflare. It works with any network-layer on-ramp, including Anycast GRE or IPsec tunnels, Cloudflare Network Interconnect (CNI), and WARP. Traffic lands at the nearest Cloudflare location automatically.
- Enable Internet connectivity. Arbitrary TCP and UDP traffic (any port) can egress to the Internet from Cloudflare IPs.
- (Optional) Use dedicated egress IPs. If you need traffic to originate from specific IPs—for allowlists or other server-side checks—you can tap dedicated IPs rather than the shared pool.
- (Optional) Add security policies. Magic NAT works natively with Cloudflare One security tooling, including Magic Firewall and the Secure Web Gateway, to apply L3–L7 policies across both East/West and Internet-bound traffic.
The service will also handle address translation between IPv4 and IPv6, including 4to6 and 6to4 NAT for compatibility where clients or servers are reachable via only one IP version.
The "everywhere" part
Because of Cloudflare's Anycast design, NAT capacity follows the traffic. Packets enter at the nearest point of presence, and if a location goes down—say, for maintenance—traffic fails over automatically to the next closest one, with zero configuration from you. Failover back to your own network is equally automatic, routing down the healthiest available path. There is no concept of an availability zone to worry about, and no need to backhaul traffic to a central hub for translation.
Scale and cost
The service rides on Cloudflare's network capacity, currently at 141 Tbps and growing. Its traffic management systems, including the edge load balancer Unimog, are designed to smooth out high-volume spikes—the same infrastructure absorbs major DDoS attacks and processes hundreds of Gbps through Magic Firewall. The takeaway: there's no instance limit to plan around, no need to manually load balance multiple NAT gateways, and no throttling to design around.
Pricing follows the same model as other Cloudflare network services: based on the 95th percentile of clean bandwidth. That means no hardware procurement, no per-instance hourly fees, and no double-charging for data transfer. The bill is predictable and tied to what you actually send through the service.
One NAT for hybrid networks
For organizations running a mix of on-premises data centers and multiple clouds, Magic NAT offers a single point of translation for traffic from any source network. Instead of needing separate NAT instances in each environment—each with its own management overhead and cost—you get one overlay that all traffic can transit. It removes the need to stand up per-network infrastructure just to get address translation done.
Magic NAT is currently in beta and is already translating addresses globally for a range of workloads. Those interested can sign up to learn more or reach out to their account team to get access.
