Key details

  1. Unified Routing became generally available for Cloudflare WAN and Magic Transit on September 18, 2026.
  2. Cloudflare recommends Unified Routing for all new accounts.
  3. The unified data plane spans Cloudflare One Client, Cloudflare Tunnel, IPsec, GRE and Cloudflare Network Interconnect.
  4. Automatic Return Routing requires Unified Routing and can return supported flows without static or dynamic return routes.
  5. Unified Routing supports Mesh-to-WAN connectivity that legacy routing does not.
  6. BGP over IPsec and GRE tunnels requires Unified Routing but remains beta.
  7. Route-selection semantics differ from the legacy system because supported connection types share one routing fabric.
  8. Some capabilities remain beta or limited even though the underlying Unified Routing mode is GA.

What builders should take away

  1. Use Unified Routing for new Cloudflare WAN or Magic Transit designs unless a required feature still depends on legacy behaviour.
  2. Before migrating an existing network, compare route-selection semantics and every firewall, IPv6, BGP and connector feature you depend on.
  3. ARR can reduce route-table maintenance for symmetric stateful traffic, but validate supported flow types and failure behaviour before removing explicit routes.
  4. If you use BGP over GRE or IPsec, treat that feature's beta status separately from Unified Routing's GA status.
  5. Test overlapping-prefix and cross-connector paths explicitly because moving from separate routing systems to one fabric can change which route wins.

What changed

On September 18, Cloudflare made Unified Routing generally available for Cloudflare WAN and Magic Transit and recommended it for all new accounts. Unified Routing replaces the legacy model's separate WAN and Zero Trust routing systems with one Cloudflare One routing fabric across supported connection types including Cloudflare One Client, Cloudflare Tunnel, IPsec, GRE and Cloudflare Network Interconnect. The GA path carries features that depend on the unified data plane, including Automatic Return Routing, BGP over supported tunnel on-ramps, custom client subnets and routing between Mesh and WAN connections.

Why it matters

For teams using Cloudflare as a private-network and Internet-edge layer, routing mode now determines which network designs are possible rather than merely how routes are displayed. Automatic Return Routing can preserve symmetric return paths without maintaining explicit return routes, while the unified fabric removes some of the precedence and connectivity boundaries between Zero Trust and WAN routes. New deployments therefore have a clear preferred architecture; existing legacy deployments need to evaluate feature parity and migration constraints before adopting newer routing capabilities.

One routing fabric replaces two independent systems

Legacy Cloudflare WAN evaluates WAN routes separately from Zero Trust routes. Unified Routing applies route selection across supported connection types in one Cloudflare One data plane. That matters when private networks span user clients, tunnels, GRE/IPsec sites and interconnects: route specificity is evaluated across the unified fabric rather than inside separate systems, reducing cases where a route in one subsystem unexpectedly takes precedence over a more specific route in another.

Automatic Return Routing can remove explicit return routes

Unified Routing is required for Automatic Return Routing. ARR learns which Cloudflare WAN connection a supported flow arrived on and sends matching return traffic back over that connection without requiring a static or dynamic return-route entry. Cloudflare documents support for traffic including new TCP connections, UDP and ICMP echo flows. The practical benefits are simpler route management, symmetric paths through stateful firewalls and support for overlapping private address space in relevant designs.

BGP over GRE and IPsec becomes part of the new routing model

Cloudflare supports BGP peering over IPsec and GRE tunnel on-ramps under Unified Routing, allowing customer routers and the Cloudflare routing table to exchange routes dynamically rather than relying only on static configuration. The tunnel BGP capability remains beta even though Unified Routing itself is GA, so teams should distinguish the stability of the routing fabric from the availability state of individual features built on it.

GA does not mean every network feature has reached parity

Cloudflare's comparison documentation still lists availability differences and beta features under Unified Routing. IPv6 remains beta for Cloudflare WAN and Magic Transit, BGP over CNI is closed beta and unavailable to new customers, and some network-firewall capabilities have been arriving incrementally. Existing customers should therefore treat GA as a migration decision to evaluate, not a signal to switch production routing without checking their specific features and route semantics.

What to watch next

  • Whether Cloudflare provides a broader migration path or tooling for existing legacy-routing accounts.
  • BGP over GRE/IPsec moving from beta to GA.
  • Remaining Advanced Network Firewall feature parity under Unified Routing.
  • IPv6 moving beyond beta for Cloudflare WAN and Magic Transit.
  • Operational evidence from production migrations showing where unified route selection changes existing network behaviour.

Still unclear

  • Cloudflare recommends Unified Routing for new accounts but does not make the GA announcement an instruction for every existing account to migrate immediately.
  • Individual features on the unified data plane have different availability states; BGP over IPsec/GRE and IPv6 are not both fully GA.
  • The available evidence is primarily Cloudflare documentation and changelog material; independent production migration evidence is limited.

Sources

Direct reading behind this dossier.

4 sources
Magic Transit changelog
Cloudflare primary

Historical beta-to-GA context and feature-parity milestones.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment