Skip to content

Instantly share code, notes, and snippets.

@bootswithdefer

bootswithdefer/ASU & Cloudflare WARP with Cloudflare WAN Support Guide.docx.md

Last active July 23, 2026 18:07
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save bootswithdefer/e9a4b970ae4c4e213e61e2c3bda0795b to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save bootswithdefer/e9a4b970ae4c4e213e61e2c3bda0795b to your computer and use it in GitHub Desktop.
Download ZIP
Raw
ASU & Cloudflare WARP with Cloudflare WAN Support Guide.docx.md

Cloudflare One Client (formerly WARP) with Cloudflare WAN (formerly Magic WAN) Support Guide

07/23/2026 NOTE: This document is a work in progress requiring input & review from both ASU and Cloudflare.

Table of contents

Purpose

This guide gives the university support team a repeatable way to triage issues for staff using the Cloudflare One Client, formerly WARP, in a Cloudflare WAN deployment.

Use it to answer four questions quickly:

  1. Is the problem local to the device, network, identity, or policy?
  2. Is traffic taking the expected path: the Cloudflare One Client, Gateway, Cloudflare WAN, Cloudflare Tunnel, or direct local network?
  3. What evidence should Tier 1, Tier 2 Desk Side, Tier 3, and Cloudflare Support collect?
  4. Which campus network services need to be checked before changing Cloudflare policy?

This is a starting operating model. It should be updated after ASU confirms its ticketing workflow and escalation ownership.

ASU-specific architecture confirmed:

  • DNS: Internal asu.edu zones resolve via Gateway resolver policy routed over the private network (CNI) to AWS-hosted resolvers (10.120.0.4, 10.120.1.4, 10.120.2.4). Local Domain Fallback handles only generic non-routable suffixes (.local, .internal, .lan, etc.) — NOT asu.edu.
  • IdP: Three providers — EASSO (OIDC, primary), Shibboleth (SAML), ADFS (SAML, backup). SCIM is disabled; group membership updates require re-authentication.
  • MDM: Microsoft Intune (device compliance posture integration active).
  • EDR: CrowdStrike Falcon (two tenants: Engineering and Main).
  • Observability: Cloudflare Logpush to Datadog. Gateway activity logging is disabled in the Cloudflare dashboard — all log correlation happens in Datadog.
  • WAN connectivity: CNI (Cloudflare Network Interconnect) with static routes. No BGP, GRE, or IPsec tunnels in use.
  • Egress: Dedicated egress IPs for all @asu.edu users — 104.30.176.165 (primary), 104.30.162.107 (fallback), 2a09:bac0:1001:377::/64 (IPv6).

ASU support model assumption: Tier 1 is the help desk for ASU staff intake. If Tier 1 cannot resolve the issue, the ticket moves to Tier 2 "Desk Side" support. Desk Side can physically visit the user's desk when needed and has practical experience with software, applications, and common endpoint troubleshooting. For the Cloudflare One Client, Desk Side will likely handle most hands-on troubleshooting unless the issue is a common and easily fixed Tier 1 item. The Cloudflare account team should train Desk Side on gathering the right diagnostic information, opening and managing Cloudflare Support cases, and escalating with enough evidence for Cloudflare to act quickly.

Audience

  • Tier 1 Help Desk: ASU staff intake, basic classification, user-facing steps, and collection of screenshots or the Cloudflare One Client diagnostics for common issues.
  • Tier 2 Desk Side Support: Hands-on endpoint and application troubleshooting, including desk visits when needed; primary owner for most the Cloudflare One Client diagnostic collection and Cloudflare Support evidence gathering.
  • Tier 3 Network, Security, and Cloudflare Administrators: Cloudflare WAN route and tunnel review, Gateway policy changes, packet captures, escalation to Cloudflare, and coordination with ASU network service owners.
  • Tier 4 Engineering: ASU Engineering, Network Engineering staff, Hytech.
  • Cloudflare account team: Validation of account configuration, Cloudflare WAN to the Cloudflare One Client integration, and Cloudflare-side escalation.

How the Cloudflare One Client and Cloudflare WAN fit together

A staff device using the Cloudflare One Client sends selected traffic to Cloudflare. From there, traffic can follow different paths:

User traffic type Expected Cloudflare path What usually owns the failure domain
Internet site Cloudflare One Client → Cloudflare Gateway → Internet Cloudflare One Client, Gateway DNS, Gateway HTTP or Network policy, TLS inspection certificate, local firewall
Private campus application over Cloudflare WAN Cloudflare One Client → Cloudflare → Cloudflare WAN tunnel → campus site Cloudflare One Client split tunnel, DNS resolution, Gateway policy if used, Cloudflare WAN route, tunnel health, campus firewall, target app
Private application over Cloudflare Tunnel Cloudflare One Client → Cloudflare → cloudflared connector → private app Cloudflare One Client split tunnel, resolver policy, tunnel route, connector health, target app
SaaS app with Access or Gateway controls Cloudflare One Client → Gateway and/or Access policy User identity, IdP groups, device posture, Gateway or Access policy
Local campus resource intentionally excluded from the Cloudflare One Client Direct local interface, not the Cloudflare One Client Campus LAN or Wi-Fi, DHCP, local DNS, local firewall, split tunnel exclusion 
flowchart LR
    Device[Staff Device<br/>WARP Client<br/>100.96.0.0/12]

    Device --> CF[Cloudflare Edge]

    CF --> GW_Internet[Gateway → Internet]
    CF --> MWAN[Cloudflare WAN Tunnel<br/>→ Campus Site]
    CF --> CFTunnel[cloudflared Connector<br/>→ Private App]
    CF --> Access[Access / Gateway<br/>Policy → SaaS]

    Device -.-> Local[Direct Local<br/>Split Tunnel Excluded]

    classDef device fill:#a29bfe,stroke:#6c5ce7,color:#000
    classDef cloudflare fill:#f08c00,stroke:#d56a00,color:#fff
    classDef info fill:#74b9ff,stroke:#0984e3,color:#000
    classDef fix fill:#00b894,stroke:#00897b,color:#000
    classDef warning fill:#fdcb6e,stroke:#f39c12,color:#000
    classDef neutral fill:#b2bec3,stroke:#636e72,color:#000
    class Device device
    class CF cloudflare
    class GW_Internet info
    class MWAN fix
    class CFTunnel warning
    class Access device
    class Local neutral
Loading

