The Problem with Reused IP Space

The public Internet works because global addressing authorities assign IP space to prevent duplication. A single IP address points to a logically unique destination — even in an Anycast architecture like Cloudflare's, every instance of an announced IP represents the same service. The routing table always knows exactly where a packet is intended to go.

Private networks don't have that luxury. In enterprise networking, IP overlap is a fact of life. Cloudflare sees it in three common scenarios:

  • Mergers & acquisitions: Two companies merge, and both use 10.0.1.0/24 for their core services.
  • Extranets: Partners, vendors or customers securely connect to your network using their own internal IP schemes, leading to unavoidable conflicts.
  • Cookie-cutter architectures: SaaS providers or retail brands use identical IP space for every branch to simplify deployment.

The problem emerges when these sites try to reach the Internet or a data center through Cloudflare. If two different sites send traffic from the same source IP, the return packet hits an architectural wall. If the administrator puts both routes into the routing table, it becomes non-deterministic which path is taken. From the perspective of a standard routing table, there is no way to distinguish between two identical paths.

Why Traditional Fixes Create Toil

The "industry standard" solutions work, but they introduce significant administrative overhead:

  1. Virtual Routing and Forwarding (VRF): Creating "virtual" routing tables keeps traffic isolated, but managing cross-VRF communication (route leaking) is brittle and complex at scale.
  2. Network Address Translation (NAT): NATing each overlapping subnet into a unique managed range works, but the mapping is administrative toil for each new site or partner.

The typical customer use case is an overlapping network needing to access the Internet or a private data center — with zero-touch configuration.

Introducing Automatic Return Routing

Cloudflare is announcing Automatic Return Routing (ARR) in Closed Beta. ARR is an optional tool for Cloudflare One customers that routes traffic back to where it originated without requiring an IP route in a routing table. Overlapping networks can coexist without a single line of NAT or complex VRF configuration.

ARR moves the intelligence from the routing table to stateful tracking. Traditional networking is "forgetful" — a router treats every packet like a stranger, looking at its routing table anew for each one even if it just saw an identical packet a millisecond ago. With stateful tracking, the system has a memory. It recognizes when packets belong to the same flow and remembers key information until the conversation finishes.

With ARR, Cloudflare remembers one extra piece of information when initializing a flow: the specific tunnel that initiated it. Instead of asking the network, "Where does this IP live?" ARR asks, "Where did this specific conversation originate?"

The logic works in three steps:

  1. Ingress: A packet arrives at the Cloudflare edge from a site via a specific connection — an IPsec tunnel, GRE tunnel, or Network Interconnect.
  2. Flow Matching: The Cloudflare Virtual Network checks whether that packet matches an existing flow. If it matches, all decisions about the traffic are already in memory. If not, Cloudflare decides which parts of the Cloudflare One stack to pass it through (Gateway, DLP, Firewall), records the ultimate destination, and — with ARR — records which tunnel initiated the flow.
  3. Symmetric Return: When return traffic arrives from the destination, the Cloudflare Virtual Network uses its in-memory state to proxy the traffic without examining the destination IP, which could be reused across different sites. The originating tunnel is visible in the flow state, so the packet is delivered directly back to it.

By remembering the originating tunnel for every flow, ARR enables zero-touch routing. If site traffic is only client-to-Internet, there is no need to configure return routes at all.

Built on Unified Routing

ARR plugs into another Cloudflare initiative: Unified Routing. Historically, Cloudflare Zero Trust (users/proxies) and Cloudflare WAN (network-layer/sites) lived at different levels of the system. Cloudflare WAN relied on kernel primitives (Linux network namespaces, routes, eBPF), while Zero Trust lived in userspace where proxies could perform deep inspection and application-level security. This "split-brain" approach required complex logic to move traffic between component services.

With Unified Routing, the initial routing decision has moved from the network-layer data plane into the existing Zero Trust userspace routing logic — the same hardened software used by Cloudflare One Clients and Cloudflare Tunnel. This fixes long-standing interoperability problems between Cloudflare WAN and Zero Trust. Cloudflare Mesh, Cloudflare Tunnel, and IPsec/GRE on-ramps can now be used together in the same account without conflict. In September 2025, Cloudflare deployed Unified Routing internally for all employees and sites, seeing immediate 3-5x performance improvements for Cloudflare One Clients.

With Unified Routing enabled, all Cloudflare WAN traffic flows through Apollo, Cloudflare's Zero Trust hub. Unlike the Linux kernel's standard routing table, the userspace data plane is fully programmable. Cloudflare can attach metadata — like the originating Tunnel ID — directly to a flow entry in Apollo. Each packet is tracked by flow from the moment it hits the edge, eliminating per-packet routing decisions in favor of consistent, session-aware decisions for the lifetime of the flow.

ARR is enabled on a per-tunnel or per-interconnect basis. Once enabled, any traffic that matches an existing flow is routed back to the connection where it originated, without consulting the routing table.

Current Scope and Next Steps

ARR is currently in closed beta and supports overlapping IP addresses accessing the Internet via Cloudflare's Secure Web Gateway. Cloudflare is extending it to support private data center access, adding mid-flow failover (pinning flows to a primary onramp and detecting failover to a backup), and investing in capabilities to make IP overlap a non-issue for even the most complex global deployments.