Kill the VPN: Building Zero Trust with Cloudflare Access and WARP

The Problem with Traditional VPNs

We have relied on traditional VPNs for decades, but they are quickly becoming a security liability. The fundamental flaw is the ‘flat network’ architecture. Once a user authenticates, they often gain broad access to an entire subnet. If a single employee’s laptop is compromised, an attacker can move laterally across your internal servers with ease. Beyond security, managing IKEv2 certificates and fielding ‘the VPN is slow’ tickets is a constant drain on IT resources.

In my experience deploying this for teams of over 100 engineers, the Zero Trust model is a massive upgrade. By using Cloudflare Access and WARP, you can stop opening inbound ports on your firewall entirely. You no longer trust a user just because they are ‘on the network.’ Instead, every single request is verified based on identity, device health, and geographic context.

The Zero Trust Architecture

This setup relies on three core components working in sync:

• Cloudflare Tunnel (cloudflared): A small daemon on your server that creates an encrypted, outbound-only connection to Cloudflare. You don’t need to touch your router’s port forwarding.
• Cloudflare Access: The brain of the operation. This is where you write policies, such as ‘only users with a @company.com email can access the staging environment.’
• Cloudflare WARP: A lightweight client app for end-users. It handles DNS and routes traffic for internal IP ranges like 10.0.0.0/8 or 192.168.1.0/24.

Installation: Setting Up the Tunnel

First, we need to bridge your internal server to the Cloudflare network. We use the cloudflared CLI for this. While the Cloudflare dashboard offers a GUI setup, the CLI is much faster for automation and troubleshooting.

1. Install cloudflared on Linux

On a Debian or Ubuntu machine, run these commands to grab the latest package:

curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

2. Authenticate and Create the Tunnel

Run the login command. It will give you a unique URL to authorize your Cloudflare account in a browser:

cloudflared tunnel login

Once authorized, create your tunnel. Let’s call it ‘production-gateway’:

cloudflared tunnel create production-gateway

This generates a JSON credentials file. Treat this file like a master key; if you lose it, you lose the connection.

Configuration: Routing and Policies

With the tunnel established, we must define what traffic flows through it. You generally have two choices: Public Hostnames for web apps or Private Networks for things like SSH, RDP, and database connections.

Configuring Private Network Routing

To let users reach an internal IP like 192.168.1.50 from their homes, route that CIDR block through your tunnel:

cloudflared tunnel route ip add 192.168.1.0/24 production-gateway

Creating the Configuration File

Create a config.yml file. This file acts as the traffic cop for the cloudflared daemon. It maps external hostnames to internal services.

tunnel: <TUNNEL_ID>
credentials-file: /root/.cloudflared/<TUNNEL_ID>.json

ingress:
  - hostname: gitlab.yourcompany.com
    service: http://localhost:8080
  - hostname: db-ssh.yourcompany.com
    service: ssh://localhost:22
  - service: http_status:404

Install the tunnel as a system service so it survives a reboot:

sudo cloudflared service install
sudo systemctl start cloudflared

Setting Up Cloudflare WARP for Clients

Cloudflare Access handles web apps perfectly, but you need the WARP client for everything else. Think of WARP as a modern, high-performance replacement for your old VPN client. It uses WireGuard under the hood for better speed and stability.

1. Configure the Zero Trust Dashboard

Head to Settings > WARP Client. You must set ‘Device Enrollment’ rules here. I suggest limiting enrollment to your corporate SSO, such as Okta, Google Workspace, or Microsoft Entra ID.

2. Split Tunneling

By default, WARP might ignore local traffic. You must ensure your internal IP ranges are included in the Split Tunnel settings. Go to Settings > WARP Client > Device Settings and add your 192.168.1.0/24 block to the inclusion list.

3. Deploy to Users

Staff can download WARP directly from Cloudflare. After installing, they just click ‘Login with Cloudflare Zero Trust’ and enter your team name. Once they authenticate via SSO, they can ping internal IPs as if they were sitting in the office.

Verification & Monitoring

Check the Tunnel Health status in your dashboard first. It should show ‘Active’ with multiple connections to different Cloudflare data centers. This redundancy ensures that if one Cloudflare edge node goes down, your connection stays live.

Testing the Connection

Try accessing an internal resource from a coffee shop or home network. If you set up a Public Hostname, Cloudflare will challenge you with a login page. After you sign in, your app should load instantly.

For private network testing, try a simple SSH command using the internal IP:

ssh [email protected]

Reading the Logs

The Logs > Access section is a goldmine for auditors. Traditional VPNs usually just show that a user connected. Cloudflare shows you exactly which service they touched and when. This granular visibility makes security audits much less painful.

Best Practices from the Field

• Enforce MFA: Don’t rely on simple passwords. Connect your Identity Provider (IdP) to enforce hardware keys or push notifications.
• Check Device Posture: Set policies that require a device to have its firewall on or be running a specific macOS or Windows version before it can connect.
• Local DNS Fallback: If you use internal names like jira.local, configure ‘Local Domain Fallback’ in WARP settings. This tells Cloudflare to resolve those specific names through your internal DNS servers.

Moving to Zero Trust is a significant shift, but it drastically shrinks your attack surface. You stop chasing ghosts in your firewall logs and start managing access based on who the user actually is.