Summary

  • Cloudflare’s published overlap example retains a broad production route in the default network and describes production reachability outside the overlap even after staging is selected.
  • Its current overview limits a possible unmatched-route fallback description to WAN routes. That is not proof that every unmatched Tunnel route always falls back.
  • Client traffic selection, virtual-network routing and access policy are distinct controls; a useful environment name cannot stand in for all three.

The address is not the environment

An organisation could have a test system and a production system behind the same private address. That is not necessarily an addressing error. RFC 1918 gives private addresses meaning within an enterprise or cooperating enterprises, not a globally unambiguous identity. Reuse becomes a problem when a connection needs to distinguish those local meanings.

Cloudflare’s virtual-network configuration guide supplies a way to associate overlapping routes with different contexts. Users can select a context through the Cloudflare One Client. The meaningful destination is therefore more than an IP string: it includes the routing context in which that string is resolved.

That can be commercially useful without establishing a saving measured here. Integrating separately addressed environments need not begin with the assumption that every duplicate private prefix must disappear. But avoiding that assumption transfers work into maintaining route associations and client context. It does not remove the need to specify the environments a user should be able to reach.

The example keeps something important in default

The overlapping-IP learning path, updated 23 April 2026, offers a particularly informative example. Production uses 10.0.0.0/8 through Tunnel-A; staging uses the more specific 10.0.1.0/24 through Tunnel-B. Initially both routes belong to default. Within the overlapping range, the more specific route leads to staging rather than production.

The example then adds a production-specific route for 10.0.1.0/24 and associates the two versions of that range with production and staging virtual networks. Crucially, the broad production 10.0.0.0/8 route remains in default. The accompanying text says a staging selection can still reach the other production addresses, while the overlapping range leads to staging.

That is a statement in a published example, not a packet path observed in a customer deployment. It nevertheless defeats a common reading of the label: choosing something called staging is not, in that example, the same as permitting staging and denying every production destination. Routing the overlapping range to its intended environment and restricting the entire reachable estate are different outcomes.

The choice may be intentional. Some users may need the shared production range and the staging override. There is no basis here to call the example a breach. The purchasing mistake would be to accept a context name as a negative-access guarantee that the example does not provide.

A narrower overview should not become a universal rule

The virtual-network overview, updated 25 August 2026, describes separate routing tables and entries. It also says an unmatched route in the selected network may fall back to the default table for WAN routes. WAN connections using IPsec, GRE or CNI are described as default-only.

Those qualifications matter. The overview is not evidence that every unmatched route through any Cloudflare Tunnel necessarily falls back to any default Tunnel route. The April example’s wider stated reachability and the August overview’s WAN-scoped wording should not be silently merged into an invented universal routing algorithm.

The robust conclusion is about commissioning evidence. Neither surface licenses a buyer to infer a sealed environment merely from a selection name. The intended route behaviour must be understood for the products and connections actually proposed. Where documentation scopes differ, a provider explanation is more useful than a confident rule supplied by the procurement model.

No customer configuration or network probe was used to resolve that scope in this research. There is no established isolation failure, exfiltration event or availability incident here. The article examines what the public descriptions do and do not prove about an investment decision.

The packet has to enter the service first

The private-IP connection guide, updated 23 June 2026, adds another boundary. An unassigned route goes to default. The client’s default exclusion of RFC 1918 traffic also means that intended private traffic needs an appropriate Split Tunnels selection before the Cloudflare route can do its job.

A configured route is therefore not proof that every intended client packet enters that route-selection system. Conversely, including a broader private range can affect local resources on the user’s own network; the guide expressly discusses that risk. An organisation integrates client-side traffic decisions as well as connector-side routes.

This is not a deployment recipe or a recommendation to alter someone’s device. It is a commercial scope question: who owns the fleet’s traffic selection, and does it match the destinations covered by the service agreement? A buyer accepting only a connector inventory could leave an essential part of the operating arrangement unspecified.

Routing and permission should meet without becoming synonyms

The connection guide separately recommends Gateway filtering and a catch-all block with higher-priority application or IP allowances. Its default reachability statement concerns enrolled devices, not arbitrary people on the public Internet. Network reachability also does not imply that the destination application has accepted a user.

The network-policy documentation, updated 24 August 2026, describes an action and a logical expression as the policy decision. It includes a Virtual Network selector for traffic routed through a specific context via the Cloudflare One Client. That offers a way to incorporate context into policy; it does not make the context name itself a policy.

A buyer consequently needs two descriptions that agree: where traffic can be routed and which traffic should be permitted. One can be technically coherent while the other is incomplete. The same private prefix can be correctly disambiguated yet carry a wider allowed destination set than a team intended.

The conclusion is not that virtual networks are useless or that Cloudflare’s controls are broken. They address a real ambiguity. The useful purchase is a complete operating boundary around that capability: client entry, route context, retained default scope and explicit access decisions. Calling the network staging is a start. Demonstrating the intended destination boundary is the work that remains.

Sources