Private hostnames and IPs
Building out a private network has two primary components: the infrastructure side and the client side.
The infrastructure side is powered by Cloudflare Tunnel, which connects your infrastructure to Cloudflare — whether that be a singular application, many applications, or an entire network segment. This is made possible by running
cloudflared in your environment to establish multiple secure, outbound-only, load-balanced links to Cloudflare.
On the client side, your end users need to be able to easily connect to Cloudflare and, more importantly, your network. This connection is handled by Cloudflare WARP. This client can be rolled out to your entire organization in just a few minutes using your in-house MDM tooling and it establishes a secure connection from your users’ devices to the Cloudflare network.
Follow the steps below to define your internal DNS resolver with Cloudflare Zero Trust and to resolve requests to your private network using Cloudflare Tunnel.
- Cloudflare Tunnel must be properly to route traffic to a private IP space.
cloudflaredmust be connected to Cloudflare from your target private network.
- Cloudflare WARP must be installed on end-user devices to connect your users to Cloudflare.
Enable UDP support
Scroll down to Firewall settings.
Ensure the Proxy is enabled and both TCP and UDP are selected.
Create a Local Domain Fallback entry
Remain in Network Settings and scroll further down to Local Domain Fallback.
Create a new Local Domain Fallback entry pointing to the internal DNS resolver. The rule in the following example instructs the WARP client to resolve all requests for
myorg.privatecorpthrough an internal resolver at
10.0.0.25rather than attempting to resolve this publicly.
Next, update your Cloudflare Tunnel configuration to ensure it is using QUIC as the default transport protocol. To do this, you can either set the
protocol: quic property in your or directly through your CLI.
Finally, update to the latest available version (2021.12.3 as of the time of writing) of cloudflared running on your target private network.
You can now resolve requests through the internal DNS server you set up in your private network.
Test the setup
For testing, run a
dig command for the internal DNS service:
$ dig AAAA www.myorg.privatecorp
dig will work because
myorg.privatecorp was configured above as a fallback domain. If you skip that step, you can still force
dig to use your private DNS resolver:
$ dig @10.0.0.25 AAAA www.myorg.privatecorp
dig commands will fail if the WARP client is disabled in your end user’s device.
Use the following troubleshooting strategies if you are running into issues while configuring your private network with Cloudflare Tunnel.
cloudflaredis connected to Cloudflare by visiting Access > Tunnels in the Zero Trust dashboard.
cloudflaredis running with
quicprotocol (search for
Initial protocol quicin its logs).
Ensure that the machine where
cloudflaredis running is allowed to egress via UDP to port 7844 to talk out to Cloudflare.
Double-check the precedence of your application policies in the Gateway Network policies tab. Ensure that a more global Block or Allow policy will not supersede the application policies.
Check the Gateway Audit Logs Network tab to see whether your UDP DNS resolutions are being allowed or blocked.
Ensure that your Private DNS resolver is available over a routable private IP address. You can check that by trying the
digcommands on your machine running
Check your set up by using
dig ... +tcpto force the DNS resolution to use TCP instead of UDP.