Post Syndicated from Steve Welham original https://blog.cloudflare.com/automatic-return-routing-ip-overlap/
The public Internet relies on a fundamental principle of predictable routing: a single IP address points to a logically unique destination. Even in an Anycast architecture like Cloudflare’s, where one IP is announced from hundreds of locations, every instance of that IP represents the same service. The routing table always knows exactly where a packet is intended to go.
This principle holds up because global addressing authorities assign IP space to organizations to prevent duplication or conflict. When everyone adheres to a single, authoritative registry, a routing table functions as a source of absolute truth.
On the public Internet, an IP address is like a unique, globally registered national identity card. In private networks, an IP is just a name like “John Smith”, which is perfectly fine until you have three of them in the same room trying to talk to the same person.
As we expand Cloudflare One to become the connectivity cloud for enterprise backbones, we’ve entered the messy reality of private IP address space. There are good reasons why duplication arises, and enterprises need solutions to handle these conflicts.
Today, we are introducing Automatic Return Routing (ARR) in Closed Beta. ARR is an optional tool for Cloudflare One customers that gives you the flexibility to route traffic back to where it originated, without requiring an IP route in a routing table. This capability allows overlapping networks to coexist without a single line of Network Address Translation (NAT) or complex Virtual Routing and Forwarding (VRF) configuration.
In enterprise networking, IP overlap is a fact of life. We see it in three common scenarios that traditionally cause toil for admins:
-
Mergers & acquisitions: Two companies merge, and both use
10.0.1.0/24for 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 and operation.
The problem arises when these sites try to talk to 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. The administrator has to make a decision on how to route the traffic based on the ambiguous destination. If the administrator puts both routes into the routing table, it will be non-deterministic as to which path is taken: the correct path or the incorrect path. From the perspective of a standard routing table, there is no way to distinguish between two identical paths.
This diagram shows two branches (Site A and Site B) both using 10.0.1.0/24. They send packets to Cloudflare. The return packet from the Internet reaches the Cloudflare edge, and this return traffic is sometimes sent to the wrong site because the routing table has two identical egress options.
There are numerous ways to resolve this ambiguity, and we are committed to solving them in the easiest way for our customers to manage. The traditional “industry standard” fixes are functional, but they introduce significant administrative overhead and complexity that we are committed to eliminating:
-
Virtual Routing and Forwarding (VRF): This involves creating “virtual” routing tables to keep traffic isolated. While effective for separation, it adds administrative overhead. Managing cross-VRF communication (route leaking) is brittle and complex at scale.
-
Network Address Translation (NAT): You can NAT each overlapping subnet from an unmanaged IP space to a managed IP range that is unique in your network. This approach works well, but the mapping is administrative toil for each new site or partner.
Typically, the use case we hear from customers is an overlapping network needing to access the Internet or a private data center. How do we solve this without administrative overhead?
We developed ARR as a “zero-touch” solution to this problem. ARR moves the intelligence from the routing table to stateful tracking.
So what is stateful tracking?
In traditional networking, a router is “forgetful” (aka “stateless”). It treats every single packet like a total stranger. Even if it just saw a packet from the exact same source going to the exact same destination a millisecond ago, it has to look at its routing table all over again to decide where to send the next one.
With stateful tracking, the system has a memory. It recognizes when a series of packets are all part of the same “flow” (that is, a network conversation between two endpoints), and remembers key information about that flow until it finishes. With ARR, we remember one extra piece of information when initializing the flow: the specific tunnel that initiated it. This allows us to send return traffic back to that same tunnel, without ever consulting a routing table!
Instead of asking the network, “Where does this IP live?” ARR asks, “Where did this specific conversation originate?”
The Logic:
-
Ingress: A packet arrives at the Cloudflare edge from a site via a specific connection, i.e. an IPsec tunnel, GRE tunnel, or Network Interconnect.
-
Flow Matching: The Cloudflare Virtual Network first checks (by header inspection) whether that packet matches an existing flow.
-
Proxying: If the packet matches, that’s great! All of the decisions about this traffic have already been made and stored in our memory. All we need to do is pass that packet along already-established paths.
-
Flow Setup: If it doesn’t match an existing flow, we decide which parts of the Cloudflare One stack to pass it through (e.g. Gateway, DLP, Firewall), as well as its ultimate destination. We store all of this state in memory. With ARR, this is when we record which tunnel initiated the flow.
-
-
Symmetric Return: When return traffic arrives from the destination, the Cloudflare Virtual Network uses its existing in-memory state to proxy the traffic. Crucially, it does this without needing to examine the traffic’s destination IP, which could very well be reused across different sites. This completely bypasses the need to consult a routing table. We see the originating tunnel in the flow state and deliver the packet directly back to it.
Example of overlapping source IPs tracked by in-memory flow state, tagged with source onramp to inform return routing decision.
By remembering the originating tunnel for every flow, ARR facilitates zero-touch routing. If your site traffic is only client-to-Internet, there is no need to configure return routes at all, reducing toil when deploying new branch sites or “Coffee Shop Networking.”
To make ARR a reality at Cloudflare scale, we plugged into another initiative we have been working on: 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, etc). Zero Trust lived in userspace, where proxies could perform deep inspection and application-level security. This “split-brain” approach often required complex logic to move traffic between component services, and some of this complexity became product limitations that customers might notice.
With our new Unified Routing mode, we have moved the initial routing decision from our network-layer data plane into our existing Zero Trust userspace routing logic, the same hardened software used by Cloudflare One Clients and Cloudflare Tunnel in our Zero Trust solution. This change has many benefits to how we enable our customers to use their private networks with products across the Cloudflare platform, as it fixes long-standing interoperability problems between Cloudflare WAN and Zero Trust. Unified Routing means you can use Cloudflare Mesh, Cloudflare Tunnel, and IPsec/GRE on-ramps together in the same account without a single conflict.
In September 2025, we deployed Unified Routing mode internally for all Cloudflare employees and sites. We saw immediate 3-5x performance improvements for Cloudflare One Clients, as you can see in the graph above.
When designing ARR, we knew that we needed to move away from kernel-based routing and build on our new Unified Routing framework.
When Unified Routing is enabled, all Cloudflare WAN traffic flows through Apollo, our Zero Trust hub. Unlike the Linux kernel’s standard routing table, our userspace data plane is fully programmable. We 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 our edge, and we no longer need to make independent, per-packet routing decisions. Instead, we can make consistent, session-aware decisions for the lifetime of the flow.
ARR is straightforward to enable on a per tunnel or interconnect basis:
Once enabled for a tunnel or interconnect, any traffic that matches an existing flow is routed back to the connection where it originated, without consulting the routing table.
For the enterprise architect, ARR is a tool to bypass the persistent friction of IP address conflicts. Whether integrating an acquisition or onboarding a partner, the goal is to make the network invisible, so you can focus on the applications, not the plumbing.
Today, ARR is in closed beta and supports overlapping IP addresses accessing the Internet via our Secure Web Gateway. We are already extending this to support private data center access, adding mid-flow failover (pinning the flow to a primary onramp, and seamlessly detecting when that flow fails over to a backup onramp), and further investing in the architectural capabilities needed to make IP overlap a non-issue for even the most complex global deployments.
Not using Cloudflare One yet? Start now with our Free and Pay-as-you-go plans to protect and connect your users and networks, and contact us for comprehensive private WAN connectivity via IPsec and private interconnect.
