Cloudflare Agent — Seamless Deployment at Scale

Cloudflare’s Zero Trust Agent Reaches Feature Parity Across All Major Platforms

Roughly a year after introducing the desktop client for its Zero Trust platform, Cloudflare is expanding both the reach and the manageability of that agent. The company this week announced full feature parity for the client across its supported operating systems, added ChromeOS and Linux to the roster, and introduced a range of configuration options intended to ease migrations away from legacy VPNs and security tools.

Scaling a shared codebase

Maintaining a client across several operating systems typically means duplicating significant chunks of code or accepting divergent behavior on different platforms. Cloudflare’s approach is to write the core of the agent in Rust, allowing roughly 95% of the codebase to be shared across all devices. The company refers to this common component internally as the “shared daemon” (or service on Windows). The result is that quality improvements and bug fixes land on every platform at the same time, rather than trickling out per-OS.

On the connection side, the agent builds on BoringTun, Cloudflare’s own WireGuard implementation written in Rust. Unlike traditional VPNs, which are often slow and flaky over varying network conditions, BoringTun runs over UDP and is designed to hold up across the range of internet infrastructure users encounter, from airplane Wi-Fi to congested city networks. It has been field-tested at scale with millions of consumer devices.

The agent now fully supports the following platforms:

• Windows 8.1, Windows 10, and Windows 11
• macOS Mojave through Monterey, including M1 support
• ChromeBooks manufactured after 2019 (new)
• Linux: CentOS 8, RHEL, Ubuntu, Debian (new)
• iOS and Android

Stepping away from the legacy VPN

The original iteration of the agent was built on the assumption that all device traffic would be encrypted and forwarded to Cloudflare’s network for HTTP and DNS policy enforcement. That model works well for organizations ready to commit fully to a Zero Trust architecture, but many are in the middle of a transition and need to run new and legacy tools side by side. The recent releases add several features to support that incremental approach.

Domain-based split tunneling. Administrators already had the ability to exclude traffic from the tunnel by IP address CIDR. Now they can write split tunnel rules using domain names such as *.example.com or example.com, sparing them the task of looking up the IP ranges behind a given domain.

Include-only split tunnels. Rather than sending all traffic to Cloudflare by default and excluding specific routes, administrators can invert the model: define only the routes that should go to Cloudflare, and leave everything else out of the tunnel. This is useful for a quick legacy VPN replacement to reach a Cloudflare Tunnel resource or for confining HTTP inspection to the most sensitive infrastructure.

Targeted private domain resolution. Some organizations run Cloudflare’s Zero Trust products alongside an existing third-party VPN. Previously, the agent’s fallback DNS handling was global and gave no control over where queries were sent. Administrators can now specify which DNS server should respond to private domains, a capability that pairs with the Zero Trust private networking rules Cloudflare introduced this week.

Posture-only mode. Scheduled for the first quarter of 2022, this mode will let the agent run without processing any DNS requests or forwarding traffic to Cloudflare. It is designed for organizations that want to adopt Cloudflare Access device posture policies before they are ready to enable Gateway HTTP inspection.

Managing the rollout programmatically

Deploying an agent to tens of thousands of endpoints is a logistical exercise that quickly outgrows a click-through dashboard. Cloudflare’s device management controls are built on RESTful APIs using HTTPS and JSON. The same API surface is exposed through the API documentation and the Terraform provider, meaning anything that can be done in the Teams dashboard can also be scripted.

Domain-based split tunneling offers a straightforward example. For a single domain-based include rule for example.com, the API call looks like this:

curl -X PUT "https://api.cloudflare.com/client/v4/accounts/699d98642c564d2e855e9661899b7252/devices/policy/include" \
     -H "X-Auth-Email: [email protected]" \
     -H "X-Auth-Key: c2547eb745079dac9320b638f5e225cf483cc5cfdda41" \
     -H "Content-Type: application/json" \
     --data '[{"host":"*.example","description":"Include all traffic to example.com in the tunnel"}]'

The equivalent Terraform configuration:

# Including *.example.com in WARP routes
resource "cloudflare_split_tunnel" "example_split_tunnel_include" {
  account_id = "699d98642c564d2e855e9661899b7252"
  mode       = "include"
  tunnels {
    host        = "*.example.com",
    description = "Include all traffic to example.com in the tunnel"
  }
}

Reporting on enrolled devices is another task well suited to automation. A script using the Device List API can retrieve all Windows devices registered to an organization:

curl -X GET "https://api.cloudflare.com/client/v4/accounts/699d98642c564d2e855e9661899b7252/devices?type=windows" \
     --header 'Authorization: Bearer 8M7wS6hCpXVc-DoRnPPY_UCWPgy8aea4Wy6kCe5T' \
     -H "Content-Type: application/json"

The command returns JSON in a structure similar to this:

        {
            "created": "2021-12-01T17:14:23.847538Z",
            "device_type": "windows",
            "gateway_device_id": "215f9adc-52ca-11ec-9ece-f240956bdf5f",
            "id": "215f9adc-52ca-11ec-9ece-f240956bdf5f",
            "ip": "150.111.29.1",
            "key": "0mS9vj2gk0KNcXoi50pwfuL49WT0rLGAcX2gVze3ixA=",
            "last_seen": "2021-12-01T17:14:30.110663Z",
            "mac_address": "00:0c:29:6f:11:93",
            "model": "VMware7,1",
            "name": "MYVMWin10",
            "os_version": "10.0.19042",
            "serial_number": "VMware-56",
            "updated": "2021-12-01T17:14:30.110663Z",
            "user": {
                "email": "[email protected]",
                "id": "6a8e079d-8a33-4677-b610-a5e361c0c959"
            },
            "version": "2021.11.278"
        },
        {
            "created": "2021-11-08T23:59:37.621164Z",
            "device_type": "windows",
            "gateway_device_id": "ee02da10-40ef-11ec-bb68-6a56f426bb46",
            "id": "ee02da10-40ef-11ec-bb68-6a56f426bb46",
            "ip": "98.247.211.1",
            "key": "DhUI8nqeVrXL1JFhYbeCFmkeu/XEkkEjVmcZ8UraTDI=",
            "last_seen": "2021-11-08T23:59:37.621164Z",
            "model": "Latitude 7400",
            "name": "CloudBox",
            "os_version": "10.0.19043",
            "serial_number": "7CHR3Z2",
            "updated": "2021-11-23T20:03:12.046067Z",
            "user": {
                "email": "[email protected]",
                "id": "39663a0d-9f7c-4a24-ae7f-f869a8cf07f1"
            },
            "version": "2021.11.34"
        },

Dashboard controls on the way

For organizations without an MDM solution—or for administrators who prefer a visual interface—Cloudflare will soon offer dashboard-based management of client behavior. A beta is expected in the coming weeks that will allow changes to client configuration to take effect without requiring a new client version to be pushed.

Roadmap: Per-user settings and more telemetry

Cloudflare has several larger client updates planned for next year. Highlights include device settings scoped by user or group, so that items like split tunnel rules or update permissions can vary by identity; the previously mentioned posture-only mode for onboarding Access controls before deploying Gateway; additional Linux distributions; and telemetry and analytics showing how devices are performing with respect to the client and the traffic they are sending to Cloudflare’s network.

Downloads for all supported clients are available at the links below.