Key routing notes:

  • the Cloudflare One Client devices receive a Cloudflare One virtual IP from 100.96.0.0/12. Use this when checking logs, firewall rules, or Cloudflare WAN flows that see WARP-sourced traffic.
  • ASU uses exclude mode split tunnels. The following are excluded from the tunnel on both profiles: 10.153.0.0/16 (ASU WiFi), 100.64.0.0/10 (CGNAT), 192.168.0.0/16, 169.254.0.0/16 (link-local), multicast, Apple APN ranges, and Zoom (*.zoom.us, *.zoom.com). Most RFC 1918 ranges (notably 10.0.0.0/8 and 172.16.0.0/12) are NOT excluded — private campus traffic routes through the Cloudflare One Client by default.
  • For the Cloudflare One Client to Cloudflare WAN access, confirm that the campus subnet is present in Cloudflare WAN routing and that the Cloudflare One Client device profile includes the destination in the tunnel path.
  • ASU resolves internal asu.edu domains via a Gateway resolver policy that routes queries over the private network to AWS-hosted DNS servers (10.120.0.{4,1,2}:53). This works regardless of whether the user is on or off campus since DNS traverses the CNI path.
  • Two device profiles exist: Default (off-campus, no protocol preference) and Campus (on-campus, forces WireGuard). The Campus profile activates via managed network detection (TLS probe to 10.220.75.12:443).
  • All @asu.edu WARP users egress through dedicated IPs: 104.30.176.165 (primary) and 104.30.162.107 (fallback). Verify WARP is active by checking the user's public IP matches one of these.
  • If the Cloudflare One Client to Cloudflare WAN integration was recently enabled, disabled, or migrated, Cloudflare should confirm account-level integration state and remove any stale tunnel binding or upgrade state.

Quick reference

  1. Identify the user, device, location, network, destination, timestamp, and the Cloudflare One Client state.
  2. Decide the expected path: Internet, Cloudflare WAN, Cloudflare Tunnel, Access, or local network.
  3. Collect the Cloudflare One Client diagnostics before changing settings.
  4. Check warp-settings.txt for organization, profile ID, mode, tunnel protocol, split tunnel, and local domain fallback.
  5. Check warp-status.txt for connected state, DNS, interfaces, and routing state at collection time.
  6. Check daemon.log, daemon_dns.log, and connectivity.txt for errors, repeated events, DNS failures, and tunnel establishment failures.
  7. Cross-reference Cloudflare Zero Trust device record, Gateway logs (in Datadog), and Network Session Logs.
  8. For private apps, validate DNS first, routing second, Gateway policy third, Cloudflare WAN or Cloudflare Tunnel path fourth.
  9. For Internet issues, validate the Cloudflare One Client connectivity, Gateway DNS or HTTP policy, TLS inspection certificate, and local firewall or proxy behavior.
  10. Escalate to Cloudflare with the diagnostic bundle, exact timestamps, device ID, user, destination, expected path, test results, and recent changes.

End-user intake questions

Tier 1 should collect this before assigning the ticket. Missing context causes most the Cloudflare One Client escalations to bounce between teams. For ASU, Tier 1 is the help desk that staff contact first.

User and device

Ask for Why it matters
User full name and university username Correlates IdP groups, Gateway logs, and device enrollment.
Email address used to enroll the Cloudflare One Client Confirms the Zero Trust identity used by the device.
Device hostname Needed for device inventory, the Cloudflare One Client device record, and MDM lookup.
Operating system and version Cloudflare One Client behavior, firewall prompts, and certificate stores differ by OS.
Cloudflare One Client version Confirms feature support and whether remote diagnostics are available.
Device type Staff laptop, lab device, shared workstation, mobile, VM, or server.
Managed or unmanaged Determines whether MDM, EDR, certificates, and local policies should be present.
Device ID from Cloudflare dashboard if available Best key for Gateway and device diagnostics correlation.

Location and network

Ask for Why it matters
User location Remote, campus, lab, branch, data center, travel, hotel, conference, home.
Network type Wired, campus Wi-Fi, home Wi-Fi, cellular hotspot, VPN, guest network.
Public IP at time of issue Helps correlate firewall, IdP, and Cloudflare logs.
Local IP and DNS servers Helps identify DHCP, DNS, captive portal, or local network conflicts.
Is another VPN, proxy, PAC file, endpoint firewall, or web filter active? Competing network agents commonly affect DNS, routes, certificates, and tunnel setup.
Is the issue limited to one network? Separates the Cloudflare One Client or policy issues from local network egress restrictions.

Problem description

Ask for Why it matters
Exact destination FQDN, URL, IP, port, protocol, application name.
Expected path Internet, campus private app over Cloudflare WAN, Cloudflare Tunnel app, Access app, SaaS, or local resource.
Exact error Browser error, the Cloudflare One Client status, app error, timeout, DNS failure, certificate warning, block page.
Timestamp and timezone Needed for Gateway, Cloudflare WAN, IdP, MDM, and firewall logs.
Reproducibility Always, intermittent, only after sleep, only on campus, only off campus, only one app.
Business impact One user, cohort, department, campus site, all Cloudflare One Client users, all Cloudflare WAN traffic.
Recent changes Password reset, the Cloudflare One Client update, MDM profile update, firewall change, DNS change, route change, IdP group change.

Evidence from the user

Ask for:

  • Screenshot of the Cloudflare One Client connection status.
  • Screenshot of the application or browser error.
  • If the user sees a block page, read the page content — ASU's custom block pages display enriched diagnostic info including device posture status, group membership, WARP status, and recent login failures. This may already explain why access was denied.
  • The affected URL, hostname, IP, port, and protocol.
  • Output from warp-cli status and warp-cli settings where the user can run commands.
  • the Cloudflare One Client diagnostic bundle, collected as close to the issue time as possible.
  • If mobile, exported console logs and a screenshot of the routing table from the Cloudflare One Client app diagnostics view.

Diagnostic collection

Collect diagnostics before toggling the Cloudflare One Client, reinstalling the client, changing policy, or deleting registration. The first bundle captures the failure state.

Windows, macOS, and Linux

Ask the user or Tier 1 technician to run:

warp-diag

The command creates a warp-debugging-info-<date-time>.zip file, usually on the user's desktop. Attach the zip to the ticket.

Useful local commands:

Command Use
warp-cli status Shows current connection status.
warp-cli settings Shows active local and dashboard-delivered settings.
warp-cli registration show Shows current registration information.
warp-cli registration organization Shows the enrolled Zero Trust organization.
warp-cli connect Connects the Cloudflare One Client. Use after diagnostics are collected.
warp-cli disconnect Disconnects the Cloudflare One Client for controlled tests.
warp-cli mode warp+doh Tests full the Cloudflare One Client plus DNS over HTTPS mode, if allowed by policy.
warp-cli mode doh Tests DNS-only mode, if allowed by policy. Useful to isolate DNS from tunnel issues.

