WARP Posture Check

[justins210]

Hello, I’m trying to setup device posture checks for my Zero Trust team so that a user must be connected via warp in order to access an application (example.mydomain.com) with no luck.

In my attempts to track down the issue I’ve identified that the problem seems to be related my Zero Trust configuration. What I’ve found is that when I visit https://cloudflare.com/cdn-cgi/trace or https://example.mydomain.com/cdn-cgi/trace from a warp client that is not connected to my Zero Trust team, the webpage prints ‘warp=on’ as expected. This indicates to me that the device posture would have been successful. However, once the warp client is enrolled in my team, both pages print warp=off even though it clearly is enabled.

Is there some key configuration setting that I’ve missed?

Though https://community.cloudflare.com/t/gateway-device-posture-check-not-work/427973/24 is a similar issue, it does not seem to resolve my problems.

[geoff12]

I’ve got a similar issue. I can secure a self-hosted app by WARP but i can’t do the same for Gateway.

On MacOs with the WARP client logged into my Zero Trust account i see the following…

With Zero Trust WARP turned on:

fl=26f147
h=blah.mydomain.com
ip=SOMEIPADDRESS
ts=1672817616.324
visit_scheme=https
uag=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36
colo=SYD
sliver=none
http=http/2
loc=AU
tls=TLSv1.3
sni=plaintext
warp=plus
gateway=off
kex=X25519

And this when I turn it off:

fl=493f161
h=blah.mydomain.com
ip=SOMEIPADDRESS
ts=1672818405.308
visit_scheme=https
uag=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36
colo=SYD
sliver=none
http=http/2
loc=AU
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off
kex=X25519

[albert]

@geoff12, please take a look at this tutorial I just created

Using WARP posture checks with Cloudflare Access

This tutorial explains how to enable WARP client posture checks and use them in an Access application policy. Enabling the “Warp” and “Gateway” selectors The “Warp” and “Gateway” selectors are not visible in the policy creator by default and must be manually enabled. Fortunately, this is quite simple and can be done in only a few steps. In the Zero Trust dashboard navigate to Settings → WARP Client → Device posture. [Screenshot 2023-01-04 at 09.18.24] In the “WARP client checks” section, c…

[geoff12]

@albert thanks for that… been banging my head against a wall for a few days trying to understand how this works.

This was the critical issue i was missing.

• The “Proxy” option is enabled in Settings → Network → Firewall

A great addition to the tutorial would be a succinct explanation as to what impact this Firewall setting may have on the overall security posture? ie. why is it not turned on by default.

[jnperamo]

@geoff12

A great addition to the tutorial would be a succinct explanation as to what impact this Firewall setting may have on the overall security posture?

Taking a wild guess, since the L7 proxy enables DPI, any app that has their certification pinned would stop working.
Applications such as Discord, Slack, AVs (partially) might stop working as they detect something is intercepting the connection, you will need to allowlist those applications from the dashboard.

[justins210]

That’s a helpful tutorial. I definitely want to use the ‘gateway’ posture check and not warp alone. It seems like my configuration currently aligns with the steps in the post but neither gateway or warp checks are working.

Going back to my original post I think it’s very odd that the warp posture check does work when the warp client is not logged into my account. Everything breaks when I register the warp client with my organization. Any ideas?

[albert]

@justins210

Everything breaks when I register the warp client with my organization.

That’s odd. Did you check out the debugging section of the tutorial?

@albert

Debugging

You can check if you are currently connected to WARP and/or Gateway by visiting https://cloudflare.com/cdn-cgi/trace and noting the value of the warp and gateway properties, which correspond to the Warp and Gateway client posture checks.

[justins210]

Yes, my first post explained that I used the https://cloudflare.com/cdn-cgi/trace page to debug. Here is most of the output when my warp client is turned on and logged in:

fl=354f35
h=cloudflare.com
ip=*removed*
ts=1673307419.606
visit_scheme=https
uag=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36
colo=IAD
sliver=010-tier1
http=http/2
loc=US
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off
kex=X25519

Additionally heres the output of the https://help.teams.cloudflare.com/ page:

Again, warp is on and logged in to my org.

[albert]

@justins210

warp is on

@justins210

warp=off
gateway=off

Your computer is not sending the request through WARP. Have you made changes to the split-tunnel settings? Do you have any other VPN software installed?

[justins210]

My split-tunnel settings seemed to be the source of the issue. Resetting the split-tunnel back to ‘Exclude IPs and domains’ fixed my problems. I’m curious why the split tunnel settings had any effect on the posture check though.

[albert]

Your split-tunnel settings caused outgoing connections to be made directly rather than through Cloudflare WARP. Since the connection was not routed through Cloudflare WARP, the client did not pass the posture check.