Skip to content
Joey Wang
Menu

Search

DevOps and Reliability

Detecting Cloudflare Zero Trust Beyond the WARP Flag

WARP can report itself as off while Zero Trust still routes your Mac's traffic; here is how to check DNS, ASN, and DoH to find out for sure.

· 2 min read

securitydevops #security#macos#networking#dns

Audio summary

Checking whether WARP is “on” only answers half the question. A Mac can still be routed through a Zero Trust tunnel while warp=off, and the reverse trip - confirming you’re actually off the corporate network - takes a few more checks: DNS, ASN, and whether internal domains still resolve.

Detecting WARP status

curl -s https://www.cloudflare.com/cdn-cgi/trace | grep warp

warp=on means WARP is active, warp=off means it isn’t. It says nothing about whether you’re still inside a Zero Trust tunnel through some other path.

Detecting DNS-over-HTTPS usage

scutil --dns

Look for a Cloudflare DoH endpoint such as https://cloudflare-dns.com/dns-query. If your DNS is going through an encrypted resolver, tools like dig and nslookup won’t show you what’s actually being resolved.

Detecting Zero Trust routing directly

Even with WARP off, you can still be routed through Zero Trust. Check the ASN:

curl -s http://whoami.cloudflareclient.com
curl -s https://ipinfo.io

If the ASN comes back as Cloudflare (AS13335), you’re likely still routed through them. The more reliable test is whether internal-only domains resolve at all:

dig internal.corp.example

If that resolves, you’re in the tunnel, regardless of what the WARP flag says.

A lightweight monitoring script

#!/bin/bash

WARP=$(curl -s https://www.cloudflare.com/cdn-cgi/trace | grep warp)
ASN=$(curl -s https://ipinfo.io/org)
DNS=$(scutil --dns | grep "https://")

echo "WARP status: $WARP"
echo "ASN: $ASN"
echo "DoH in use: $DNS"

Run it on a schedule via launchd if you want a standing check rather than a one-off.

Blocking Zero Trust DNS with /etc/hosts

If MDM restrictions mean you can’t touch WARP itself, you can override DNS locally with /etc/hosts. This doesn’t kill WARP, but it stops key services from resolving.

Step 1: create a blocklist

Save as ~/scripts/zero_trust_blocklist.txt:

# Zero Trust Block Rules START
127.0.0.1 api.corp.example
127.0.0.1 sso.example.com
127.0.0.1 warp.cloudflareclient.com
# Zero Trust Block Rules END

Step 2: a toggle script

#!/bin/bash

HOSTS_FILE="/etc/hosts"
BLOCKLIST="$HOME/scripts/zero_trust_blocklist.txt"

if grep -q "# Zero Trust Block Rules START" "$HOSTS_FILE"; then
    echo "Unblocking Zero Trust domains..."
    sudo sed -i.bak '/# Zero Trust Block Rules START/,/# Zero Trust Block Rules END/d' "$HOSTS_FILE"
else
    echo "Blocking Zero Trust domains..."
    sudo cp "$HOSTS_FILE" "$HOSTS_FILE.bak"
    sudo bash -c "cat '$BLOCKLIST' >> '$HOSTS_FILE'"
fi
chmod +x ~/scripts/toggle_zero_trust_hosts.sh

Step 3: optional notification

terminal-notifier -title "Zero Trust Hosts" -message "Block mode enabled"

Step 4: run it off-hours automatically

HOUR=$(date +%H)
if [[ $HOUR -ge 18 || $HOUR -lt 9 ]]; then
  ~/scripts/toggle_zero_trust_hosts.sh
fi

None of this disables WARP. It gives you visibility into whether you’re actually routed through Zero Trust, and a reversible way to block specific domains when the client won’t let you disconnect outright.