Do not use warp-cli registration delete as an initial troubleshooting step. It forces re-enrollment and can destroy evidence. Use it only after Tier 2 Desk Side or Tier 3 confirms that re-registration is required.

iOS and Android

Ask the user to open the Cloudflare One Client app:

  1. Go to Advanced.
  2. Go to Diagnostics.
  3. Export Console logs. Include both application and extension logs where present.
  4. Open Routing Table and take a screenshot.
  5. Include screenshots of the Cloudflare One Client status and the application error.

Remote capture from the dashboard

If the installed the Cloudflare One Client version supports it, Tier 2 Desk Side or Tier 3 can collect diagnostics remotely:

NOTE: This requires access or membership in the ASU dashboard where these devices are managed.

  1. Go to Cloudflare One dashboard.
  2. Go to My team or Devices and select the device.
  3. Go to DEX then Diagnostics.
  4. Start a capture.
  5. Select Include the Cloudflare One Client Diagnostics Logs.
  6. Leave packet capture disabled unless needed for the issue.
  7. Download the diagnostic bundle when capture completes.

If using the Cloudflare One Client Diagnostic Analyzer beta, treat the analyzer output as a triage aid, not as the final root cause. Keep the original diagnostic bundle attached to the ticket.

What to look for in the Cloudflare One Client diagnostics

Start with three files: warp-settings.txt, warp-status.txt, and daemon.log. Then branch based on symptoms.

flowchart TD
    Start[Open warp-diag bundle] --> Settings[1. warp-settings.txt<br/>Profile, mode, split tunnel,<br/>org, LDF, tunnel protocol]
    Settings --> Status[2. warp-status.txt<br/>Connected state, interfaces,<br/>routes, DNS at capture time]
    Status --> Daemon[3. daemon.log<br/>Errors, warnings,<br/>tunnel negotiation]

    Daemon --> Symptom{Primary symptom?}

    Symptom -->|DNS failure| DNS_Files[daemon_dns.log<br/>warp-dns-stats.txt<br/>dns_stats.log]
    Symptom -->|Connection /<br/>tunnel failure| Conn_Files[connectivity.txt<br/>daemon.log tunnel errors]
    Symptom -->|Wrong profile<br/>or settings| Profile_Files[alternate-networks-check.txt<br/>warp-settings.txt profile ID]
    Symptom -->|Routing /<br/>split tunnel| Route_Files[routetable.txt<br/>ipconfig.txt / interfaces]
    Symptom -->|Device posture<br/>or Access block| Posture_Files[warp-device-posture.txt<br/>warp-account.txt]
    Symptom -->|Identity /<br/>enrollment| Account_Files[warp-account.txt<br/>daemon.log registration events]

    classDef device fill:#a29bfe,stroke:#6c5ce7,color:#000
    classDef info fill:#74b9ff,stroke:#0984e3,color:#000
    classDef file fill:#ffeaa7,stroke:#fdcb6e,color:#000
    class Start device
    class Settings info
    class Status info
    class Daemon info
    class DNS_Files file
    class Conn_Files file
    class Profile_Files file
    class Route_Files file
    class Posture_Files file
    class Account_Files file
Loading

warp-settings.txt

Use this first. It tells you whether the device received the settings you expected.

Check:

  • Organization: Is the device enrolled in the correct Zero Trust organization?
  • Profile ID: Does it match the expected device profile for the user, campus, cohort, or managed network?
  • Mode: Is the client in warp+doh, DNS-only, proxy, or another expected mode?
  • Tunnel protocol: WireGuard or MASQUE. Compare to the profile setting.
  • Split tunnel mode: Include or Exclude.
  • Split tunnel entries: Is the destination included or excluded correctly?
  • Local Domain Fallback: Are internal domains routed to local DNS when intended?
  • Managed network state: Is the device receiving the office, campus, or remote profile expected for its location?
  • Override endpoint or MDM-delivered settings: Do local policy values conflict with dashboard policy?

Red flags:

  • Profile ID does not match the user or location.
  • Private campus CIDR is excluded when it should route through the Cloudflare One Client.
  • Include mode is used but the destination CIDR is missing.
  • Local Domain Fallback sends an internal domain to a DNS server that is unreachable from the user's current path.
  • Tunnel protocol does not match the policy expected for the environment.

warp-status.txt

Use this to understand device state at the moment diagnostics were collected.

Check:

  • Connected, disconnected, connecting, or degraded state.
  • Interface list and active the Cloudflare One Client interface.
  • Current routing table and DNS configuration.
  • Any status message that differs from the user's report.

Red flags:

  • The bundle was collected after the user disconnected the Cloudflare One Client or changed networks.
  • the Cloudflare One Client is disconnected, but the ticket describes a policy block.
  • DNS servers or routes do not match the active the Cloudflare One Client profile.

daemon.log

Use this for connection sequence, repeated warnings, tunnel setup, and service errors.

Check:

  • Version and startup sequence.
  • Registration and organization events.
  • Tunnel protocol negotiation.
  • Repeated connection attempts.
  • Warnings and errors around the timestamp of the issue.
  • Transitions between connected, disconnected, reconnecting, and degraded.

Search patterns:

  • error
  • warn
  • failed
  • dns
  • connectivity
  • masque
  • wireguard
  • registration
  • profile
  • Destination hostname or IP if present

Red flags:

  • Repeated tunnel establishment failures.
  • Errors immediately after network change, sleep, or roaming.
  • DNS errors in daemon.log that align with failures in daemon_dns.log.
  • Profile or settings updates that occur just before the issue begins.

Other useful files

File Use
warp-account.txt Confirms Zero Trust account, device ID, and registration details.
systeminfo.txt Shows OS, hostname, and network interface context.
routetable.txt Confirms whether destination traffic routes through the Cloudflare One Client.
ipconfig.txt or interface files Shows local IP, DNS servers, and active adapters.
daemon_dns.log Best starting point for DNS failures.
warp-dns-stats.txt and dns_stats.log Shows DNS latency, failure patterns, and resolver behavior over time.
connectivity.txt Shows checks inside and outside the tunnel. Useful for connection failures.
warp-device-posture.txt Use when Access or Gateway policy depends on device posture.
alternate-networks-check.txt Use when managed networks or alternate networks affect profile selection.

Cross-reference checklist

A the Cloudflare One Client diagnostic bundle tells you what the device believed. Cross-reference it against Cloudflare and campus systems before changing policy.

