Starting today, your team can create a private network on Cloudflare’s network. Team members click a single button to connect to private IPs in environments that you control. Cloudflare’s network routes their connection through a data center in one of over 200 cities around the world. On the other side, administrators deploy a lightweight software connector that replaces traditional VPN appliances.
Cloudflare’s private network combines IP level connectivity and Zero Trust controls. Thick clients like RDP software, SMB file viewers, or other programs can connect to the private IPs already in use in your deployment without any additional configuration. Coming soon, you’ll be able to layer additional identity-based network-level rules to control which users, from which devices, can reach specific IPs.
We are launching this feature as a follow-up to Cloudflare’s Developer Week because we are excited to give your development team, and your entire organization, a seamless platform for building and connecting your internal resources. We built this solution based on feedback from customers who want to move to a Zero Trust model without sacrificing some convenience of a private network.
We’re excited to give any team the ability to run their internal network on Cloudflare’s global edge. Organizations that have 50 or fewer team members can use this feature, as well as nearly all of Cloudflare for Teams, at no cost by starting here.
Challenges with non-web applications
Over the last three years, Cloudflare Access has helped thousands of organizations replace their VPN with a Zero Trust model. Most of those teams started with web applications like homegrown intranet sites or self-hosted tools. In less than 10 minutes, customers could connect an application to Cloudflare’s network, add Zero Trust rules, and make connectivity seamless and fast for their users.
Web applications make that flow easier thanks to client software that already runs on every device: the browser. Browsers send HTTP requests over the public Internet to the application. Cloudflare’s network checks every request against the Zero Trust rules configured for that application.
Users are prompted to authenticate and, in some cases, present additional signals like device posture. If the user should be able to reach the application, Cloudflare issues a JSON Web Token (JWT) that the browser stores in the form of a cookie. That token allows for seamless authentication to other applications because they all are available inside of the same web browser.
Cloudflare's network accelerates traffic to the applications and evaluates every request. Meanwhile, the browser handles authentication storage and HTTP requests trigger Zero Trust checks. No additional client software is required.
Customers gave us two consistent pieces of feedback:
“Setup for web applications is seamless.”
“What about everything else outside of the browser?”
Use cases outside of the browser introduce two challenges: they each rely on a different piece of client software and they each handle authentication in unique ways. For example, SSH sessions can support client certificates or password authentication. RDP workflows rely on passwords and tend to lack multifactor requirements or SSO integration. Other protocols lack authentication altogether. Exposing any of these directly on the Internet would make them vulnerable to attack.
As a result, organizations hide these types of resources behind a private network as a band-aid. Users toggle their VPN and their client software connects to internal IPs and ports. Administrators suffer through maintaining VPN appliances while their users deal with the slower performance.
Cloudflare attempted to solve this type of use case a couple of years ago. We built an option that relied on a connector, `cloudflared`, that bridged user devices and the environment where the services ran.
The instance of cloudflared running in the data center or cloud environment created a WebSocket connection between the connector and Cloudflare’s edge. End users ran the same connector on their own devices. cloudflared running on the client device exposed a local port which could receive traffic from services like an SMB or RDP client and send it over WebSocket to the corresponding cloudflared in the data center.
This option was functional, but not viable for small teams without dedicated IT staff or enterprises who do not want to retrain tens of thousands of users. End users had to run a manual command for each service and change the configuration for every client. We had offered full Zero Trust control at the expense of usability.
A private network on Cloudflare’s edge
Today’s announcement combines the usability of a VPN client with the performance and security of Cloudflare’s network while removing the maintenance overhead of networking appliances.
The architecture starts with Cloudflare Tunnel (previously called Argo Tunnel). Cloudflare Tunnel uses the same connector, cloudflared, to create an outbound-only TCP connection from your data center or public cloud environment to two nearby Cloudflare data centers.
Administrators configure the tunnel to represent a range of IP addresses where applications run in their environment. Those IPs can be RFC 1918 ranges or any IP addresses that cloudflared can address. Teams can also run redundant Tunnels for availability and separate Tunnels in different environments to connect other IP ranges.
Cloudflare’s edge then maps each Tunnel in the organization’s account to the IP range represented. Administrators can review the mapping from any active instance of cloudflared.
On the client side, end users run an agent, Cloudflare WARP, and authenticate with their identity provider into the same Cloudflare account that administers the Tunnels. They can then click a single button to connect and the WARP agent creates a Wireguard tunnel from the device to Cloudflare’s network.
The Cloudflare WARP agent routes traffic from the device to Cloudflare’s edge. By default, the client excludes traffic to RFC 1918 IP addresses and a few other defaults. In this mode, administrators can configure the client to instead pick up traffic bound for those IP ranges.
When that traffic arrives, Cloudflare’s edge locates the Tunnel in that account that represents the IP range enrolled. If the user connects to the same data center as the Tunnel, Cloudflare proxies a TCP connection by opening a bidirectional stream to the corresponding instance of cloudflared. If the user first reaches a different data center, Cloudflare’s smart routing technology finds the fastest path to the Tunnel.
Client applications that connect to specific IP addresses can continue to do so without any configuration changes. When those applications attempt to reach those IPs, the Cloudflare WARP agent handles routing that traffic to Cloudflare’s edge and to the instance of cloudflared.
cloudflared then operates like a bastion inside of the data center and connects to the services running at those IP addresses.
Security for the rest of the Internet
The Cloudflare WARP agent that connects users to this private network can also keep them safe on the rest of the Internet.
You can start by using Cloudflare WARP to filter DNS queries for devices in any location. We've built that solution on top of the world's fastest DNS resolver, 1.1.1.1, to stop users from inadvertently connecting to phishing sites, malware, or other threats.
The agent can also help your team adopt a faster Secure Web Gateway and deprecate web filtering hardware. Cloudflare WARP will connect all Internet-bound traffic over a Wireguard tunnel to a nearby data center. Once there, Cloudflare will inspect the HTTP requests and accelerate traffic to its destination on our global backbone network. You can build rules that control where files can be uploaded, filter for viruses inside of traffic, or prevent users from going to certain parts of sites.
How to get started
You can start running your virtual private network on Cloudflare with just four steps.
1. Install and authenticate cloudflared in a data center, public cloud environment, or even on a single server with the command below. Once authenticated, cloudflared will become part of your Cloudflare account and available.
cloudflared tunnel login
2. Create a Tunnel with a name that represents that service or environment.
cloudflared tunnel create grafana
Next, configure cloudflared to represent the IP address range in your environment. The command below will tell Cloudflare to send traffic from your users to that IP range to this Tunnel.
cloudflared tunnel route ip add 100.64.0/10
Once configured, you can start the tunnel with a single command or run it as a service.
cloudflared tunnel run grafana
Configure traffic to private IP addresses to be included through WARP, as opposed to being run in the default split tunnel mode.
Enroll your device and enable WARP to connect.
We've provided a step-by-step tutorial as well to help your team get started.
What’s next?
Available today, security teams can build rules to determine who can enroll into this private network and from which devices. That requirement and the connectivity features available make this option similar to a private network, although one accelerated by Cloudflare.
However, we want to give your team more granular control over who can reach specific resources. We’ll be launching support to build additional Zero Trust rules that apply distinct rules to individual IPs or IP ranges.
Additionally, this flow only works for client-to-server (WARP to cloudflared) connections. Coming soon, we’ll introduce support for east-west connections that will allow teams to connect cloudflared and other parts of Cloudflare One routing.