Cloudflare WARP deployment guide
This guide helps teams plan Cloudflare WARP deployment with pilot groups, device enrollment, profile targeting, split tunnel behavior, DNS settings, private routes, Gateway policies, posture checks, troubleshooting, and rollback.
This guide helps teams plan Cloudflare WARP deployment with pilot groups, device enrollment, profile targeting, split tunnel behavior, DNS settings, private routes, Gateway policies, posture checks, troubleshooting, and rollback.
Topics: cloudflare, resource, cloudflare, warp, deployment, guide
Machine-readable context: /ai-index.json
Step by step
Implementation steps
- 1
Define which platforms and device populations are in scope (Windows, macOS, Linux, iOS, Android) and separate managed devices from unmanaged or BYOD, since each needs a different enrollment approach.
- 2
Choose the enrollment method per platform: silent managed deployment of the WARP client via MDM/Intune/Jamf with pre-seeded configuration, versus user-driven install and login for unmanaged devices.
- 3
Design WARP device profiles and the rules that target them — by user group, OS, or enrollment state — so the right profile applies to the right devices automatically.
- 4
Decide the split-tunnel mode: include-only (route just defined destinations through WARP) or exclude (route everything except listed destinations), and list the routes, IP ranges, and domains each mode must cover.
- 5
Configure DNS behaviour and local domain fallback so internal and corporate hostnames resolve correctly while WARP is active.
- 6
Attach the Gateway DNS, HTTP, and network policies and any device posture checks that should apply once a device is enrolled, starting posture in monitor mode.
- 7
Pilot with a small group: validate enrollment, profile targeting, split-tunnel routing, private-route reachability, and posture evaluation, then capture the common support issues.
- 8
Stage the broader rollout by group with a rollback path (profile reassignment or client removal) and a support runbook for enrollment, DNS, and posture failures.
Risk register
Risks to control
Split-tunnel mode is misconfigured, either forcing all traffic through WARP and degrading performance, or excluding traffic that should be inspected.
Pick include or exclude mode deliberately, enumerate the exact routes and domains, and validate real traffic paths with the pilot group before scaling.
The WARP client cannot be pushed silently because the MDM configuration or pre-seeded org token is missing.
Prepare the managed-deployment configuration per platform (including the enrollment token and team name) and test a silent install on a managed device first.
Internal hostnames stop resolving once WARP changes the device's DNS path.
Configure local domain fallback for internal domains and verify resolution of corporate hostnames on a pilot device before wider rollout.
Profile targeting rules overlap or conflict, so devices receive the wrong WARP profile.
Keep targeting rules specific and ordered, and confirm each test device lands on the intended profile before enabling for a group.
Posture checks block enrollment or connectivity for devices that are only marginally out of compliance.
Run posture in monitor mode first to baseline the fleet, then move to enforcement once the spread of device states is understood.
Users can't get help when enrollment or connectivity fails, generating tickets and abandoned installs.
Publish a short enrollment guide and a support runbook covering login, DNS, split-tunnel, and posture issues before the rollout begins.
Output
Useful deliverables
- A device-scope matrix listing platforms and separating managed from unmanaged/BYOD devices.
- A per-platform enrollment plan (silent MDM deployment with pre-seeded config versus user-driven install).
- WARP device profiles with documented targeting rules.
- A split-tunnel design specifying include or exclude mode and the exact routes, ranges, and domains.
- DNS and local domain fallback configuration for internal hostname resolution.
- Attached Gateway policies and device posture checks, with posture starting in monitor mode.
- A pilot validation report plus a rollout sequence, rollback path, and support runbook.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
How is the WARP client deployed to managed devices?
Through your MDM (such as Intune or Jamf) using a silent install with pre-seeded configuration — the organisation/team name and an enrollment token — so the client connects without each user logging in manually. Unmanaged devices instead use a user-driven install and login.
What is the difference between include and exclude split-tunnel modes?
Include-only mode sends just the destinations you list through WARP and leaves everything else direct; exclude mode sends everything through WARP except the destinations you list. The choice determines what Gateway inspects and what bypasses Cloudflare One.
Why do internal sites stop loading after WARP is enabled?
Usually because internal hostnames are no longer resolving on the device's normal DNS path. Configuring local domain fallback for those internal domains, and confirming it on a pilot device, restores resolution while WARP stays active.
Should device posture checks be enforced from the start?
It is safer to run posture signals in monitor mode first so you can see how the real fleet measures up, then move to enforcement. Enforcing strict posture on day one risks locking out devices that are only slightly out of date.
Nanosek
Plan WARP deployment
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.