Cloudflare Zero Trust dashboard

Check:

  • Device record for the hostname and user.
  • Device ID, the Cloudflare One Client version, OS, last seen time, and profile.
  • Device posture result, if policy uses posture.
  • Device enrollment permissions and IdP group membership.
  • DEX test results for the affected device (configured tests: www.asu.edu, asu.zoom.us, asu.enterprise.slack.com, asu.instructure.com, and a traceroute to 1.1.1.1).
  • Remote diagnostics, if the Cloudflare One Client version supports it.

For Gateway log correlation, use Datadog (Gateway activity logging is disabled in the Cloudflare dashboard). Filter in Datadog by:

  • Source: cloudflare
  • Service: gateway_dns, gateway_http, gateway_network, or zero_trust_network_sessions
  • User email.
  • Device ID.
  • Source IP or the Cloudflare One Client virtual IP.
  • Destination IP, hostname, port, or protocol.
  • Time window.
  • Action: Allow or Block.
  • Policy name.

Cloudflare WAN dashboard and network analytics

Check:

  • CNI (Cloudflare Network Interconnect) link health for the relevant nexthop group:
    • im (on-prem datacenter): 169.254.64.177, 169.254.64.187
    • aws-us-west-2: 169.254.66.7, 169.254.66.9
    • aws-us-east-1: 169.254.65.79, 169.254.65.89
  • Static route for the destination subnet (all routes are static, no BGP).
  • Route priority — lower number = higher preference. A route may be working but on the backup path (e.g., priority 75 im backup when AWS at priority 50 is down).
  • Whether the target subnet is configured in Cloudflare WAN static routes.
  • Magic Firewall rules that could block traffic (currently: SDN blast list block
    • allow-all IPv4 baseline).
  • Network Analytics for traffic from the Cloudflare One Client source ranges to the campus subnet.
  • Recent route or firewall changes.

Campus network services

Ask the owning team to check:

Service What to verify
DNS Internal zone exists, resolver reachable via private network, forwarder rules correct, no split-horizon mismatch.
DHCP User has expected local DNS and gateway before the Cloudflare One Client connects.
IdP User is in the expected group, no conditional access block, no MFA failure. Note: SCIM is disabled — user must re-authenticate to pick up group changes.
MDM (Intune) Cloudflare One Client profile, TLS inspection root certificate, client version, and local policy delivered. Intune compliance status reports correctly.
EDR (CrowdStrike) Correct tenant (Engineering or Main), Falcon version ≥3.6/3.7, sensor config ≥70, process not blocked, network filter not conflicting.
Firewall Cloudflare One Client egress destinations allowed, Cloudflare WAN tunnel traffic allowed, the Cloudflare One Client virtual source range allowed if needed.
Proxy or PAC Cloudflare One Client control traffic is not forced through an intercepting proxy unless designed and tested.
Certificate authority Gateway TLS inspection root certificate (Cloudflare-managed, auto-generated) installed and trusted.
Application owner Destination app is listening, healthy, and allows traffic from the observed source.
Datadog Cloudflare logs (source: cloudflare) show the same action and time window. Check gateway_dns, gateway_network, zero_trust_network_sessions.

Troubleshooting flows and common scenarios

Flow 1: the Cloudflare One Client will not enroll or connect

flowchart TD
    Start[WARP will not<br/>enroll or connect] --> Corporate{Using corporate<br/>Cloudflare One Client?}

    Corporate -->|No| Fix1[Install corporate client,<br/>not consumer WARP]
    Corporate -->|Yes| OrgName{Correct Zero Trust<br/>org name?}

    OrgName -->|No| Fix2[Correct the org name]
    OrgName -->|Yes| IdP{Can user reach<br/>IdP in browser?}

    IdP -->|No| Fix3[Fix IdP access:<br/>network, DNS, or IdP issue]
    IdP -->|Yes| Diag[Collect warp-diag]

    Diag --> Connectivity{connectivity.txt<br/>shows failures?}

    Connectivity -->|Outside-tunnel<br/>checks fail| FW{Local firewall,<br/>EDR, or egress<br/>blocking WARP?}
    Connectivity -->|Inside-tunnel<br/>checks fail| Tunnel[Check daemon.log for<br/>MASQUE/WireGuard errors]
    Connectivity -->|Both pass| DaemonLog[Check daemon.log for<br/>API or registration errors]

    FW -->|Yes| Fix4[Allow WARP ingress IPs,<br/>API endpoints, UDP ports]
    FW -->|No| OtherNet{Same issue on<br/>another network?}

    OtherNet -->|Yes| Escalate[Escalate to Tier 3 /<br/>Cloudflare Support]
    OtherNet -->|No| Fix5[Network-specific block:<br/>check egress, proxy, captive portal]

    Tunnel --> Escalate
    DaemonLog --> Escalate

    classDef problem fill:#d63031,stroke:#b71c1c,color:#fff
    classDef fix fill:#00b894,stroke:#00897b,color:#000
    classDef warning fill:#fdcb6e,stroke:#f39c12,color:#000
    class Start problem
    class Fix1 fix
    class Fix2 fix
    class Fix3 fix
    class Fix4 fix
    class Fix5 fix
    class Escalate warning
Loading

Symptoms:

  • User cannot log in to the organization.
  • the Cloudflare One Client remains disconnected or connecting.
  • the Cloudflare One Client shows connectivity, API, DNS, or tunnel failures.

Tier 1 actions:

  1. Confirm the user is using the corporate Cloudflare One Client, not the consumer WARP app.
  2. Confirm the Zero Trust organization name.
  3. Confirm the user can reach the IdP in a browser.
  4. Collect warp-diag before reinstalling or deleting registration.
  5. Ask whether the issue occurs on another network, such as mobile hotspot.

Tier 2 Desk Side actions:

  1. Check connectivity.txt.
  2. Check daemon.log for API, DNS, MASQUE, WireGuard, or registration errors.
  3. Check warp-settings.txt for mode and tunnel protocol.
  4. Check local firewall, EDR, and campus egress rules.
  5. Confirm the Cloudflare One Client firewall requirements are allowed.

Cloudflare documentation notes that the client uses specific API endpoints, the Cloudflare One Client ingress IPs, DoH endpoints, and connectivity checks. For example, outside-tunnel checks use engage.cloudflareclient.com, 162.159.197.3, and 2606:4700:102::3. Inside-tunnel checks use connectivity.cloudflareclient.com, 162.159.197.4, and 2606:4700:102::4. The client also uses the Cloudflare One Client ingress ranges and UDP ports that depend on WireGuard or MASQUE.

