Currently I use “full” setup of tunnels, where DNS records point to <uuid>.cfargotunnel.com
However I’d like to not rely on public DNS for some of tunnels if that is possible.
I tried to create a firewall rule in zero trust (i.e. rule for WARP users) that applies DNS filtering and replaces asked.internal.domain with <uuid>.cfargotunnel.com. However I get
“Access restricted. This site is blocked. Please contact your administrator for further assistance”.
I don’t quite see the difference between DNS record and user-side DNS filtering, but anyway - CF does not seem to bless these requests.
Is there any blessed way to use tunnels + custom DNS names but without actually registering them in DNS system?
I’ve tried two different firewall rules:
- overwrite of DNS name
asked.internal.domain → <uuid>.cfargotunnel.com
- overwrite of DNS name to ip
asked.internal.domain → ip of tunnel
And in both cases I get “Access restricted. This site is blocked”
Sounds like you want to route to a private network.
@cscharff I use private network to route ip traffic.
However that’s a poor solution to route dns requests: I like the convenience of tunnels. For example, I can run a tunnel within a container and serve my.internal.service with some well-encapsulated service inside the container. I don’t need to manage available ports in the docker, figure out ip of instance, check security groups, etc.
It is just I want to avoid using public DNS and rely on warp routing.
You’re not routing DNS requests.
Warp routing for internal traffic not proxied by Cloudflare is covered in the link I shared.
Warp routing for internal traffic not proxied by Cloudflare is covered in the link I shared.
I’ve checked this page once again, and it covers only proxying based on IP (which I already use for different scenario). It does not send traffic through CF tunnel.
You’re not routing DNS requests.
Sorry, wrong phrasing. DNS-based requests.
See my previous comment:
I like the convenience of tunnels. For example, I can run a tunnel within a container and serve my.internal.service with some well-encapsulated service inside the container. I don’t need to manage available ports in the docker, figure out ip of instance, check security groups, etc.
So service is not even exposed outside of docker. Access is only possible via a tunnel.
All I need is to connect to my.internal.service via a tunnel BUT without public DNS lookup.
This sounds like a basic feature for corporate networks.
Ok, that’s possible using the link I provided.
You can’t point random.example.com to the IP hostname of a tunnel and route traffic through it unless that domain name is active on Cloudflare, so install a tunnel in the same place using the method I linked to.
Every docker instance has an IP address in the well encapsulated container matrix right? and it’s in some kind of CIDR range. Add the CIDR range(s) of the docker instance as described in Step 1 in the link I shared.
Sounds like you already have the Warp client installed so you get to skip step 2.
Step 3: Modify the split tunnel config so that the IP address CIDR for the docker network is now no longer excluded
Step 4. Make sure that asked.internal.domain can be resolved via DNS in your docker environment by the machine you plan to install the tunnel on.
Step 5. Configure local domain fallback for DNS resolution as described here: Private hostnames and IPs · Cloudflare Zero Trust docs
Or if you can’t do 4, use DNS overrides as you had been with the specific IP address of the docker instance you are communicating with.
You can’t point random.example.com to the IP hostname of a tunnel and route traffic through it unless that domain name is active on Cloudflare
I think this answers my question.
I understand that I can run IP-based routing. That’s an over-engineering for my case: keep DNS, update records there for every instance/container, update domain fallbacks and split tunnel.
Additionally unsure how this will interact with access policies.