No DNS on Windows client when using exit node

[33b5e5]

From: https://forum.tailscale.com/t/no-dns-when-using-exit-node/477:

---

Tailscale version: 1.6.0 on both nodes

Your operating system & version:

• client is Win 10 20H2 (19042.867)
• exit node is Ubuntu 20.04.2 LTS.

Following https://tailscale.com/kb/1103/exit-nodes, 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.

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.

---

I also commented on #1527, where @danderson noted:

Probably not the same thing. On Windows we explicitly allow DNS traffic to continue using the LAN, to handle the case you describe. Can you file a separate bug with the info you reported in the forum, and the Tailscale IPs of the two nodes in question so I can debug more?

---

IP of Ubuntu exit node: 100.110.232.113
IP of Windows client: 100.83.119.13

LAN of Windows client: 10.0.0.0/24

The (2) DNS servers are on the same LAN. When the exit node feature is enabled, I cannot resolve any queries, and if I try to ping the DNS servers' LAN addresses in Powershell, I get:

Pinging 10.0.0.X with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.

[danderson]

Thanks for the detailed report. You're hitting some of the same issues as #1533, albeit different in the details.

Your local DNS server going unreachable when enabling the exit node is not normal on a Windows client, in that I thought we were explicitly allowing DNS traffic to the local resolver (we don't yet do this on all platforms, but a Windows client should be doing the right thing).

In your initial configuration, can you confirm that you had Magic DNS disabled, and no DNS resolvers set in the Tailscale admin panel? In that configuration, Windows should keep using the local resolver, and the firewall rules we install should allow that traffic to flow. I'm digging through logs and trying to reproduce this now, but if you could confirm that's how you were set up that'd be great.

[danderson]

The problem you seem to be having in the other configuration (using 8.8.8.8 as the resolver) is down to ACLs: your ACL config in the admin panel doesn't allow all traffic to your exit node, so all your outbound connections are being dropped. If you add an ACL entry that permits you to talk to *:*, that should resolve and let you connect out in that configuration. Still working to figure out what happens with your local DNS, since that config should also work and not cause DNS failures.

[33b5e5]

In your initial configuration, can you confirm that you had Magic DNS disabled, and no DNS resolvers set in the Tailscale admin panel?

Correct. I don’t normally use either of those features.

[33b5e5]

@danderson a few other tidbits:

• The Ubuntu exit node is dual stack. The Windows 10 client is IPv4-only. (One thing I was hoping to do with the exit node was enable IPv6 connectivity via Tailscale).

• The only difference I see in the IPv4 routing table on Windows (show route) when the exit node mode is enabled is the one-line addition of the Tailscale route. (I.e., this part seems okay?).

• Disabling the Windows firewall altogether makes no difference.

Please let me know if there is other information I can provide.

The problem you seem to be having in the other configuration (using 8.8.8.8 as the resolver) is down to ACLs: your ACL config in the admin panel doesn't allow all traffic to your exit node, so all your outbound connections are being dropped. If you add an ACL entry that permits you to talk to *:*, that should resolve and let you connect out in that configuration. Still working to figure out what happens with your local DNS, since that config should also work and not cause DNS failures.

Ah, that makes sense. I'll try it, but yes, ideally I would keep using the DNS servers on the LAN. Thanks much for looking into it!

[33b5e5]

I tried enabling exit mode (sudo tailscale up --advertise-exit-node) on a different Ubuntu 20.04.2 machine without IPv6 (100.85.197.80) and tried routing the Windows client (100.83.119.13) through it instead. Same end result -- no DNS and a "General failure" when trying to ping the DNS server in Powershell.

While doing this I noticed the Tailscale admin panel is complaining that this second exit node is "Unable to relay traffic" and says "this machine has IP forwarding disabled and cannot relay traffic. Please enable IP forwarding on this machine to use relay features like subnets or exit nodes." This machine has net.ipv4.ip_forward enabled, but not net.ipv6.conf.all.forwarding. Is this a different bug? Or does an exit node require IPv6?

[DentonGentry]

The exit node function currently implements both IPv4+IPv6, there isn't a notion of an IPv4-only exit node. So if it sees net.ipv6.conf.all.forwarding not set it will flag it, even if you don't really need or use IPv6 connectivity. If you are able to set net.ipv6.conf.all.forwarding the admin panel should mark it as useable as an exit node.

[33b5e5]

I noticed something else on Windows after this comment in the related macOS issue: #1544 (comment)

When I have the exit node mode on, I get timeouts when trying to use nslookup google.com 8.8.8.8 on an external server, but oddly, can still successfully query the local servers with nslookup google.com 10.0.0.8 despite the expectation that the local servers should be unreachable. Also odd: I can't ping these local IPs (General failure) even as they are replying to nslookup.

PS > nslookup google.com 8.8.8.8
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  8.8.8.8

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

PS > nslookup google.com 10.0.0.x
Server:  ant
Address:  10.0.0.x

Non-authoritative answer:
Name:    google.com
Addresses:  2607:f8b0:400a:807::200e
          142.251.33.110

[DentonGentry]

1.19.x builds in https://pkgs.tailscale.com/unstable/ include functionality to forward DNS queries to the exit node, which is expected to resolve most issues like this. This functionality will be in the 1.20 release build.

Both the Windows client and the exit node would need to be running 1.19.x or later.

[LewisSpring]

1.19.x builds in https://pkgs.tailscale.com/unstable/ include functionality to forward DNS queries to the exit node, which is expected to resolve most issues like this. This functionality will be in the 1.20 release build.

Both the Windows client and the exit node would need to be running 1.19.x or later.

Just installed unstable 1.19.187 on my Debian machine, connected to an exit node and DNS now works.

Been trying to work it out for hours! When can I expect to see a stable build with the fixes?

Thanks!

[DentonGentry]

1.20.1 is the current stable version for Linux, and contains the functionality to forward DNS queries to the exit node.

Given the positive report, I'm going to close this as fixed.