Escalate when:

  • Multiple users on different networks fail at the same time.
  • Diagnostics show repeated tunnel establishment failures with no local firewall explanation.
  • Device enrollment permissions or organization settings appear correct, but registration fails.
  • Cloudflare dashboard cannot start or retrieve diagnostics for an otherwise visible device.

Flow 2: the Cloudflare One Client is connected, but an internal campus app fails

flowchart TD
    Start[Internal campus<br/>app fails] --> DNS{Step 1: DNS<br/>Does FQDN resolve<br/>to correct private IP?}

    DNS -->|NXDOMAIN /<br/>wrong IP| DNS_Check{Local Domain Fallback<br/>or resolver policy<br/>configured?}
    DNS -->|Resolves<br/>correctly| Route{Step 2: Routing<br/>Does traffic route<br/>through WARP interface?}

    DNS_Check -->|LDF configured| LDF{Can device reach<br/>fallback DNS server<br/>from current path?}
    DNS_Check -->|Resolver policy| RP[Check Gateway DNS logs:<br/>query reaching resolver?]
    DNS_Check -->|Neither| Fix_DNS[Configure DNS resolution<br/>for internal domain]

    LDF -->|No| Fix_LDF[Fix LDF reachability or<br/>use resolver policy instead]
    LDF -->|Yes| RP

    Route -->|Not through WARP| Split{Split tunnel mode?}
    Route -->|Through WARP| GW{Step 3: Gateway<br/>Network log shows<br/>Allow or Block?}

    Split -->|Exclude mode| Fix_Excl[Remove destination CIDR<br/>from exclude list]
    Split -->|Include mode| Fix_Incl[Add destination CIDR<br/>to include list]

    GW -->|Block| Fix_GW[Adjust Gateway policy<br/>or add allow rule]
    GW -->|Allow / No log| MWAN{Step 4: Cloudflare WAN<br/>Route exists and<br/>tunnel healthy?}

    MWAN -->|Route missing| Fix_Route[Add route in<br/>Cloudflare WAN config]
    MWAN -->|Tunnel down| Fix_Tunnel[Restore tunnel health:<br/>GRE/IPsec/CNI/Connector]
    MWAN -->|Route + tunnel OK| App{Step 5: Application<br/>App listening? Firewall<br/>allows WARP source?}

    App -->|Firewall blocks<br/>WARP source| Fix_FW[Update campus firewall<br/>to allow WARP/Cloudflare WAN source]
    App -->|App down or<br/>misconfigured| Fix_App[Engage application owner]
    App -->|Return route<br/>missing| Fix_Return[Fix return route to<br/>Cloudflare via the Cloudflare WAN tunnel]

    classDef problem fill:#d63031,stroke:#b71c1c,color:#fff
    classDef fix fill:#00b894,stroke:#00897b,color:#000
    class Start problem
    class Fix_DNS fix
    class Fix_LDF fix
    class Fix_Excl fix
    class Fix_Incl fix
    class Fix_GW fix
    class Fix_Route fix
    class Fix_Tunnel fix
    class Fix_FW fix
    class Fix_App fix
    class Fix_Return fix
Loading

Symptoms:

  • Private FQDN does not resolve.
  • Private IP times out.
  • App works on campus but not remote.
  • App works for some the Cloudflare One Client users but not others.

Use this order: DNS, routing, policy, Cloudflare WAN, application.

Step 1: DNS

Ask the user to test the internal FQDN:

nslookup app.example.edu

If a specific internal DNS server should answer, test it directly:

nslookup app.example.edu <internal-dns-server-ip>

Tier 2 Desk Side checks:

  • Does Gateway DNS log (in Datadog, service: gateway_dns) show the query?
  • ASU uses a resolver policy for asu.edu that routes queries over the private network to 10.120.0.4, 10.120.1.4, 10.120.2.4. This works on and off campus. Subdomains devops.asu.edu, apps.asu.edu, and weblogin.asu.edu are excluded from this resolver policy and resolve via Gateway's default resolver.
  • Local Domain Fallback at ASU only handles generic suffixes (.local, .internal, .lan, .home.arpa, etc.) — NOT asu.edu.
  • Does daemon_dns.log show timeout, NXDOMAIN, SERVFAIL, or fallback behavior?
  • If DNS fails for asu.edu subdomains, the issue is likely CNI connectivity (the private path to 10.120.0.x is down), not a missing LDF entry.

Step 2: Routing on the device

Check whether the private destination routes through the Cloudflare One Client.

Windows:

Find-NetRoute -RemoteIPAddress "<destination-ip>" | Select-Object InterfaceAlias -Last 1

Expected result for WARP-routed traffic: CloudflareWARP.

macOS:

route get <destination-ip>

Expected result for WARP-routed traffic: a the Cloudflare One Client tunnel interface such as utun.

Linux:

ip route get <destination-ip>

Expected result for WARP-routed traffic: dev CloudflareWARP or equivalent the Cloudflare One Client interface.

If traffic is not routed through the Cloudflare One Client:

  • In Exclude mode, confirm the destination IP or parent CIDR is not excluded.
  • In Include mode, confirm the destination IP or CIDR is included.
  • Confirm the user is on the expected device profile.
  • Confirm profile changes have reached the device.

Step 3: Gateway policy

Check Gateway Network logs or Network Session Logs:

  • Filter by user, device ID, destination IP, port, and timestamp.
  • Check Action and Policy Name.
  • Confirm whether a default-deny private network policy blocked the flow.
  • Confirm whether a higher-precedence allow rule should have matched.

If no Gateway log exists, the traffic may not have reached Gateway or may be taking a different off-ramp.

Step 4: Cloudflare WAN path

Check Cloudflare WAN:

  • Is the destination subnet present in the Cloudflare WAN static route table?
  • Which CNI nexthop group handles this route (im for on-prem, aws-us-west-2, or aws-us-east-1)?
  • Are the CNI link-local endpoints for that group healthy?
  • What priority is the route using — is it on primary or backup path?
  • Is Magic Firewall allowing the flow (check the SDN blast block list)?
  • Does the campus firewall allow traffic from the observed Cloudflare or the Cloudflare One Client source range?
  • Does Network Analytics show packets toward the site?

If the route is missing or points to the wrong nexthop, the client can be healthy while the private app still fails.

Step 5: Application and campus service

Ask the application or network owner to confirm:

  • The destination IP and port are correct.
  • The app is listening.
  • Campus firewall allows the source seen from Cloudflare WAN.
  • Return route is correct.
  • DNS answer points to the intended private IP.
  • The app does not restrict access by legacy VPN source ranges only.

