Module 3b — Device Profiles Configuration

Goal: Apply different Cloudflare One Client settings to different groups of devices — so managed laptops, BYOD phones, servers, and contractors each get exactly the right mode, split-tunnel, and DNS behavior.

This is an optional deep-dive that expands Part B of Module 3. If every device in your org should behave identically, the single Default profile is enough — come back here when you need laptops, BYOD, servers, or contractors to differ.

What a device profile is

A device profile is a named bundle of Cloudflare One Client settings (mode, split tunnels, DNS behavior, switch lock, etc.) plus match rules that decide which devices it applies to. When a device connects, Cloudflare picks one profile for it based on those rules.

There are two layers of settings:

📺 Where these live: Zero Trust → Team & Resources → Devices → Device profiles. Profiles are under General profiles. (Older dashboards put this under Settings → WARP Client — same feature.)

⏱️ Heads-up: changes can take up to 10 minutes to reach devices.

The five client modes (decide this per profile first)

The mode is the most important setting in a profile — it decides which Zero Trust features work on that device.

💡 Tip: Most organizations use Gateway with WARP for managed laptops and Device Information Only (or Include-mode Gateway with WARP) for BYOD.

Part A — Create a device profile

1. 👉 Zero Trust → Team & Resources → Devices → Device profiles → General profiles.
2. 👉 Click Create new profile.
   • 📺 What you'll see: the new profile starts as a copy of your Default profile, so you only change what's different.
3. ⌨️ Name the profile clearly, e.g. BYOD phones or Linux servers.
4. 👉 Create the match rules that define which devices get this profile — see Part B.
5. 👉 Configure the client settings for these devices (mode, switch lock, auto-connect, etc.).
6. 👉 Click Create profile.
   • ⚠️ Watch out: Split Tunnels and Local Domain Fallback can only be edited after you save the profile. Create it first, then reopen it to set those (Part D and Part E).
7. 👉 Back in the list, drag the profile into the right position — order matters (Part C).

✅ Checkpoint: Your new profile appears in the Profile settings list, above the Default profile.

Part B — Match rules (selectors)

Match rules decide which devices use the profile. You build them from selectors, operators, and values.

⚠️ Identity-based selectors (email, groups, SAML) only work if the user enrolled by logging in to your IdP. Service-token-enrolled devices can't match on identity — use OS, managed network, or service token instead.

Operators:

💡 Example — a "Contractors" profile: Selector User group names · operator is · value contractors. Now anyone in your IdP's contractors group automatically gets this profile's (tighter) settings.

Part C — Order of precedence (how a device gets matched)

This is the part people most often get wrong, so it's worth understanding clearly:

1. When a device connects, Cloudflare reads the profile list top to bottom.
2. It uses the first profile the device matches — then stops. No profile lower down can override it.
3. The Default profile is always pinned at the bottom and applies only if the device matched nothing above it.

   Profile list (evaluated top ↓ bottom)     A Windows laptop in "finance" group…
   ┌─────────────────────────────────────┐
   │ 1. Linux servers      (os = linux)   │  ✗ not linux
   │ 2. Finance team       (group finance)│  ✓ MATCH → gets this profile, stops here
   │ 3. BYOD phones        (os = ios/andr)│  (never evaluated)
   │ 4. Default            (always last)  │  (never evaluated)
   └─────────────────────────────────────┘

⚠️ Watch out: put your most specific profiles higher, and broader ones lower. If a broad profile (e.g. "all Windows") sits above a narrow one (e.g. "Windows in finance"), the narrow one will never match.

💡 Tip: If you promote a custom profile to be the Default, all of its settings are copied into the Default profile.

Part D — Split Tunnels (per profile)

Split Tunnels decide which IP traffic goes through Cloudflare vs. around it. Configure it after saving the profile (open the profile → Split Tunnels → Manage).

Common reasons to use it: run the Cloudflare One Client alongside a VPN (Exclude mode), or grant access to one specific private network (Include mode).

The two modes

⚠️ Switching modes wipes your entries. When you change between Exclude and Include, the list reverts to Cloudflare's defaults. Copy your current entries first (Manage → note them down) so you can re-add them.

🔑 Split Tunnels only affect IP traffic — not DNS

This is the single most misunderstood point. Split Tunnels control where IP packets flow. DNS is separate: even if you exclude a site's IP, its DNS query is still resolved by Gateway (and subject to your DNS policies) unless you also add that domain to Local Domain Fallback (Part E). Split Tunnels and Local Domain Fallback are designed to work together for private resources.

Entry types — IP address vs domain

When you click Manage → add, you choose IP Address or Domain:

• IP address / CIDR (⭐ preferred) — e.g. 10.0.0.0/8. Fast and predictable. To carve a smaller range out of a larger one, use the built-in CIDR calculator in the UI.
• Domain — e.g. example.com. When a user visits it, the domain is resolved (by Gateway, or by your private DNS via Local Domain Fallback), and Split Tunnels then dynamically include/exclude the returned IP. If the domain has no public DNS record, you must add a Local Domain Fallback entry (Part E) so it can resolve.

