🇪🇸 This article is also available in Spanish → Leer en español
🧩 1. Introduction
In this post, I share a real case I experienced by installing both ZeroTier and Tailscale on the same PC running Windows 10 & 11. While both services work very well independently, having them coexist on the same machine caused routing conflicts, connectivity loss, and unpredictable behavior across virtual networks.
The issue didn’t start immediately after installation, but rather appeared suddenly—possibly triggered by client updates or automatic system changes—making it harder to diagnose.
The conflict directly affected my ability to access a Windows Server 2016 machine and also impacted remote users outside my LAN who lost access while the issue was active.
It’s also worth noting that I use ControlD as the DNS service inside Tailscale, which adds encrypted DoH resolution and filtering. This layer too was likely affected by the overlapping virtual networks.
This kind of situation isn't obvious at first but can cause serious disruption if you're relying on these VPNs for remote support, network management, or testing hybrid setups.
🔍 2. Case Background
The problem emerged during my routine support tasks when I noticed that one of my Windows 10 PCs could no longer connect via RDP or respond to ICMP pings to a server running Windows Server 2016 via ZeroTier.
Initially, I didn’t link the issue to VPNs, as the PC had been running both ZeroTier and Tailscale successfully for days or even weeks. But after testing other peers on my ZeroTier network, I noticed inconsistent behavior: some peers were visible, others weren’t, and some routes were being ignored without a clear cause.
The situation worsened when remote users—who connected exclusively via ZeroTier and didn’t use Tailscale—also began experiencing RDP drops and ping failures, as if the server was isolated. This confirmed that the routing conflict wasn’t limited to my local machine, but was degrading ZeroTier’s performance globally.
Eventually, I discovered that Windows' routing table had been altered, with conflicting /16 routes injected by both ZeroTier and Tailscale. Depending on the order in which services or interfaces were activated, Windows would route traffic inconsistently—sometimes cutting off access completely.
The problem was intermittent and misleading, only becoming clear after manually inspecting the routing table using route print and other diagnostic tools.
🔧 3. Technical Diagnosis Step-by-Step
After pinpointing the root cause, I analyzed the Windows routing table using route print. I found that both VPNs were injecting static routes into the system, including:
-
100.64.0.0/10(Tailscale default range) -
172.22.0.0/16(ZeroTier virtual network)
While these routes don’t overlap directly, Windows was arbitrarily prioritizing one over the other—often based on adapter order or recent interface activity.
Even after rebooting the system or the network interfaces, the conflict would return if the VPNs reinitialized in a specific order.
I also discovered that Tailscale’s adapter had a lower metric, so Windows often favored it, sometimes causing ZeroTier routes to become unreachable.
Additionally, I found that my Raspberry Pi, although not directly involved in support, had both ZeroTier and Tailscale installed and connected simultaneously. This contributed to instability by maintaining overlapping VPN participation on a critical node in the network, affecting even the visibility of my Windows Server 2016 host.
Most critically, branch office users relying solely on ZeroTier started experiencing unexpected RDP session disconnections, despite not using Tailscale at all. Their connections were affected indirectly due to route manipulation caused by devices where both VPNs were active.
This created the false impression that the server was down, when in reality, Windows was silently misrouting or dropping traffic.
💡 4. Practical Recommendations to Avoid Conflicts
⚠️ If you're considering running both VPNs simultaneously, here’s what you should watch out for:
🔹 Use smaller subnets like /24 instead of /16 to reduce the chance of overlap.
📴 Manually disable unused interfaces (netsh, Disable-NetAdapter, etc.) to prevent confusion.
📊 Inspect the routing table regularly using route print, especially after restarts or VPN updates.
🧪 Use isolated environments for cross-VPN testing:
-
🖥️ Virtual Machines (VMs)
-
🐳 Containers managed with Docker Compose
-
⚙️ Visual management via Portainer, which simplifies handling container networks
Even devices not actively used for remote support, like my Raspberry Pi running DietPi, can create conflict if connected to both VPNs simultaneously.
🔚 5. Final Thoughts
This experience clearly showed me that—even when two tools are great individually—they don’t always coexist well in the same environment. In my case, ZeroTier and Tailscale ended up competing at the routing level, leading to downtime, false error assumptions, and serious remote access issues.
What made it trickier is that the problem wasn’t immediate or constant—it took time and manual digging to uncover. That’s why it’s so important to monitor virtual network behavior and inspect routing tables frequently in production environments.
The reality is that Windows 10 & 11 don’t manage routing tables reliably, certainly not like Linux or BSD. Route priorities (metrics) are often ignored or overwritten dynamically, which only makes things worse when multiple VPNs are in play.
Today, I make sure to keep each VPN isolated in its own environment. When I need to test them together, I use Docker Compose containers or virtual machines managed with Portainer, so my main systems stay clean.
💬 Have you run into similar issues? Are you using both VPNs without problems? I’d love to hear about your experience—or help you troubleshoot if you're stuck.