Flow 3: the Cloudflare One Client is connected, but an Internet site fails

flowchart TD
    Start[Internet site fails<br/>with WARP connected] --> Scope{All sites<br/>or one site?}

    Scope -->|All sites| Connect{WARP status<br/>shows connected?}
    Scope -->|One site| Error{What error<br/>does user see?}

    Connect -->|Degraded /<br/>reconnecting| Flow1[Go to Flow 1:<br/>Connection issue]
    Connect -->|Connected| DNS_All[Check Gateway DNS logs<br/>for all queries failing]

    Error -->|Block page| GW_HTTP[Check Gateway HTTP logs:<br/>policy name and action]
    Error -->|Certificate<br/>warning| Cert{TLS inspection<br/>cert installed<br/>and trusted?}
    Error -->|Timeout| GW_Net[Check Gateway Network /<br/>Session logs for TCP block]
    Error -->|DNS failure| GW_DNS[Check Gateway DNS logs:<br/>block or category match?]

    GW_HTTP -->|Policy block| Fix_Policy[Adjust Gateway HTTP policy<br/>or add bypass rule]
    GW_HTTP -->|No block logged| Proxy{Browser proxy,<br/>PAC, or local<br/>HTTPS inspection?}

    Cert -->|Not installed| Fix_Cert[Deploy TLS inspection<br/>root certificate via MDM]
    Cert -->|Installed but<br/>another product<br/>intercepts| Fix_Conflict[Disable conflicting<br/>TLS inspection product]
    Cert -->|Installed, site<br/>uses cert pinning| Fix_Pin[Add Do Not Inspect<br/>policy for pinned domain]

    GW_Net -->|Block found| Fix_Policy
    GW_Net -->|No log| Proxy

    GW_DNS -->|DNS block| Fix_DNS[Adjust Gateway DNS policy]
    GW_DNS -->|No block| Proxy

    Proxy -->|Yes| Fix_Proxy[Remove conflicting proxy/PAC<br/>or exclude from inspection]
    Proxy -->|No| Escalate[Escalate: collect warp-diag,<br/>timestamps, destination]

    DNS_All --> Escalate

    classDef problem fill:#d63031,stroke:#b71c1c,color:#fff
    classDef fix fill:#00b894,stroke:#00897b,color:#000
    classDef warning fill:#fdcb6e,stroke:#f39c12,color:#000
    classDef info fill:#74b9ff,stroke:#0984e3,color:#000
    class Start problem
    class Fix_Policy fix
    class Fix_Cert fix
    class Fix_Conflict fix
    class Fix_Pin fix
    class Fix_DNS fix
    class Fix_Proxy fix
    class Escalate warning
    class Flow1 info
Loading

Symptoms:

  • Browser shows Cloudflare block page.
  • Browser shows certificate warning.
  • Site times out only when the Cloudflare One Client is connected.
  • DNS resolution differs with the Cloudflare One Client on and off.

Tier 1 actions:

  1. Capture the URL, hostname, error, timestamp, and screenshot.
  2. Ask if the issue is all sites or one site.
  3. Collect the Cloudflare One Client diagnostics.
  4. Ask if the issue occurs on another network.

Tier 2 Desk Side checks:

  • Gateway DNS logs for DNS block or category match.
  • Gateway HTTP logs for block action, isolate action, DLP, AV, or policy name.
  • Gateway Network logs or Network Session Logs for TCP or UDP block.
  • TLS inspection root certificate on the endpoint.
  • Browser proxy or PAC settings.
  • Local firewall or EDR HTTPS inspection.

Certificate errors usually point to one of three causes:

  1. Gateway TLS inspection certificate is missing or not trusted.
  2. Another local security product is intercepting TLS.
  3. The app uses certificate pinning and needs a bypass policy.

Flow 4: Issue only happens on campus or only off campus

flowchart TD
    Start[Issue only on campus<br/>OR only off campus] --> Where{Where does<br/>it fail?}

    Where -->|Fails ON campus<br/>works off campus| OnCampus{Campus egress<br/>blocking WARP?}
    Where -->|Fails OFF campus<br/>works on campus| OffCampus{What breaks<br/>off campus?}

    OnCampus -->|WARP IPs/ports<br/>blocked| Fix_Egress[Allow WARP ingress IPs<br/>and UDP ports on campus FW]
    OnCampus -->|Captive portal<br/>interfering| Fix_Captive[Exempt WARP from<br/>captive portal / segmentation]
    OnCampus -->|Proxy/PAC<br/>intercepting| Fix_PAC[Exclude WARP control<br/>traffic from proxy/PAC]
    OnCampus -->|Wi-Fi DNS<br/>interception| Fix_WiFi[Fix DNS interception<br/>or allow DoH endpoints]
    OnCampus -->|None of above| Check_Profile[Compare managed network<br/>profile on vs off campus]

    OffCampus -->|DNS for internal<br/>domain fails| LDF{Local Domain Fallback<br/>points to campus-only DNS?}
    OffCampus -->|Private app<br/>unreachable| Split{Split tunnel or profile<br/>differs by location?}
    OffCampus -->|WARP tunnel<br/>fails to establish| ISP[Home network / ISP<br/>blocking UDP paths?]

    LDF -->|Yes| Fix_LDF[Use resolver policy instead,<br/>or route DNS through private path]
    LDF -->|No| Check_Resolver[Check resolver reachability<br/>via Cloudflare WAN / Tunnel]

    Split -->|Different profile| Fix_Profile[Align managed network<br/>profile for remote users]
    Split -->|Same profile| Flow2[Go to Flow 2:<br/>check route + Cloudflare WAN path]

    ISP --> Fix_ISP[Test alternate network;<br/>check MASQUE vs WireGuard]

    classDef problem fill:#d63031,stroke:#b71c1c,color:#fff
    classDef fix fill:#00b894,stroke:#00897b,color:#000
    classDef info fill:#74b9ff,stroke:#0984e3,color:#000
    class Start problem
    class Fix_Egress fix
    class Fix_Captive fix
    class Fix_PAC fix
    class Fix_WiFi fix
    class Fix_LDF fix
    class Fix_Profile fix
    class Fix_ISP fix
    class Flow2 info
Loading

If the same device works off campus but fails on campus, check campus egress controls first:

  • the Cloudflare One Client ingress IPs and ports.
  • Client orchestration API endpoints.
  • Captive portal checks.
  • DoH endpoints if DNS-only mode is used.
  • Local firewall, proxy, or PAC rules.
  • Wi-Fi segmentation and DNS interception.

