Common issues
This section covers the most common issues you might encounter as you deploy the WARP client in your organization, or turn on new features that interact with the client. If you do not see your issue listed below, refer to the troubleshooting FAQ or contact Cloudflare Support.
If WARP is stuck in the Disconnected
state or frequently changes between Connected
and Disconnected
, this indicates that the client cannot establish a connection to Cloudflare’s global network.
In your WARP debug logs, daemon.log
will typically show one or more of the following errors:
-
Happy Eyeball checks failing:
ERROR main_loop: warp::warp::happy_eyeballs: Happy eyeballs error Custom { kind: NotConnected, error: "All Happy Eyeballs checks failed" } -
Many other checks timing out:
ERROR warp::warp::connectivity_check: DNS check failed error=ResolveError { kind: Timeout }WARN warp::warp::connectivity_check: Tunnel trace failed request::Error { kind: Request, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("connectivity.cloudflareclient.com")), port: None, path: "/cdn-cgi/trace", query: None, fragment: None }, source: TimedOut }
Here are the most common reasons why this issue occurs:
A third-party service (such as a hardware or software firewall, router, MDM/group policy configuration, or other networking interface) may have a security policy in place which blocks WARP from connecting.
Configure the third-party service to exempt the IP addresses required by WARP.
The most common places we see interference with WARP from VPNs are:
-
Control of traffic routing: In
daemon.log
, you will see a large number of routing table changes. For example,DEBUG warp::warp_service: Routes changed:Added; Interface: 8; Destination: 10.133.27.201/32; Next hop: 100.64.0.2;Added; Interface: 8; Destination: 10.133.27.202/32; Next hop: 100.64.0.2;DEBUG warp::warp_service: Routes changed:Added; Interface: 8; Destination: 10.133.27.203/32; Next hop: 100.64.0.2;Added; Interface: 8; Destination: 10.133.27.204/32; Next hop: 100.64.0.2;DEBUG warp::warp_service: Routes changed:Added; Interface: 8; Destination: 10.133.27.205/32; Next hop: 100.64.0.2;This indicates that a third-party VPN is fighting WARP for control over the routing table.
-
Control of DNS: In
daemon.log
, you will see a large number of DNS changes followed by this warning:WARN main_loop: warp::warp_service: Reinforcing DNS settings. Is something else fighting us?The daemon may also note that some other process has already bound to the UDP and TCP sockets:
WARN warp::warp: Unable to bind local UDP socket error=Os { code: 48, kind: AddrInUse, message: "Address already in use" } sockaddr=127.0.2.2:53WARN warp::warp: Unable to bind local TCP socket error=Os { code: 48, kind: AddrInUse, message: "Address already in use" } sockaddr=127.0.2.2:53
To confirm that the VPN is the source of the issue, temporarily uninstall (not disable or disconnect) the VPN.
- Disable all DNS enforcement on the VPN. WARP must be the last client to touch the primary and secondary DNS server on the default interface.
- In Zero Trust ↗, create a Split Tunnel rule to exclude the VPN server you are connecting to (for example,
vpnserver.3rdpartyvpn.example.com
). - Configure your VPN to only include routes to your internal resources. Make sure that the VPN routes do not overlap with the routes included in the WARP tunnel.
For more information, refer to our guide for running VPNs alongside the WARP client.
Some countries explicitly block the use of VPN or VPN-like software that intentionally encrypts traffic. These blocks are often inconsistently enforced and you may sometimes see successful connections.
If you suspect your country may be blocking WARP traffic, contact your ISP to verify.
WARP cannot parse resolv.conf
files which contain an invalid hostname. In daemon.log
, you will see an unrecognized char
warning:
WARN main_loop: warp::warp_service: Tunnel connection experienced error error=Custom { kind: Other, error: ProtoError { kind: Msg("unrecognized char: ") } }
- Open the
/etc/resolv.conf
file on your device. - In the
search
directives, check for invalid URL characters such as!@#$%^&*()<>?
. - Remove the invalid lines and rely on WARP and Gateway for DNS services.
If WARP shows as Connected
but you cannot reach any websites or internal resources, this is likely due to one of the following configuration issues.
A misconfigured Gateway firewall policy can result in traffic to some or all sites being restricted.
- In Zero Trust ↗, go to Gateway > Firewall Policies.
- Disable all DNS, Network, and HTTP policies and see if the issue persists. It may take up to two minutes for the change to take effect. Note that all policy enforcement happens on the Cloudflare global network, not on your local device.
- Slowly re-enable your policies. Once you have narrowed down the issue, modify the policies or their order of enforcement.
Installing and trusting a root CA is a necessary step to enable advanced security features such as Browser Isolation, TLS decryption, AV scanning, and device posture.
If the root CA is not installed on the device, you will see untrusted certificate warnings on every website. Example warnings include Certificate not trusted
, Not trusted identity
or SSL Error
.
Install the Cloudflare certificate on all of your devices, or upload your own certificate to Cloudflare.
WARP does not allow third-party DLP or proxy services to perform TLS decryption on traffic sent to Gateway.
To diagnose the issue, go to https://zero-trust-client.cloudflareclient.com/v0/client_config
and verify the certificate the HTTPS traffic is signed with. If the certificate is issued by your organization or a third-party service, the third-party service is performing TLS decryption on WARP traffic and re-signing with a certificate that we do not trust.
In the third-party security product, disable HTTPS inspection and TLS decryption for the WARP IP addresses.
Below are the most common reasons why turning on WARP blocks a specific application from loading.
Some applications do not support SSL inspection or are otherwise incompatible with TLS decryption. Gateway provides a list of applications known to perform certificate pinning.
Applications such as Firefox, Docker, Python, and npm rely on their own certificate store and the Cloudflare root certificate must be trusted in each.
Refer to our instructions for adding the root certificate to common applications. For applications not on our list, try searching the Internet for <app-name> proxy support
or <app-name> proxy certificate
.
If you cannot install the certificate on the application, create a Do Not Inspect policy to exclude the application from Gateway inspection.
You may have a Gateway DNS, Network, or HTTP in place that accidentally blocks a port, IP, or domain that the app or site relies on.
- In Zero Trust ↗, go to Gateway > Firewall Policies.
- Disable all DNS, Network, and HTTP policies and see if the issue persists. It may take up to two minutes for the change to take effect. Note that all policy enforcement happens on the Cloudflare global network, not on your local device.
- Slowly re-enable your policies. Once you have narrowed down the issue, modify the policies or their order of enforcement.
Some applications require traffic to flow either all inside or all outside of the WARP tunnel. For instance, in order to use AirDrop or communicate with a local printer, traffic must be outside the tunnel. For applications like Microsoft Teams to function properly, all Microsoft Teams traffic must be either fully inside the tunnel or fully outside the tunnel.
- Determine the IP addresses and/or domains required for your application to function. Common Internet search terms include
<app-name> split tunnel list
,<app-name> allow list
, or<app-name> firewall ips
. - In Zero Trust ↗, go to your Split Tunnel settings.
- Depending on the application, either include or exclude all of the necessary IPs and/or domains. For Microsoft applications, we provide a one-click action to exclude all Microsoft 365 IPs.