Cloudflare One Brings Hardware-Free Load Balancing to Private Networks

Cloudflare has extended its load balancing solution to support fully private traffic flows, including traffic from WARP-authenticated devices. This removes the need for dedicated hardware load balancers by integrating Cloudflare’s load balancing service directly with the Cloudflare One platform. Enterprise customers can now use load balancers to manage both public and private traffic destined for private networks.

The service previously supported four traffic patterns: public HTTP(S) endpoints at layer 7, public TCP/UDP endpoints at layer 4 via Spectrum, private HTTP(S) endpoints connected by Cloudflare Tunnels at layer 7, and private TCP/UDP endpoints connected by Tunnels at layer 4 via Spectrum. The new private load balancing capabilities sit alongside these existing options.

For years, Cloudflare’s load balancing argument has been that hardware appliances are expensive to buy, license, operate and upgrade, and eventually hit end-of-life requiring costly replacements. Cloudflare runs its load balancers in every one of its data centers across more than 300 cities, providing scale without the constraints of bandwidth limitations, deployment location, additional modules, or supply chain issues. Its Anycast network ensures every customer connects to a nearby data center where policies and steering rules are applied. These private load balancing features are meant to extend that resilience, scale, and simplicity into internal networks.

Closing the Public Traffic Residency Gap

All existing layer 4 load balancers were connected to the public Internet. That meant customers could protect traffic with WAF rules and Zero Trust policies, but the load balancer itself was still reachable from the Internet. Some organizations need to keep internal resources completely off the public network. While it was already possible to isolate origins and endpoints behind Cloudflare Tunnels, the platform has now delivered a similar level of isolation for layer 4 load balancers.

This follows a previous extension to load balancing that introduced support for private IPs and Cloudflare Tunnels. In that setup, load balancers were accessible via RFC 1918 private IP addresses rather than hostnames—essentially acting as a virtual IP (VIP) inside a private network. Those VIP-based load balancers can now be deployed within a virtual network to isolate traffic to a specific set of Cloudflare Tunnels, so applications stay completely private.

Entering the Network Through Magic WAN

To reach those private VIP load balancers from a corporate network, Cloudflare Magic WAN now functions as an on-ramp. Customers connect their corporate networks to Cloudflare’s global network through GRE or IPSec tunnels, or use the Magic WAN Connector, which works without manual configuration of network gear and can run at any physical or cloud location. That allows internal load balancing across data centers, internally hosted applications, and critical services requiring high availability, without exposing anything publicly.

All Cloudflare One on-ramps are now supported. That means connecting to private load balancers does not require a public egress or forced latency penalty. The proximity of Cloudflare’s data centers helps here—within 50ms of 95% of the global Internet-connected population—and the load balancing service works with Argo Smart Routing to avoid network congestion and improve application performance by up to 30%.

WARP for Dispersed Clients

Companies also need to serve users outside the corporate LAN. Cloudflare WARP acts as an on-ramp to reach load balancers on private IPs. The WARP client sends device traffic through Cloudflare’s global network, where Gateway can filter web traffic and Zero Trust policies can assess device health before granting access to corporate applications.

For this load balancing use case, WARP combines with Cloudflare Tunnels so private origins live inside virtual networks that isolate traffic or handle overlapping private IP spaces. Administrators set up WARP profiles that point each user at the correct virtual network. The WARP client then installs the necessary routes on the device, and the traffic path to the private load balancer’s IP address happens over the WARP connection with no separate user action.

Under the Hood: Connecting Load Balancing to Cloudflare One

Private layer 4 load balancers do not carry public hostnames or IP addresses, so Cloudflare had to integrate its load balancing service with its private networking stack. When a private load balancer is created, it now receives a private IP within the customer’s virtual network. When traffic reaches that VIP, the private networking services consult the load balancing system to determine the right endpoint, then connect to a privately hosted origin through a secure off-ramp. This differs sharply from public load balancers, which off-ramp traffic to the public Internet.

Traffic can now flow between any supported on-ramp—WARP, Magic WAN GRE/IPSec, or otherwise—to any off-ramp: Cloudflare Tunnel, CNI, or even the public Internet. That flexibility lets an organization provision one load balancing configuration to handle whatever traffic pattern it needs, instead of maintaining separate appliances or cloud load balancers per traffic type.

Setup and Roadmap

The new features are documented in Cloudflare’s load balancing documentation. Cloudflare says it plans to follow with updates to the user experience, enhanced layer 4 session affinity, new steering methods, and finer control over egress ports.