If the same device works on campus but fails off campus, check:

  • Split tunnel differences by managed network profile. Note: the Campus profile forces WireGuard; the Default profile has no protocol preference. If the issue is tunnel-protocol-related, it only manifests off campus.
  • ASU's asu.edu resolver policy routes DNS through the private network and works regardless of location. If DNS fails off campus, suspect CNI health, not LDF configuration.
  • Private DNS resolver reachability through Cloudflare WAN or Cloudflare Tunnel.
  • Device profile selected by location (verify managed network detection: TLS probe to 10.220.75.12:443).
  • Home network or ISP blocking UDP paths.

Flow 5: Issue affects many users at once

flowchart TD
    Start[Multiple users<br/>affected simultaneously] --> Common{What do affected<br/>users share?}

    Common -->|Same WARP<br/>profile / OS| Profile[Recent WARP profile<br/>or MDM rollout change?]
    Common -->|Same campus<br/>site / subnet| MWAN[Cloudflare WAN tunnel<br/>or route change?]
    Common -->|Same IdP<br/>group| IdP[IdP group sync<br/>or SCIM change?]
    Common -->|Same<br/>destination| App[Application or<br/>campus service down?]
    Common -->|All WARP<br/>users| Global[Cloudflare platform<br/>or Gateway policy change?]

    Profile -->|Yes| Fix_Profile[Roll back profile /<br/>MDM change]
    Profile -->|No| GW_Policy[Check Gateway<br/>policy changes]

    MWAN -->|Tunnel down| Fix_Tunnel[Restore Cloudflare WAN<br/>tunnel health]
    MWAN -->|Route changed| Fix_Route[Correct Cloudflare WAN<br/>route configuration]
    MWAN -->|No change| Campus_FW[Check campus firewall<br/>or DNS changes]

    IdP -->|Group removed<br/>or sync failed| Fix_IdP[Restore IdP group<br/>membership / user must re-auth]
    IdP -->|No change| GW_Policy

    App -->|Yes| Fix_App[Engage app owner /<br/>campus service team]
    App -->|No| GW_Policy

    Global -->|Policy change<br/>found| Fix_GW[Roll back Gateway<br/>policy change]
    Global -->|No change| CF_Health[Check Cloudflare<br/>status page and<br/>escalate to Cloudflare]

    GW_Policy --> Fix_GW
    Campus_FW --> Fix_Campus[Revert campus<br/>firewall / DNS change]

    classDef problem fill:#d63031,stroke:#b71c1c,color:#fff
    classDef fix fill:#00b894,stroke:#00897b,color:#000
    classDef warning fill:#fdcb6e,stroke:#f39c12,color:#000
    class Start problem
    class Fix_Profile fix
    class Fix_Tunnel fix
    class Fix_Route fix
    class Fix_IdP fix
    class Fix_App fix
    class Fix_GW fix
    class Fix_Campus fix
    class CF_Health warning
Loading

Treat this as a potential service, routing, policy, or deployment change.

Tier 2 Desk Side and Tier 3 should check:

  • Recent the Cloudflare One Client device profile changes.
  • Recent Gateway policy changes.
  • IdP group changes (SCIM is disabled — group membership only updates on re-authentication, not in real time).
  • MDM profile rollout or the Cloudflare One Client version rollout.
  • Cloudflare WAN route or tunnel changes.
  • Campus firewall or DNS changes.
  • Cloudflare dashboard health and analytics.
  • Whether all failures share the same site, route, profile, IdP group, OS, or the Cloudflare One Client version.

Support tier operating model

flowchart TD
    User[Staff Member<br/>Reports Issue] --> T1[Tier 1 Help Desk]

    T1 -->|Intake complete,<br/>cannot resolve| T2[Tier 2 Desk Side Support]
    T1 -->|Common fix<br/>applied| Resolved[Resolved]

    T2 -->|Hands-on triage,<br/>evidence gathered| T3[Tier 3 Network / Security /<br/>Cloudflare Admins]
    T2 -->|Endpoint issue<br/>resolved| Resolved

    T3 -->|Complete escalation<br/>package| CF[Cloudflare Support]
    T3 -->|Route/policy/tunnel<br/>fix applied| Resolved
    T3 -->|Campus service<br/>issue found| Campus[Campus Service Owner]

    CF -->|Account-level fix<br/>or guidance| Resolved
    Campus -->|Service restored| Resolved

    classDef device fill:#a29bfe,stroke:#6c5ce7,color:#000
    classDef info fill:#74b9ff,stroke:#0984e3,color:#000
    classDef warning fill:#fdcb6e,stroke:#f39c12,color:#000
    classDef escalate fill:#e17055,stroke:#d63031,color:#fff
    classDef cloudflare fill:#f08c00,stroke:#d56a00,color:#fff
    classDef fix fill:#00b894,stroke:#00897b,color:#000
    class User device
    class T1 info
    class T2 warning
    class T3 escalate
    class CF cloudflare
    class Campus fix
    class Resolved fix
Loading

Tier 1 Help Desk

Tier 1 is the help desk that ASU staff contact first. Tier 1 owns intake, first classification, and common or easily fixed issues.

Actions:

  1. Confirm the user is enrolled in the correct Cloudflare One organization.
  2. Capture identity, device, location, network, destination, timestamp, and screenshot.
  3. Ask whether the issue happens with the Cloudflare One Client on, the Cloudflare One Client off, and on another network.
  4. Collect warp-diag or mobile diagnostics when the user can run the steps, or escalate to Desk Side when hands-on help is needed.
  5. Classify the issue:
    • Enrollment or connection
    • DNS
    • Routing
    • Policy block
    • Certificate error
    • Private app over Cloudflare WAN
    • Internet site
    • Broad outage
  6. Attach all evidence to the ticket.
  7. Escalate to Tier 2 Desk Side with a clear expected path and the intake template completed.

Tier 1 should not:

  • Delete the Cloudflare One Client registration unless instructed.
  • Reinstall the Cloudflare One Client before diagnostics are collected.
  • Change split tunnel, Gateway, Cloudflare WAN, or IdP policy.
  • Assume every private app failure is a Cloudflare issue before checking DNS and routing.

Tier 2 Desk Side Support

Tier 2 is ASU's Desk Side team. This team can physically show up to a user's desk when needed and has practical experience with software, applications, and common endpoint troubleshooting. Desk Side will likely own most hands-on the Cloudflare One Client troubleshooting unless the issue is a common and easily fixed Tier 1 item.

