DNS problem with new easy tunnel

Client is running Linux Mint 20.3 and WARP 2022.2.288
Server is running Debian 11.3 and cloudflared version 2022.3.4 (built 2022-03-25-1731 UTC)

I rebuilt my tunnel following the recent Ridiculously easy to use Tunnels blog post. Everything works like it used to except DNS. I have to add entries to my client’s hosts file with IPs from my private network to connect to websites on my private network again. Local DNS was working with the previous tunnel, after I added my local domain and DNS server under Settings > Network > Local Domain Fallback.

Do I need to make any changes to the tunnel to get local DNS working again, or do the new tunnels not support DNS yet?

I think I know what happened:

  • private DNS resolution over a Tunnel requires the Tunnel to run with QUIC protocol
  • by default, Tunnel runs with HTTP2 by default (we’re rolling out QUIC as the default slowly)
  • you probably had protocol: quic in your YAML config
  • now you’re depending entirely on the UI to do the config for you
  • but that protocol flag is something low level we don’t expect to be needed/configurable most of the time, so it’s not configurable in the UI

TLDR: you need to make sure your Tunnel is running with cloudflared tunnel --protocol quic run --token ... in the service that was installed by cloudflared service install ... that you did following the UI instructions

3 Likes

Initially I assumed this was the problem. I checked the output from cloudflared tunnel help to see if there was an option to specify the protocol. I didn’t see any mention of a --protocol switch, or the quic protocol, so I assumed it wasn’t required.

I just updated the service file for cloudflared and restarting the service. I have verified that --protocol quic is included in the flags passed to the running cloudflared and that the tunnel is connected. There’s no change. Local DNS still doesn’t resolve like it did before.

Anything else I can do to troubleshoot this?

What’s the tunnel ID?

It looks like the tunnel ID is 9587166d-9b8f-4ac2-9d7e-21948846cd75.

I can see UDP working fine in your Tunnel on the 29th March 2022 until near 11PM UTC. It is targeting port 53 so it was likely DNS resolution.
Since then, I do not see any activity at all, no TCP nor UDP.
Also, I confirm that your Tunnel is connecting with QUIC protocol as you said.

I can also confirm that the Zero Trust WARP client shut down the session at that time and never came back online since then.

So, based on this, it’s as if you had stopped the Zero Trust WARP client and never enabled it back on.

I only use the warp client on my personal laptop while it’s on the guest network at work. When I got home around 10PM UTC on the 29th, I reconfigured and restarted the cloudflared tunnel, so it would use the QUIC protocol. I then connected my laptop to my neighbor’s Wi-Fi, so I could check the warp client’s connection back to my home network. The tunnel worked, but local DNS over the tunnel did not. I flushed DNS, disconnected and reconnected the warp client, restarted the laptop, and reconnected the warp client again, but local DNS still didn’t work. I disconnected the warp client and reconnected directly to my home network around 11PM UTC, because I was done testing for the day.

This morning I took my personal laptop to work, connected to the guest Wi-Fi, and connected the warp client. Local DNS is working fine now. I don’t know what changed, but I’ll continue to monitor the connection. Thanks.

I thought I should follow-up on this, even though I wasn’t able to troubleshoot these problems thoroughly. This morning I brought my laptop to work and connected to the guest Wi-Fi again. The warp tunnel reported that it was connected, but I couldn’t connect to any of my services running at home.

A service that’s publicly exposed through a tunnel gave the following error:

A service that’s only available to warp clients gave the following error:

In both cases local DNS resolution seemed to be working based on results returned from a host command. I disconnected and connected warp multiple times, and I restarted the warp service on my laptop, but I kept getting these errors. Another laptop without the warp client was able to load the publicly available site above without any errors.

Later in the day, after reading another post on the community forum, I tried deleting and adding the private IP range to the tunnel configuration. Both sites immediately came up after that. Unfortunately I didn’t test the connection before I deleted and added the private IP range, so I don’t know if that fixed it, or if something else earlier in the day already had.