No DNS when using Exit Node

SUPPORT QUESTIONS
1

Tailscale version: 1.6.0 on both nodes

Your operating system & version: client is Win 10 20H2 (19042.867). Exit node / server is Ubuntu 20.04.2 LTS.

Following Exit Nodes - Tailscale, I ran sudo tailscale up --advertise-exit-node on the Ubuntu server. I allowed the exit node from the admin console. No problem so far.

On the Windows client, I selected “Use exit node” and picked the server I just enabled. At this point I can ping external IPs on the internet, so some connectivity is working, but… I can’t browse anything. It seems DNS is not working.

I tried enabling Magic DNS (normally disabled). I also tried setting two DNS servers on the admin console – 1.1.1.1 and 8.8.8.8 (also normally left blank / disabled). This makes no difference.

I think at this point I’ve narrowed it down to, my DNS servers on the LAN go unreachable when routing via the exit node. That’s weird to me. How do I fix this? Also, why doesn’t adding external DNS servers help?

Ideally, I would like to continue using my LAN DNS servers while routing other traffic via the exit node, because I like the benefits of Pi-hole. If that’s not an option, I would be fine using external DNS servers while routed via the exit node. It’s not clear how to do either of these things. There is no mention of DNS at all in the exit node doc, so not much help there.

1 Like
2

I think Selecting an exit node causes local subnet to become unavailable · Issue #1527 · tailscale/tailscale · GitHub may partially explain my DNS problem. I’m not sure how to best resolve it though (pardon the pun). Any tips on how DNS is supposed to work when using an exit node would be appreciated.

1 Like
4

Try adding a DNS server in the admin console (even with magic DNS turned on). That’s the only way I could get DNS via tailscale to work. It’s pointing to my PiHole server.

5

Thanks for the suggestion @Travelingflwr. I was eventually able to get intermittant connectivity over an exit node after adding public DNS servers in the admin console, and the other step I had missed – opening up the ACLs.

But DNS still doesn’t work reliably. I can’t figure it out. I’m guessing there’s a race condition when configuring DNS on Windows or somesuch. I filed No DNS on Windows client when using exit node · Issue #1535 · tailscale/tailscale · GitHub last week but forgot to update here.

6

Did you add your pi.hole server to the DNS settings on the console? That’s what I did.

Now, since I’ve been using exit node I’ve found that it’s hit and miss on if it will work or not. I’m still working on reliably reproducing it so I can file a bug report on it.

7

If you mean the LAN IP of my Pi-hole server, I don’t think that will work in my case, because some of the devices on my Tailnet aren’t on the same LAN. Seems like that would break DNS for those remote devices.

Or did you mean use the Pi-hole’s Tailscale IP? I guess you could bind Pi-hole to the Tailscale interface add then add that IP as a DNS server on the console. It’s an interesting thought.

8

Yes. I added tailscale to my Pi-hole server and use the tunneled address as a DNS server. I did have to modify Pi-hole instance to listen on all interface in order to get it working.

Do you plan on using the Pi-hole server as an exit node as well? If so, make sure to enable it forwarding on it as well.

9

Getting the same issue here on MacOS and can’t seem to figure out what the issue is.

I’m using 1.1.1.1 as my DNS server (and therefore escaping the issue of the DNS server being unavailable to me on the LAN of the exit node).

However, as soon as I flick on to use the exit node, I can refresh pages already open in my browser, but new pages result in 404. Interestingly, these are my results with dig:

❯ dig google.com                                                                                                                         ✔  7203  20:18:06

; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

❯ dig google.com @1.1.1.1                                                                                                    9 ↵  7204  20:18:51

; <<>> DiG 9.10.6 <<>> google.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24800
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		108	IN	A	172.217.14.238

;; Query time: 253 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Apr 11 20:18:58 AEST 2021
;; MSG SIZE  rcvd: 55

The default DNS server times out (however that server is determined) however when specifying 1.1.1.1 I can see that the resulting latency means that it is passing through the exit node.

10

Hi, Can you please enable the “Use Tailscale DNS setting” option in the debug menu? Then test it again.

11

Just to clarify, it looks like we missed several DNS cases when testing out the first release of exit nodes. The following combination is the one that works most reliably:

  • set a public DNS server (9.9.9.9 for example) in the tailscale admin panel
  • add only that DNS server, not any others; PiHole servers probably will not work with exit nodes in this version.
  • enable MagicDNS in the tailscale admin panel
  • as Darshini mentioned, make sure your tailscale client is set to “Use Tailscale DNS setting”, if you’ve been playing with the DNS menu.

I use exit nodes with this combination of settings almost all the time (though mainly for testing) and it works reliably for me so far.

12

Is that setting exposed for iOS devices? Can’t find it anywhere.

13

Not exposed on iOS. It’s always enabled, on those devices. (This might change later, but anyway, it’s already set to the recommended setting.)

14

In that case, looks like possibly waiting for the next version for DNS to work with exit node on iOS? I did have this working at one point with PiHole at one point but now, no luck.

15

Revising. Looks like 100.100.100.100 is pingable on iOS but for some reason, anything beyond blink.sh is not able to do lookups with 100.100.100.100 and routing to public IP’s isn’t working when exit node is set.

16

Okay. So I switched to my PiHole instance (it’s running tailscale) and I can do DNS lookup’s against that but it really appears that there’s no route to anything public via exit node.

17

So DNS is working now, but you can’t reach the Internet? That sounds like a different problem. Can you check that your pi is still definitely doing --advertise-exit-node, and that you don’t have any tailscale ACLs blocking it, and that your Linux iptables on the pi isn’t configured to prevent IP forwarding?

18

DNS is only working because I switched to resolution to my PiHole.

No firewall enabled (the pi is behind a firewall - Internet facing). Tailscale ACL’s are default so everything is allowed.

I did a tcpdump on the pi and the only traffic I see coming over the tunnel is DNS resolution to the PiHole server. Traceroute doesn’t even get off of the ipad when exit node is enabled.

19

We have exitnode+DNS related issues in 1.6 which has been mostly addressed in 1.8 (our upcoming release), which will be out in a week or so. Please let us know if you want to try the beta release.

20

I’m already on testflight for iOS. Is there a way to get the beta version working on Raspberry PI Buster?

21

CROSSPOST:

Okay. I got exit node working on my iPad finally. Yay!!

To get it to work, I ended up deleting a very old OpenVPN profile (has been inactive for well over 6 months).

Deleting and re-installing Tailscale got me back to the original issue I was having (DNS not resolving with exit node enabled). IP traffic was routing this time but just no DNS resolution.

I was able to get a new tcpdump and I found that my DNS queries were hitting my pi.hole DNS server via the tailscale interface and answers were hitting the tailscale interface on my PI but various apps on the iPad were not getting the responses.

Now I’m working on breaking things again so I can find what exactly was causing the problem. Seems strange that inactive OpenVPN profiles could cause any issue but then again, I’ve seen similar types of issues when I used to administer multiple types of VPN servers in the past.

I’ll also post this in the DNS thread in case that helps there.