Blocking WARP cloudflare app

I have a WiFi ssid provided for staff cellphones with social apps blocking, some users use warp vpn to have access to those apps.
Steps to prevent:
App-id, security rule and url filtering in PAN-820
But unfortunately still working.

Any idea please!

Just finished a project for this, so here’s the required information.

The latest version of the WARP mobile app connects using either the WireGuard or MASQUE tunnel protocols. PAN-OS identifies the tunneled traffic as the following App-IDs:
a) WireGuard as “cloudflare-warp”
b) MASQUE as “unknown-udp”

So you can create the following three Security Policies to block the WARP app from connecting:

Rule 1

Name: Block warp consumer traffic
Source zone: (your zone)
Source address: Any
Destination zone: (your internet zone)
Destination address: 162.159.192.0/24
Application: “cloudflare-warp” and “ike” and “ipsec-esp-udp” and “unknown-udp”
*** Add the two dependency App-IDs
Service: Any
Action: Reset both client and server

Rule 2

Name: Block warp wireguard protocol
Source zone: (your zone)
Source address: Any
Destination zone: (your internet zone)
Destination address: 162.159.193.0/24 and 2606:4700:100::/48
*** The IPv6 block only required if your network is using IPv6
Application: “cloudflare-warp” and “ike” and “ipsec-esp-udp” and “unknown-udp”
*** Add the two dependency App-IDs
Service: Any
Action: Reset both client and server

Rule 3

Name: Block warp masque protocol
Source zone: (your zone)
Source address: Any
Destination zone: (your internet zone)
Destination address: 162.159.197.0/24 and 2606:4700:102::/48
*** IPv6 block only required if your network is using IPv6
Application: “unknown-udp”
Service: Any
Action: Reset both client and server

Notes:

  1. With the above rules, the WARP mobile app attempts to connect (says “checking connectivity” for a few seconds) and then reverts to “disconnected” mode.

  2. By using the Reset actions (vs. Deny or Drop), the WARP app is notified it cannot connect from this network and stops trying. This results in less overhead for your network infrastructure, and also the end user immediately realizes the WARP app doesn’t work on this network.

  3. This was tested this on PAN-OS 10.2.9 with WARP app on Apple iOS devices. I assume Android devices should see same results, but may have different traffic patterns.

  4. PAN-OS SSL Decryption was disabled, but it should work with that either enabled or disabled.

  5. As CloudFlare continues to develop the WARP app, those IP addresses and traffic patterns may change over time. You’ll need to monitor the documentation, and update the rules as time progresses.

  6. Planning on submitting a request to PAN to see if the “cloudflare-warp” App-ID can be updated to include MASQUE. But since that tunneling protocol uses encrypted QUIC protocol, use of SSL decryption will prolly be needed to identify this one (which will prolly break the app). So just using “unknown-udp” may just be the best permanent solution.

What is the warp vpn being identified as? Do you have ssl decryption enabled? What are the IPs of the warp vpn concentrators?

Review the logs allowing the traffic. Block what’s allowed that’s needs blocked to prevent it.

You might be able to block some combination of these specific destination IPs and UDP ports to break the WARP app from making its connections to Cloudflare:

https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/deployment/firewall/#client-orchestration-api

https://community.cloudflare.com/t/warp-network-requirements/213717

I appreciate your recommendations, I will implement these rules and will revert back to you.

Those rules are implemented, but the WARP app is connected immediately after this config again.

<3 the breakout of documentation

Existing WARP sessions (that were established prior to adding the rules) will need to be forcibly killed from Monitor>Session Browser.

Or, the WARP client app will need to disconnect/reconnect, after which it should establish new sessions that match the deny rules.

Use the Session Browser to filter by a client’s source IP, and make sure that you can see the client’s WARP sessions in the DISCARD state, and verify that it’s hitting those rules created.

You’ll need to do some basic troubleshooting. Are these Apple iOS devices? Android may behave differently, I’ve never tested it.

I tested on both iOS and Android devices, they get connect with the WARP cloudflare VPN and by passes proxy and security rules on firewall, even tho on monitor tab shows deny reset both for these apps.

Even though the WARP app on the devices show “connected”, are you positive the device actually has Internet connectivity?

If the WARP app cannot connect using wireguard or masque (blocked by rule 2 and 3), I observed that it will failback to using ipsec (which is what rule 1 is supposed to block).

It sounds like the rules are working, but the WARP app is still connecting using a different method (or differing destination IPs or protocol or something).

To help any further, I’m going to need to see a screenshot of your firewall rules you created, and the Session monitor tab (with a source IP filter applied) showing the client’s connections while it’s WARP app is “connected”. You can PM me these screenshots if you like, and also sanitize them as required.