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.
Prerequisites
- Cloudflare Tunnel must be properly configured to route traffic to a private IP space.
cloudflared
must 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
-
On the Zero Trust dashboard, navigate to Settings > Network.
-
Scroll down to Firewall settings.
-
Ensure the Proxy is enabled and both TCP and UDP are selected.
Create a Local Domain Fallback entry
Next, we need to create a Local Domain Fallback entry.
-
Remain in Network Settings and scroll further down to Local Domain Fallback.
-
Click Manage.
-
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.privatecorp
through an internal resolver at10.0.0.25
rather than attempting to resolve this publicly.
Update cloudflared
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
configuration file
or
pass the –-protocol quic
flag
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
The 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
Both dig
commands will fail if the WARP client is disabled in your end user’s device.
Troubleshooting
Use the following troubleshooting strategies if you are running into issues while configuring your private network with Cloudflare Tunnel.
-
Ensure that
cloudflared
is connected to Cloudflare by visiting Access > Tunnels in the Zero Trust dashboard. -
Ensure that
cloudflared
is running withquic
protocol (search forInitial protocol quic
in its logs). -
Ensure that the machine where
cloudflared
is running is allowed to egress via UDP to port 7844 to talk out to Cloudflare. -
Ensure that end-user devices are enrolled into WARP by visiting https://help.teams.cloudflare.com
-
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
dig
commands on your machine runningcloudflared
. -
Check your set up by using
dig ... +tcp
to force the DNS resolution to use TCP instead of UDP.