Actions:

  1. Review warp-settings.txt, warp-status.txt, daemon.log, and symptom-specific files.
  2. Confirm device profile, split tunnel, local domain fallback, tunnel protocol, and organization.
  3. Confirm DNS behavior in daemon_dns.log, Gateway DNS logs, and internal resolver logs.
  4. Confirm route behavior using routetable.txt and OS route commands.
  5. Review Gateway DNS, HTTP, Network, or Network Session logs where Desk Side has access, or request log validation from the Tier 3 or Cloudflare administrator team.
  6. Check MDM, EDR, certificate deployment, local firewall, proxy, PAC file, and other endpoint controls.
  7. Confirm whether the destination should use Cloudflare WAN, Cloudflare Tunnel, Gateway, Access, or local network.
  8. Gather the information required for a Cloudflare Support case when the issue cannot be resolved locally.
  9. Escalate to Tier 3 with evidence, a hypothesis, and the Cloudflare escalation package started.

Tier 2 Desk Side should be trained on:

  • How to collect and preserve the Cloudflare One Client diagnostics before changing settings.
  • Which files matter first: warp-settings.txt, warp-status.txt, daemon.log, daemon_dns.log, routetable.txt, and connectivity.txt.
  • How to decide whether an issue is endpoint, DNS, Gateway policy, Cloudflare WAN route, campus firewall, or application-owned.
  • How to gather timestamps, device ID, user identity, destination, expected path, and reproduction steps.
  • How to open, update, and manage a Cloudflare Support case with complete evidence.
  • When to escalate to ASU Tier 3 versus Cloudflare Support.

Tier 2 should document:

  • Expected path.
  • Actual observed path.
  • Matching Gateway policy or absence of a log.
  • Device profile ID.
  • Destination DNS answer.
  • Device route decision.
  • Any local security product or network control in the path.
  • What was attempted at the user's desk or during hands-on troubleshooting.

Tier 3 Network, Security, and Cloudflare Administrators

Tier 3 owns route, tunnel, account-level validation, and coordination with Cloudflare Support.

Actions:

  1. Validate Cloudflare WAN CNI health, static route table, route priorities, and Magic Firewall.
  2. Validate Gateway policy order and exception rules.
  3. Validate resolver policies and internal DNS reachability over the private network.
  4. Compare Cloudflare logs in Datadog with campus firewall, DNS, IdP, MDM, EDR, and other campus system logs.
  5. Start remote diagnostics or packet capture if needed.
  6. Confirm whether any recent Cloudflare account configuration changed the Cloudflare One Client, Gateway, Tunnel, or Cloudflare WAN integration.
  7. Escalate to Cloudflare with a complete evidence package.
  8. Coach Tier 2 Desk Side on what to collect earlier next time when escalations arrive incomplete.

Cloudflare escalation package:

  • Account name and Zero Trust organization.
  • Device ID and the Cloudflare One Client registration details.
  • User email.
  • the Cloudflare One Client version and OS version.
  • warp-diag zip or remote diagnostics capture.
  • Exact timestamps with timezone.
  • Destination FQDN, IP, port, and protocol.
  • Expected path and actual observed path.
  • Gateway log excerpts or confirmation that no log appears.
  • Cloudflare WAN route and tunnel evidence.
  • Campus network service evidence, if relevant.
  • Recent changes.
  • Scope and impact.
  • Steps already attempted.

Common pitfalls

What goes wrong Why it happens How to avoid it
Diagnostics collected after toggling the Cloudflare One Client or changing networks The evidence no longer reflects the failure Collect warp-diag first. Then test changes.
Private app fails because RFC 1918 traffic is still excluded Cloudflare One Client excludes private ranges by default ASU's profiles do NOT exclude 10.0.0.0/8 or 172.16.0.0/12. Check for 10.153.0.0/16 (ASU WiFi) exclusion.
DNS is treated as routing Private app name never resolved to the intended private IP Test DNS first, then route.
User matches the wrong device profile Managed network detection (TLS probe to 10.220.75.12:443) fails or succeeds unexpectedly Compare Profile ID in warp-settings.txt to dashboard profile rules. Check if campus profile activated.
Internal DNS fails off campus CNI path to 10.120.0.x resolvers is unhealthy Check CNI nexthop health. ASU does NOT use LDF for asu.edu — resolver policy goes over private network.
Gateway block is missed because dashboard logs are checked Gateway activity logging is disabled in the Cloudflare dashboard Check Datadog (source: cloudflare, service: gateway_dns/gateway_http/gateway_network).
Cloudflare WAN route is assumed healthy because the Cloudflare One Client is connected Cloudflare One Client and Cloudflare WAN are separate legs of the path Check CNI link health, static route table, route priority, Magic Firewall, and campus return path.
Certificate errors are misclassified as connectivity failures TLS inspection certificate is missing or another product intercepts TLS Verify the Cloudflare-managed root certificate and bypass pinned apps where required.
Legacy VPN assumptions remain in firewall rules Apps allow old VPN source ranges but not the Cloudflare One Client or Cloudflare WAN observed sources Update firewall and app allowlists based on the new traffic path.
User's group membership appears stale SCIM is disabled; groups only update at authentication time User must re-authenticate (log out of Cloudflare One Client and log back in) to pick up IdP group changes.
Device posture fails for sensitive resources (QFS, LSV, EDNA portal) CrowdStrike wrong tenant, version too old, disk encryption off, or OS below minimum Check posture rules: CrowdStrike ≥3.6/3.7, disk encryption on all drives, OS version thresholds met.
ASU WiFi traffic fails when expected to go through WARP 10.153.0.0/16 is excluded from the tunnel on both profiles ASU WiFi traffic is intentionally direct. If the resource requires WARP, it won't work over ASU WiFi alone.
Campus app access via WARP is slow but functional Known CNI egress + WARP performance constraint (architectural decision pending) Do not escalate as a new bug. This is a known condition. Escalate only if access fully fails, not just slow.
User accesses posture-gated resource despite failing posture Device posture checks run on a 5-minute interval; sessions are not revoked mid-flight Wait one interval (5 min), then re-check. Posture violations don't take effect until the next evaluation cycle.
Cloudflare receives incomplete escalations Missing timestamps, device ID, or diagnostic bundle Use the Tier 3 Cloudflare escalation package.

ASU support channels

Channel Purpose
Slack: #cloudflare-one-trust-based-access Primary user-facing support channel (linked from WARP client and block pages)
Email: cloudflare-zero-trust@asu.edu Gateway block page contact for policy exceptions
Cloudflare org: asu.cloudflareaccess.com Zero Trust auth domain

Related resources

Public Cloudflare documentation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment