Tailscale: Fixing Unreachable Mullvad Exit Nodes

by Viktoria Ivanova 49 views

Introduction

Hey guys, have you ever run into a situation where your Tailscale setup just wasn't working as expected, especially when using Mullvad exit nodes? You're not alone! This article dives deep into a tricky issue where Tailscale can sometimes select an unreachable exit node, leaving you scratching your head. We'll break down the problem, explore potential solutions, and discuss how to ensure your Tailscale network stays smooth and reliable. So, let's get started and figure out how to tackle this together!

The Core Issue: Unreachable Exit Nodes

At the heart of the matter is a frustrating scenario: when using Tailscale with Mullvad exit nodes, the tailscale exit-node suggest command and the tailscale set --exit-node=auto:any setting can sometimes choose an exit node that your client simply can't reach. This often happens when you're behind a firewall that's blocking certain exit node IPs. The real kicker? Tailscale will stubbornly stick with that unreachable node instead of automatically switching to a working one. It's like your GPS insisting on a route that's clearly closed – super annoying!

Understanding the Problem in Detail

Let's paint a clearer picture. Imagine Tailscale is showing you a complete list of Mullvad exit nodes, which is great. But when your client tries to connect directly to a chosen node and fails (because, say, your firewall is playing gatekeeper), Tailscale doesn't give up. It keeps that node as the suggested or active exit node, even though no data is actually flowing through it. This means you're effectively stuck, unable to route your traffic as intended, and Tailscale isn't automatically trying other options. This is a major pain point, especially when you expect seamless connectivity.

What Should Happen? The Ideal Scenario

Ideally, if Tailscale picks an exit node and discovers it can't connect, it should intelligently fall back to another available exit node. This automatic failover is crucial for maintaining a reliable connection. You want Tailscale to be smart enough to say, "Oops, that one's not working. Let me try another!" This kind of resilience is what makes a network truly robust and user-friendly. Without it, you're left manually troubleshooting and switching nodes, which is far from ideal.

Potential Solutions: How to Fix This

Okay, so we know the problem. What can we do about it? One potential workaround involves using the AllowedSuggestedExitNodes system policy. This allows you to limit the pool of available exit nodes to only those that are allowed through your firewall. Think of it as creating a VIP list for exit nodes. However, there's a catch: this feature isn't yet implemented for Linux clients, which is a significant limitation for many users.

Diving Deeper into Solutions: A More Robust Approach

As @sfllaw wisely pointed out, hardcoding a pool of exit nodes might not be the most reliable long-term solution. IP whitelists can easily fall out of sync, leading to more headaches down the road. The real issue, as they highlight, is that the Tailscale client isn't handling the situation gracefully when it can't directly connect to a Mullvad exit node. This is because Mullvad endpoints are WireGuard-only and don't support DERP, which is Tailscale's fallback relay mechanism.

The preferred solution, therefore, is to implement a check to ensure a connection to the selected exit node is actually possible. This would involve Tailscale verifying connectivity before committing to a particular node. This approach is much more dynamic and adaptable to changing network conditions.

Reproducing the Issue: A Step-by-Step Guide

Want to see this problem in action? Here's how you can reproduce it:

  1. Set up Tailscale on your server: Get Tailscale installed and running on your server.
  2. Configure Mullvad exit nodes: Tell Tailscale to use Mullvad exit nodes.
  3. Run tailscale set --exit-node=auto:any: This command instructs Tailscale to automatically choose an exit node.
  4. Check the external IP: Note the external IP address of the selected exit node.
  5. Simulate a restricted network: Use iptables (or your preferred firewall tool) to block traffic to the selected exit node's IP. For example:
    iptables -A OUTPUT -p udp -d 1.2.3.4 -j DROP
    (Replace 1.2.3.4 with the actual IP address of your exit node.)
  6. Observe the failure: You'll see that auto:any doesn't switch to a different exit node, even though it can't connect to the current one.

Real-World Example: Firewall Fun

Imagine you're in a coffee shop with a restrictive firewall. You set up Tailscale to use a Mullvad exit node, hoping for secure browsing. Tailscale happily selects a node, but unbeknownst to you, the coffee shop's firewall is blocking that specific IP. You're left with a connection that doesn't actually work, and Tailscale isn't smart enough to try another node. This highlights the importance of a robust fallback mechanism.

Key Takeaways and Possible Improvements

This issue underscores the need for Tailscale to be more proactive in handling unreachable exit nodes. Here are some key takeaways and potential improvements:

  • Connection Verification: Before settling on an exit node, Tailscale should verify that a connection can actually be established.
  • Automatic Fallback: If a connection fails, Tailscale should automatically try another available exit node.
  • DERP Integration: Explore ways to leverage DERP for Mullvad exit nodes to provide a fallback mechanism when direct connections aren't possible.
  • Linux Support for AllowedSuggestedExitNodes: Implementing this feature for Linux clients would provide a valuable workaround.

Additional Information: System Details

For those interested in the nitty-gritty details, here's some system information related to this issue:

  • OS: Linux (specifically Ubuntu 24.04.2 LTS)
  • Tailscale Version: 1.86.2
  • Other Software: No other relevant software was mentioned in the original report.

Conclusion: Towards a More Resilient Tailscale

In conclusion, the issue of Tailscale selecting unreachable Mullvad exit nodes is a real pain point that needs addressing. While workarounds exist, the ideal solution involves Tailscale actively verifying connections and automatically falling back to working nodes. By implementing these improvements, Tailscale can become even more reliable and user-friendly, ensuring seamless and secure connectivity for everyone. Let's hope the Tailscale team tackles this soon!