This post is also available in 简体中文, 日本語, Bahasa Indonesia, ไทย.

Zero Trust Private Networking Rules

Earlier this year, we announced the ability to build a private network on Cloudflare’s network with identity-driven access controls. We’re excited to share that you will soon be able to extend that control to sessions and login intervals as well.

Private networks failed to adapt

Private networks were the backbone for corporate applications for years. Security teams used them to build a strict security perimeter around applications. In order to access sensitive data, a user had to physically be on the network. This meant they had to be in an office, connecting from a corporately managed device. This was not perfect — network access could be breached over physical connection or Wi-Fi, but tools like certificates and physical firewalls existed to prevent these threats.

These boundaries were challenged as work became increasingly more remote. Branch offices, data centers and remote employees all required access to applications, so organizations started relying on Virtual Private Networks (VPNs) to put remote users onto the same network as their applications.

In parallel to the problem of connecting users from everywhere, the security model of a private network became an even more dangerous problem. Once inside a private network, users could access any resource on the network by default unless explicitly prohibited. Identity-based controls and logs were difficult to impossible to implement.

Additionally, private networks come with operational overhead. Private networks are routed following RFC 1918 reserved IP space, which is limited and can lead to overlapping IP addresses and collisions. Administrators also need to consider the total load their private network can withstand, a load that can be further exacerbated by employees on the VPN doing video calls or even watching videos on their off time.

Modern alternatives did not solve all use cases

SaaS applications and Zero Trust Networking solutions like Cloudflare Access have made it easier to provide a secure experience without a VPN. Administrators are able to configure controls like multi-factor authentication and logging alerts for anomalous logins for each application. Security controls for public-facing applications have far outpaced applications on private networks.

However, some applications still require a more traditional private network. Use cases that involve thick clients outside the browser or arbitrary TCP or UDP protocols are still better suited to a connectivity model that lives outside the browser.

We heard from customers who were excited to adopt a Zero Trust model, but still needed to support more classic private network use cases. To solve that, we announced the ability to build a private network on our global network. Administrators could build Zero Trust rules around who could reach certain IPs and destinations. End users connected from the same Cloudflare agent that powered their on-ramp to the rest of the Internet. However, one rule was missing.

Bringing session control to Cloudflare’s private network

Cloudflare’s global network makes this possible and lighting fast. The first step is securely connecting any private networks to Cloudflare. This can be done by establishing secure outbound-only tunnels using Cloudflare Tunnel, or by adopting a more traditional connection approach like a GRE or IPSec tunnels.

Once the tunnel connection is established, specific private IP ranges can be advertised on an instance of Cloudflare. This is done with a set of commands to map a tunnel to a CIDR block of IP addresses. In the screenshot below, CIDR ranges are mapped to unique Cloudflare Tunnels -- each with their own unique identifier and assigned name.

Once the applications are addressable over Cloudflare’s network, users need a way to access these private IP ranges. This is where a VPN would traditionally be used to place a user onto the same network as the application. Instead, Cloudflare’s WARP client is used to connect a user’s Internet traffic to Cloudflare’s network.

Administrators then have control over the traffic from a user’s device client. They can create granular, identity based policies to control which users can access specific applications on certain IP private addresses or, soon, hostnames.

This was a huge step forward for IT and Security teams, as it eliminates painful latency, management and backhauling issues caused by a VPN. However, when a user authenticated once, they could keep connecting indefinitely unless fully revoked. We know some customers need to force a login every 24 hours, for example, or to set a timeout after one week. We’re excited to give customers the ability to do that.

Launching into beta, administrators can add session rules to the resources made available in this private network model. Administrators will be able to configure specific session durations for their policies and require a user re-authenticates with multi-factor authentication.

What’s next?

This announcement is just one component of making Cloudflare’s Zero Trust private network more powerful for your organization. Also being announced this week is UDP support in this model. Teams will be able to use their existing private DNS nameservers to map their application hostnames on local domains. This prevents issues with clashing or ephemeral private IP addresses for applications.

We’re excited to offer a beta for both of these features. If you would like to try these out before the new year, please use this sign-up link to be alerted when the beta is available.

If you would like to get started with Zero Trust controls for your private network, Cloudflare’s solution is free for the first 50 users. Navigate to dash.teams.cloudflare.com to get started!