Known limitations

Below, you will find information on devices, software, and configurations that are incompatible with Cloudflare WARP.

Windows Server

The WARP client does not run on Windows Server. Refer to the downloads page for a list of supported operating systems.

Managed network on legacy Windows Server

Managed network detection will not work when the TLS certificate is served from IIS 8.5 on Windows Server 2012 R2. To work around the limitation, move the certificate to a different host.

Multi-user support on Windows

The WARP client does not support multiple users on a single Windows device. WARP uses hard-coded global paths to store settings and keys and does not save information on a per-user basis. Therefore, after one user logs into WARP, their settings will apply to all traffic from the device.

nslookup on Windows in DoH mode

On Windows devices in Gateway with DoH mode, nslookup by default sends DNS requests to the WARP local DNS proxy over IPv6. However, because WARP uses an IPv4-mapped IPv6 address (instead of a real IPv6 address), nslookup will not recognize this address type and the query will fail:

C:\Users\JohnDoe>nslookup google.com
Server:  UnKnown
Address:  ::ffff:127.0.2.2

*** UnKnown can't find google.com: No response from server

To work around the issue, specify the IPv4 address of the WARP local DNS proxy in your query:

C:\Users\JohnDoe>nslookup google.com 127.0.2.2

Alternatively, use PowerShell:

PowerShell

Resolve-DnsName -Name google.com

4G/5G embedded modules

Because of how the WARP client instantiates the local DNS Proxy, it is incompatible with 4G/5G cellular adaptors which have IPv6 enabled. To run WARP on these devices, you will need to disable IPv6 on the system.

Note

This limitation does not apply to mobile phones, only desktop machines with cellular connectivity.

Comcast DNS servers

Comcast DNS traffic (to the IPs below) cannot be proxied through WARP. This is because Comcast rejects DNS traffic that is not sent directly from the user’s device.

• IPv4 Addresses: 75.75.75.75 and 75.75.76.76
• IPv6 Addresses: 2001:558:feed::1 and 2001:558:feed::2

To work around the issue, you can either:

• Create a Split Tunnel rule that excludes the above IPs from WARP.
• Configure your device or router to use a public DNS server such as 1.1.1.1 ↗.

Cox DNS servers

Similar to the Comcast DNS servers limitation listed above, Cox DNS servers will not respond to traffic from the WARP egress IPs (or any IP that is not a Cox IP). The workaround is nearly identical, except that Cox DNS servers may be specific to the individual end user. You can either:

• Create a Split Tunnel rule that excludes all Cox DNS servers. For business customers, refer to the COX documentation ↗ for the DNS server IPs. For residential customers, check your local DNS servers. The residential DNS servers typically fall under 68.105.28.0/24 and 68.105.29.0/24.
• Configure your device or router to use a public DNS server such as 1.1.1.1 ↗.

HP Velocity

The HP Velocity driver has a bug which will cause a blue screen error on devices running WARP. HP recommends uninstalling this driver ↗.

Cisco Meraki

Cisco Meraki devices have a bug where WARP traffic can sometimes be identified as Statistical-P2P ↗ and de-prioritised or dropped entirely. To resolve the issue, disable Statistical-P2P on the Cisco Meraki device.

Windows Teredo

The Windows Teredo ↗ interface conflicts with the WARP client. Since Teredo and WARP will fight for control over IPv6 traffic routing, you must disable Terado on your Windows device. This allows the WARP client to provide IPv6 connectivity on the device.

Docker on Linux with bridged networking

Currently Docker ↗ on Linux does not perform the underlying network tunnel MTU changes required by WARP. This can cause connectivity issues inside of a Docker container when WARP is enabled on the host machine. For example, curl -v https://cloudflare.com > /dev/null will fail if run from a Docker container that is using the default bridge network driver.

Until Docker changes this behaviour, WARP + Docker users on Linux can manually reconfigure the MTU on Docker’s network interface. You can either modify /etc/docker/daemon.json to include:

{
  "mtu": 1420
}

or create a Docker network with a working MTU value:

docker network create -o "com.docker.network.driver.mtu=1420" my-docker-network

The MTU value should be set to the MTU of your host’s default interface minus 80 bytes for the WARP protocol overhead. Most MTUs are 1500, therefore 1420 should work for most people.