--- title: Troubleshoot private networks description: Debug private network connectivity issues. image: https://developers.cloudflare.com/cf-twitter-card.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/learning-paths/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Troubleshoot private networks Follow this troubleshooting procedure when end users running the Cloudflare One Client have issues connecting to a private network behind Cloudflare Tunnel. ## 1\. Is the Cloudflare One Client connected to a Cloudflare data center? The Cloudflare One Client GUI should display `Connected` and `Your Internet is protected`. ![Cloudflare One Client GUI when connected to Cloudflare](https://developers.cloudflare.com/_astro/warp-connected.NWD7Y4NW_1F03OI.webp) If the Cloudflare One Client is stuck in the `Disconnected` state or frequently changes between `Connected` and `Disconnected`, refer to [Unable to connect WARP](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/troubleshooting/common-issues/#unable-to-connect-warp). ## 2\. Is the Cloudflare One Client connecting to your private DNS server? This step is only needed if users access your application via a private hostname (for example, `wiki.internal.local`). * If you are using [custom resolver policies](https://developers.cloudflare.com/cloudflare-one/traffic-policies/resolver-policies/) to handle private DNS, go to your Gateway DNS logs (**Insights** \> **Logs** \> **DNS query logs**) and search for DNS queries to the hostname. * If you are using [Local Domain Fallback](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/local-domains/) to handle private DNS, go to your Gateway Network logs (**Insights** \> **Logs** \> **Network logs**) and search for port `53` traffic to your DNS server IP. If there are no relevant Gateway logs, it means that WARP was unable to forward the query to your private DNS server. Check your resolver policies or Local Domain Fallback configuration and refer to [How WARP handles DNS requests](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/#how-the-warp-client-handles-dns-requests). ## 3\. Is network traffic to the application going through the Cloudflare One Client? Next, check if your Gateway Network logs (**Insights** \> **Logs** \> **Network logs**) show any traffic to the destination IP. If the Cloudflare One Client is connected but there are no network logs, it means that your private network IPs are not routing through the Cloudflare One Client. You can confirm this by [searching the routing table](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/client-architecture/#routing-table) on the device for the IP address of your application. Traffic to your application should route through the Cloudflare One Client interface. If another interface is used, [check your Split Tunnel configuration](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/#3-route-private-network-ips-through-the-cloudflare-one-client). ## 4\. Is the user blocked by a Gateway policy? To check if a Gateway block event occurred: 1. Go to **Insights** \> **Logs** and select the **DNS query logs**, **Network logs**, or **HTTP request logs**. 2. Apply the following filters: * **Email**: User's email address * **Event**: _Blocked_ * **Date Time Range**: Time period when the user accessed the application ## 5\. Is the user matching the correct Gateway policy? Determine whether the user is matching any policy, or if they are matching a policy that has a higher priority than the expected policy. 1. To determine the actual policy that was applied: 1. Go to **Insights** \> **Logs** and select the **DNS query logs**, **Network logs**, or **HTTP request logs**. 2. Apply the following filters: * **Email**: User's email address * **Date Time Range**: Time period when the user accessed the application 3. In the search box, filter by the destination IP or FQDN. 4. In the results, select a log and note its **Policy Name** value. 2. Go to **Traffic policies** \> **Firewall policies** and compare the [order of enforcement](https://developers.cloudflare.com/cloudflare-one/traffic-policies/order-of-enforcement/) of the matched policy versus the expected policy. 3. Compare the Gateway log values with the expected policy criteria. * If the mismatched value is related to identity, [check the user registry](https://developers.cloudflare.com/cloudflare-one/team-and-resources/users/users/) and verify the values that are passed to Gateway from your IdP. Cloudflare updates the registry when the user enrolls in the Cloudflare One Client. If the user's identity is outdated, ask the user to re-authenticate the client (**Profile** \> **Account information** \> **Re-authenticate**)[1](#user-content-fn-1). * If the mismatched value is related to device posture, [view posture check results](https://developers.cloudflare.com/cloudflare-one/reusable-components/posture-checks/#2-verify-device-posture-checks) for the user's device. Verify that the device passes the posture checks configured in the policy. ## 6\. Are the correct Gateway proxy settings enabled? Under **Traffic policies** \> **Traffic settings**, ensure that **Allow Secure Web Gateway to proxy traffic** is enabled for TCP, UDP, and ICMP traffic. UDP is required for proxying DNS traffic and other UDP packets, while ICMP is required for `ping` and other administrative functions. ## 7\. Is the user's traffic reaching the tunnel? [Review your tunnel log stream](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/#view-logs-on-your-local-machine). If you do not see any requests to your application, ensure that you have added the appropriate static routes to your Cloudflare Tunnel. ## 8\. Is the tunnel forwarding requests to your application? Verify that you can connect to the application directly from the `cloudflared` host machine: * [ macOS and Linux ](#tab-panel-6821) * [ Windows ](#tab-panel-6822) Open Terminal and run the following command: Terminal window ``` telnet test.example.com 443 ``` If `telnet` fails to open the connection, check your infrastructure for firewalls, load balancers, or other network devices that may be interfering with the connection between `cloudflared` and the application server. Open PowerShell and run the following command: PowerShell ``` PS C:\Users\JohnDoe> Test-NetConnection test.example.com -port 443 ``` If the output shows `TcpTestSucceeded : False`, check your infrastructure for firewalls, load balancers, or other network devices that may be interfering with the connection between `cloudflared` and the application server. You can also use a packet capture tool such as `tcpdump` or Wireshark to trace whether traffic from the user device successfully reaches `cloudflared` and routes to your application. Traffic to your application will carry the source IP of the `cloudflared` host. ## 9\. How is your application handling requests? 1. Check if the application server has a local firewall in place that is blocking requests from the `cloudflared` host machine. 2. Check if the application server needs to initiate any connection towards the user's device. If so, this is a limitation of `cloudflared` and you should instead [deploy Cloudflare Mesh](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-mesh/) to enable bidirectional traffic. ## 10\. Is TLS inspection affecting the connection to your application? If there is a problem with [TLS inspection](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/tls-decryption/), the user will get an `Insecure Upstream` error when they access the application in a browser. They will probably not get an error if they access the application outside of a browser. Customers who have [Logpush](https://developers.cloudflare.com/cloudflare-one/insights/logs/logpush/) enabled can check the [Gateway HTTP dataset](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/account/gateway%5Fhttp/) for any hostnames which have an elevated rate of `526` HTTP status codes. To troubleshoot TLS inspection: 1. Create a temporary Gateway HTTP policy that disables TLS inspection for all traffic to the application. For example: | Selector | Operator | Value | Action | | -------------- | -------- | ----------- | -------------- | | Destination IP | in | 10.2.3.4/32 | Do Not Inspect | 2. If the `Do Not Inspect` policy enables the user to connect, verify that the TLS certificate used by your application is trusted by a public CA and not self-signed. Cloudflare Gateway is unable to negotiate TLS with applications that use self-signed certificates. For more information, refer to [TLS inspection limitations](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/tls-decryption/#inspection-limitations). To work around the issue: * **Option 1:** Create a permanent [Do Not Inspect HTTP policy](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/#do-not-inspect) for this application. * **Option 2:** Customers who use their [own certificate infrastructure](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/user-side-certificates/custom-certificate/) for inspection can opt to create an [Allow _Pass Through_ policy](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/#untrusted-certificates) which enables our proxy to accept the TLS negotiation from your application. This will allow requests to flow correctly without the need for a `Do Not Inspect` policy. * **Option 3:** If your application uses `HTTPS` or other common protocols, you can add a [published application](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/) to your Cloudflare Tunnel and set [noTLSVerify](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/origin-parameters/#notlsverify) to `true`. This will allow `cloudflared` to trust your self-signed certificate. ## Footnotes 1. In Cloudflare One Client version 2026.1 and earlier, select **Preferences** \> **Account** \> **Re-Authenticate Session**. [↩](#user-content-fnref-1) ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/learning-paths/","name":"Learning Paths"}},{"@type":"ListItem","position":3,"item":{"@id":"/learning-paths/replace-vpn/troubleshooting/","name":"Troubleshooting"}},{"@type":"ListItem","position":4,"item":{"@id":"/learning-paths/replace-vpn/troubleshooting/troubleshoot-private-networks/","name":"Troubleshoot private networks"}}]} ```