WARP and device posture

Task

Now that we have an Identity Provider configured, we’re going to use it to enroll a user with a WARP client

Why

  • Like a VPN client, WARP client allows you to protect user traffic by sending it securely and privately from user’s device to Cloudflare’s edge network
  • Unlike a VPN, granular Zero Trust policies are then applied on this traffic, controlling precisely which internal and external resources can be accessed
  • Additionally, the client reports on the device posture, allowing you to build policies checking if for example the OS is updated

Steps

1. Configure enrollment policy for WARP

First, let’s define who can connect devices to your organization.

  • In your Zero Trust dashboard, navigate to Settings ‣ WARP Client ‣ Device enrollment permissions ‣ Manage ‣ Add a rule
  • When the rule wizard appears, create a new ruleset, with Rule action Allow, and choose the Emails or Emails ending in selector
  • Set the Value field to your admin's SAML email: [email protected]
Device enrollment rules
  • Once rule is created, Save your policy.

2. Test your connection to the WARP device client

On your lab Win11 VM, open the preinstalled WARP client and select Preferences:

Then Account ‣ Login to Cloudflare Zero Trust:

Use your LAB_SLUG when asked for a team name:

Click on Sign in with: SAML and log in as [email protected] with password #Savetheinternet.

ℹ️
Do not use the login code via email since you can't access inbox of the SAML user ([email protected]).

Once you are authenticated, click on the big grey button in the WARP client to connect to Cloudflare's network.

Once connected, your Zero Trust WARP client should turn blue:

3. Create a device posture rule

Next, we’re going to use WARP to harden our device posture. You can configure Zero Trust policies that rely on additional signals from the WARP client or from third-party endpoint security providers. When device posture checks are configured, users can only connect to a protected application or network resource if they have a compliant and healthy device.

WARP tests on client machines fall into two categories:

  • Signals provided via integrations with popular endpoint security providers like CrowdStrike and Tanium
  • Direct/native enforcement of device attributes on the client machine

Let’s create a device posture rule that checks if Notepad is running:

  1. In your Windows 11 VM, open the Notepad application
  2. Type powershell in the Windows search bar
  3. Select Run as administrator

Paste this command in PowerShell:

Get-Process -Name Notepad | ForEach-Object {$_.Path -replace "\\","/"}

The output will look something like this: C:/Program Files/WindowsApps/Microsoft.WindowsNotepad_xxxx_x64__xxxxxx/Notepad/Notepad.exe

ℹ️
If you are getting an error with the above command and no path is returned, restart Windows and try again.

Copy this full path.

Next, return to the Zero Trust dashboard. Go to Settings ‣ WARP Client

  1. Scroll down to Device posture and under WARP client checks select Add new:
device_posture.jpg
  1. Select Application Check
  2. You will be prompted for the following information:

Name: Notepad check
Operating system: Windows
Application path: <paste in the path you got from PowerShell>

  1. Save your changes.

4. Observe how WARP enforces device posture

Cloudflare polls the WARP client every 5 minutes to ensure the device posture requirements are met. If the client isn’t adhering to the device posture rules, authorization can be revoked.

You can see how Cloudflare evaluates current status of a specific device in the dashboard under My Team ‣ Devices.

When Notepad is running, you should see the posture check as PASSED:

When you stop the Notepad, the posture check will change to FAILED in a few minutes (if it doesn't, double check in Task Manager that the notepad process isn't still running on the background):

You can also see the history of posture activity of your whole team at Logs ‣ Posture.

Gather WARP logs

Before continuing in the Zero Trust dashboard, review some troubleshooting features of the WARP client.

A vital aspect of troubleshooting WARP client issues is knowing how to guide a user to retrieve network logs - referred to as warp-diag output.

If you need to escalate WARP client issues to Cloudflare Support, warp-diag output will be required!
  1. Navigate to Program Files ‣ Cloudflare ‣ Cloudflare WARP
  2. Double click on the warp-diag file
  3. A terminal window will appear for a 5-60 seconds, then the warp-diag output will appear on the desktop in zip format
The steps to create WARP client logs for other operating systems are available here: How do I retrieve WARP Client Logs

5. Quick WARP support challenge

The WARP client will try to run some connection tests.

  • The first is outside the WARP Tunnel to engage.cloudflareclient.com
  • The second will be internal, through the WARP Tunnel to connectivity.cloudflareclient.com

Can you open the warp-diag zip folder and identify the two connection tests?

Try to do this yourself, before proceeding below to the solution.


Solution

When you open the warp-diag folder you will see it contains several log and configuration files.

Some log files contain multiple iterations with a new number at the end:

When warp-diag runs it breaks down longer time based logs into current day and previous days:

  • daemon.log ← The most current log. Todays events from the perspective of when warp-diag was run
  • daemon1.log ← Today -1 (aka yesterdays) events from the perspective of when warp-diag was run

The most useful is the daemon.log, it reads from the bottom upwards, the bottom most line is the most recent log entry.

Look for the most recent Initiate WARP Connection from when you started having issues:

The WARP client will try to run some connection tests:

  • The first is outside the WARP Tunnel to engage.cloudflareclient.com, it will show as warp/gateway=off
  • The second will be internal, through the WARP Tunnel to connectivity.cloudflareclient.com, it will show as warp/gateway=on

If the outside connection test fails, this is usually a problem with your internet connectivity.

If the internal connection test fails, check if there are any Network or HTTP policies that could be blocking the test before escalating to Cloudflare Support.