Tailscale exit nodes take my home internet with me when I travel

Shekhar Vaidya is a veteran technology journalist and computer science engineer. He is the founder of TechLatest, where he has spent years providing technical analysis on hardware and Windows ecosystems. Now a Computing Writer at XDA, Shekhar leverages his deep background in NAS, storage solutions, and PC internals to help readers master their tech.

I advertised my home server as a Tailscale exit node, then joined the same tailnet on my phone and enabled the exit node while using mobile data. And I saw my home connection’s IP address instead of my carrier's. So, even when I am away from home Wi-Fi, the websites I visit think my phone is sitting on my home fiber line.

A Tailscale exit node routes the internet traffic of any device on the same tailnet that opts in through another device I chose, in my case, the home server. An exit node looks similar to the subnet router but works completely differently. I tested it. It works, but not in every way you would expect.

Turning my home server into an exit node

Hop one wasn’t my router

I have been using Tailscale on my home Debian server for more than a year. I opted for it in the early days of my homelab because my internet connections were behind CGNAT. Even after so long, I still discover new features every now and then. A few weeks ago, I tried its subnet router feature, and it has been good for me. Another feature is exit nodes.

The initial setup was simple, like any other Tailscale feature. I have many devices under the same tailnet, and a few of them stay at home permanently, like my server, the NAS, and the PC. So one of these three was a good choice to advertise the exit node. The NAS was outdated (old hardware and an old Tailscale package), and I couldn’t keep my 7700X-4070 Ti PC ON 24/7, so I chose the server to be the exit node.

To test it, I connected my PC and phone to the same Tailnet with the server as the exit node. For a moment, when I tried to connect my PC to the Tailnet, I didn’t see the server in the exit node list, but it was fixed only after I restarted the Tailscale app.

Before visiting any website or doing an IP test, I simply ran a few successful ping tests and even inspected the route using tracert. tracert showed me the whole route. The first hop was my server’s Tailscale address, then my router, and then the ONT (Optical Network Terminal). The first hop being the server proved the traffic had entered the tunnel.

After those simple tests, I ran tailscale status from the server terminal, and the best part was there — my phone showed a direct connection. And this was when the phone was on mobile data and the home primary connection was double-NAT’d. But these were kind of lab tests; I wanted to see how it would act in real-world use.

What came along for the ride

My speed test flipped on me

The first real-world test was how a third-party website behaves, and the best place to start was an IP test. In all the tests, the phone stayed connected to the tailnet, and I just toggled the exit node on and off.

I visited a random “check my IP” website. The website showed my carrier’s address when the exit node was off and my home IP address when it was on. That was the first good sign. If an unknown website couldn’t distinguish the connections, I figured it would work with most apps and websites.

My one concern was speed. I assumed that, since the connection was hopping multiple hops, the speed would suffer too. But believe me, I was amazed on the first test, and the second test made everything normal.

In the first test, with the exit node off, I got 145Mbps down/10.9Mbps up, and with the exit node on, I got 185Mbps down/11Mbps up. I thought, “Did the exit node speed up the connection?” but no, the cellular connection was acting up, and the next test backed that up. The next morning, I got 242/3.38 Mbps (exit node off) and 234/2.01 Mbps (exit node on).

An exit node might help in some cases, not by actually speeding up the connections but by routing the traffic through my home connection when I am on a congested carrier route. But this is just my theory built on a few VPN providers' claims; I didn’t test it.

These test results were below my home internet connection’s rated speed of 300/300 Mbps, so for these tests at least, my home line wasn’t a bottleneck. The upload speeds pointed in the same direction. But this is my theory; I would have verified the bottleneck if my phone’s cellular speed were faster than my home connection.

Any café or hotel network should only see an encrypted Tailscale connection, which is a plus. But don’t think of the feature as a privacy move; with the exit node enabled, the phone’s traffic just reroutes through my home server and leaves through my home internet connection. So, technically, it just shifts trust to my ISP rather than disappearing.

When these tests proved successful, I got another idea: if I can carry my home connection with me, then why not my home DNS too?

What stayed behind

My tunnel worked, and my DNS didn’t come along

I have been using AdGuard Home (AGH) at home for a long time. I set my router to use it as the DNS server so every device on my home network uses it without extra per-device setup. But it only works when I am home (if I keep aside my experimental public endpoints). So after a successful attempt at the exit node, I thought the DNS would work the same way.

Well, that was the start of several unsuccessful attempts and hours of troubleshooting. I started by adding the server’s Tailscale address as a DNS nameserver and turning on override DNS servers in the admin console. As soon as I connected to the tailnet on my phone and PC, I lost internet, and turning off the Tailscale DNS restored the internet. And the weird part was that the Tailscale connection itself was established, but none of the websites would load.

Then I remembered I had restricted devices from using DNS in AGH settings. I immediately opened AGH DNS settings and found that the Tailscale address range was already there in the allowed client list. So, Tailscale was already allowlisted; still, I had no internet.

After that I ran tcpdump on the server, and I tried to establish a connection (DNS query) from the PC. That's when I noticed that Tailscale’s NAT seemed to rewrite tailnet queries to the Docker bridge address (192.168.32.1). As a fix, I added the Docker bridge address to the allowed client list, and it worked perfectly after that.

But this simple fix raised more concerns. The AGH query log showed many entries under the same address, even for my public DoH endpoint. My public DoH endpoint was protected with ClientIDs, but this change exposed it to the public, which I didn’t want. I even tested the DoH endpoint from a VPS without a ClientID, and yet AGH accepted the request.

So I removed the Docker bridge address from the AGH allowlist. I also added public Quad9 as a workaround to get Tailscale DNS working with the exit node. AGH following me even when I was away would have been the best use case for me, but unfortunately it didn’t. I still don’t know whether the issue is with Tailscale or AGH.

It works, but not for me yet

Up until a few days ago, Tailscale exit nodes were a theory for me. But after using it on my home server and devices, I can say it works, but not in every way — DNS is a good example. I haven't found a proper use case that fits my day-to-day workflow, but for now I am keeping it as is. Exit nodes are useful if you want your internet traffic to leave through a familiar home connection while traveling, or if you’d rather not use a sensitive app on public Wi-Fi.