Segregated virtual networks now supported in Cloudflare Zero Trust

Cloudflare Zero Trust has always allowed organizations to build a single virtual private network connecting users on WARP to services behind Cloudflare Tunnel. That model carried an implicit constraint: every private IP range connected to an account had to be globally unique. Today, Cloudflare is introducing support for multiple, logically separate virtual networks so overlapping CIDRs no longer block private network routing.

With this update, organizations can create and manage multiple virtual networks through WARP and Tunnel connectors. Each virtual network operates as an independent group of IP subspaces, letting teams compose their infrastructure into separate private networks accessible through the same Zero Trust deployment.

The overlapping-CIDR problem

The original architecture treated all connected private networks as one flat routing domain. That worked when every IP range was distinct, but it breaks down in realistic enterprise scenarios. Two data centers replicating each other often reuse the same 10.1.0.0/16 space, creating duplicate addresses like 10.1.2.3 on different machines in different locations.

Previously, attempting to register a second Tunnel advertising that same CIDR triggered an ambiguity error and blocked the route. This is a common pain point for large organizations, especially after mergers or acquisitions, where renumbering entire private networks is impractical.

Setting up virtual networks

The new workflow introduces virtual networks as first-class constructs for organizing IP routes. Teams begin by defining networks, with one designated as the default:

$ cloudflared tunnel vnet add —-default vnet-frankfurt "For London and Munich employees primarily"

Successfully added virtual network vnet-frankfurt with ID: 8a6ea860-cd41-45eb-b057-bb6e88a71692 (as the new default for this account)

$ cloudflared tunnel vnet add vnet-sydney "For APAC employees primarily"

Successfully added virtual network vnet-sydney with ID: e436a40f-46c4-496e-80a2-b8c9401feac7

Once the virtual networks exist, Tunnels can be created and their CIDRs assigned to the appropriate network:

$ cloudflared tunnel create tunnel-fra

Created tunnel tunnel-fra with id 79c5ba59-ce90-4e91-8c16-047e07751b42

$ cloudflared tunnel create tunnel-syd

Created tunnel tunnel-syd with id 150ef29f-2fb0-43f8-b56f-de0baa7ab9d8

$ cloudflared tunnel route ip add --vnet vnet-frankfurt 10.1.0.0/16 tunnel-fra

Successfully added route for 10.1.0.0/16 over tunnel 79c5ba59-ce90-4e91-8c16-047e07751b42

$ cloudflared tunnel route ip add --vnet vnet-sydney 10.1.0.0/16 tunnel-syd

Successfully added route for 10.1.0.0/16 over tunnel 150ef29f-2fb0-43f8-b56f-de0baa7ab9d8

With both Tunnels running, the two data centers can now connect to Cloudflare despite their overlapping IPs. Users on WARP are routed through the default virtual network. Any user who needs to reach the other network can switch their selection in the WARP client interface—for example, from vnet-frankfurt to vnet-sydney:

New menu to allow the user to choose the network to send traffic to in the Zero Trust WARP enabled devices.

When a user switches virtual networks, the WARP client informs Cloudflare's edge of the new routing decision. That configuration propagates to all data centers through Quicksilver within seconds. The client then reconnects to the Cloudflare network, which ends any active TCP sessions to the previously selected network—similar to disconnecting and reconnecting WARP.

Current availability and roadmap

Existing Cloudflare Zero Trust organizations using private network routing will automatically have a default virtual network covering their current Tunnel IP routes. For those without overlapping ranges, no migration steps are required. Anyone needing to segment overlapping CIDRs can use the CLI commands above and optionally reassign the default virtual network.

Virtual network management is currently available only through the cloudflared CLI, but dashboard integration is planned. Cloudflare is also working on making Gateway aware of virtual networks so Zero Trust policies can target specific overlapping ranges. Once that work lands, virtual network awareness will also appear in Network Logging to support auditing and troubleshooting.