💡 Prefer IPs over domains. Domains are slower — the client must do on-the-fly IP lookups and rewrite the routing table / local firewall each time. Keep the list short: every entry adds parsing time, and there are per-account limits.

Defaults to know

• Exclude mode already excludes RFC 1918 private ranges, the CGNAT range 100.64.0.0/10 (used by Cloudflare One services), and multicast ranges.
• ⚠️ If you need to reach private apps/hostnames via the client:
  • Exclude mode: remove 100.64.0.0/10 from the exclude list (and add back any non-Cloudflare CGNAT ranges you actually use locally, to avoid conflicts).
  • Include mode: add these so private hostnames resolve — IPv4 100.80.0.0/16 and IPv6 2606:4700:0cf1:4000::/64, plus your private network's own CIDRs.

Common Exclude-mode use cases

• Microsoft 365 / Teams / Zoom / VoIP — apps that need the user's real device IP, or are latency-sensitive, often perform better excluded. (There's a one-click Directly route Microsoft 365 traffic option in device settings.)
• Running beside an existing VPN during a phased migration.

⚠️ Trade-off: anything you exclude bypasses Gateway — you lose filtering, DLP, and logging for that traffic. Don't exclude a destination if you need visibility or policy on it.

💡 Tip: To route a private network (e.g. 10.50.0.0/16) to users, add that CIDR in Include mode, or make sure it isn't excluded in Exclude mode.

Part E — Local Domain Fallback

Local Domain Fallback (LDF) tells the client to resolve certain domains using a private/internal DNS resolver you manage, instead of sending those DNS queries to Cloudflare Gateway. The client proxies matching lookups directly to the DNS servers you specify.

Use it for: Active Directory, *.internal, and other private-only domains that public DNS (and Cloudflare) can't resolve — especially when the DNS server is reachable only from the user's device.

Built-in defaults (already handled for you)

Out of the box, Zero Trust keeps common local-resolution top-level domains off Gateway and lets the device's own resolver handle them. The default suffixes are:

corp · domain · home · home.arpa · host · internal · intranet · invalid · lan · local · localdomain · localhost · private · test

You only need to add entries for private domains outside that list (e.g. acme.internal, ad.acme.com).

How to add an entry

1. 👉 Open the profile → Local Domain Fallback → Manage (editable only after the profile is saved).
2. ⌨️ Domain — enter the apex domain, e.g. example.com. It's treated as *.example.com, so all subdomains are covered.
3. ⌨️ DNS Servers — enter the IP(s) of the resolver(s) that should answer it (e.g. 10.0.0.25). Keep it to ≤ 8 servers for performance. The client queries all of them and uses the fastest response — even if that response is "no records found", so always specify at least one reliable server. (Leave blank and the client falls back to whatever DNS the device used before WARP started.)
4. ⌨️ Add an optional description → Save domain.

LDF is scoped per device profile. A profile with no LDF resource just uses the default suffixes above.

⚠️ Important limitation — no Gateway visibility

DNS queries handled by Local Domain Fallback bypass the Gateway resolver, so they are not subject to Gateway DNS policies and do not appear in DNS logs. If you need filtering or logging on private DNS, use resolver policies instead.

LDF vs. resolver policies — which to use?

⭐ Recommendation: if your DNS server can reach a Cloudflare on-ramp, prefer resolver policies for the logging/visibility. If both are configured on the same device, Local Domain Fallback rules apply first.

⚠️ AWS gotcha: don't route all *.amazonaws.com to an internal Route 53 resolver — public AWS endpoints (e.g. ssm.us-east-1.amazonaws.com) won't resolve and features break. Route only specific Route 53 zones or VPC endpoints (vpce.amazonaws.com).

Verify

• 👉 On a device, run warp-cli settings and check the fallback domains section to confirm your entries are applied.

Part F — Global device client settings (all devices)

These sit outside profiles and apply org-wide. Find them under Team & Resources → Devices → Device settings (global section):

Part G — Verify which profile a device got

Via the dashboard:

1. 👉 Team & Resources → Devices → open a device → check its assigned profile.

Via the device (CLI):

warp-cli settings

• 📺 Look for the Profile ID field — it shows the UUID of the profile currently applied.

✅ Checkpoint: Your test device reports the profile you expect (e.g. the BYOD device shows the BYOD profile, not Default).

Worked examples (copy these patterns)

✅ Module 3b complete!

You now have:

• ✅ An understanding of global vs. profile settings and the five client modes
• ✅ One or more custom device profiles with match rules
• ✅ Correct order of precedence (specific profiles above broad ones)
• ✅ Per-profile split tunnels and local domain fallback set as needed
• ✅ A way to verify which profile a device received

Quick troubleshooting

👉 Next: Module 4 — ZTNA / Access

Publish your first private application and replace VPN access to it.