A client preparing for an upcoming business trip needed a reliable way to keep three company laptops connected to each other over Tailscale, a secure mesh VPN: two laptops would stay behind at the office, while the third would travel with him. The goal was to keep files, printers, and remote desktop sessions working between all three devices no matter where the traveling laptop was. All three machines were running Windows 11 Pro. Before contacting us, the client had already worked through the standard checklist: Remote Desktop enabled, Windows Firewall rules opened for inbound RDP, and the network profile on all three laptops set to "Private." None of it helped — the laptops couldn't see each other, either on the local network or through port forwarding.
This is a common pattern we see with remote access and VPN mesh networking: the problem looks like a Windows networking issue, but the real cause sits one layer up, inside the VPN or tunneling configuration itself.
Step 1: Understanding the Real Requirement
When the request came in, our support team asked a few clarifying questions before assuming this was a standard Remote Desktop Protocol (RDP) problem. It became clear the client's actual goal was broader than "connect a couple of laptops": he needed a persistent, secure Tailscale network across all three company devices that would keep working from any location, specifically so the laptop he was traveling with could still reach the two staying behind. RDP was simply the service he planned to run on top of that network once it was in place.
We offered a technician visit for the same week, with two available windows, and asked the client to run a basic connectivity check in the meantime: pinging one laptop's local IP address from another, while all three were still on the same local network. This is a fast way to rule out whether the issue is happening at the local network layer or further up the stack, and it let the client and our engineer arrive at the site with a clearer starting point.
Step 2: On-Site Diagnostics
Our field engineer visited on site and worked through the connections from the ground up: verifying all three devices could reach each other on the local network, confirming Windows Firewall and Remote Desktop settings were correctly applied on each machine, and testing port forwarding on the router. Every one of these checks came back clean. The devices were healthy, the local network was healthy, and Windows was configured correctly on all three laptops.
That consistently clean result across every local-network test was itself the key diagnostic signal. It meant the fault could not be sitting in Windows configuration or the local router — it had to be in the layer the client was relying on to bridge the three laptops together in the first place: the Tailscale network itself.
Step 3: Escalation and Remote Tailscale Review
The case was escalated to one of our Level 3 engineers, who reviewed the field engineer's on-site report in detail. The conclusion: this wasn't a local network or device fault at all — it was a Tailscale configuration issue. Tailscale is genuinely a strong fit for securely connecting a small number of business devices like this three-laptop setup, but its setup can get detailed fast, particularly around elv/access-control" class="text-blue-700 underline underline-offset-2 hover:text-blue-900">access control lists (ACLs) and per-device settings, and a misconfiguration there can silently block traffic between specific devices even when every local Windows and router setting looks correct.
Rather than schedule a second full on-site visit and guess again, the Level 3 engineer proposed a focused remote session — about 30 minutes, with the client logged into the Tailscale admin console — as the fastest path to a fix, with an on-site revisit offered as a backup if that was more convenient for the client.
Step 4: Resolution and Verification
The client chose the remote session. Working directly through the Tailscale admin console together, our engineer walked through the access control and device configuration for all three laptops, identified the setting that was silently blocking connections between them, and corrected it live. Once the fix was applied, all three laptops connected to each other over the Tailscale network immediately — including the one he was about to travel with — and the client confirmed Remote Desktop worked exactly as needed ahead of his trip.
Why This Matters for Other Businesses
The most useful lesson from this case isn't specific to Tailscale — it applies to any VPN mesh network or zero-trust remote access setup connecting several devices, whether that's two, three, or more: when every local network and Windows setting checks out clean but devices still can't reach each other, stop troubleshooting the local layer and start reviewing the tunneling/VPN configuration itself. Structured, methodical diagnostics — ruling things out one layer at a time, then escalating to the right level of expertise rather than repeating the same on-site checks — is what turns a stuck, days-old problem into a 30-minute fix.
The Challenge
A business client needed a stable Tailscale connection across three Windows 11 Pro laptops ahead of an upcoming business trip — two laptops would remain at the office, and the third would travel with him — so that Remote Desktop, file access, and printer sharing would keep working between all three devices while he was away. Despite correctly configuring Remote Desktop, Windows Firewall rules, and setting all three network profiles to "Private," the laptops could not connect to each other — not locally, and not through port forwarding.
Our Solution
Our field engineer completed a full on-site diagnostic, confirming the local network, all three devices, and every Windows setting were correctly configured and healthy. Since every local-layer test passed, the case was escalated to a Level 3 engineer, who identified the true cause as a Tailscale access control and device configuration issue affecting how the devices could reach each other. A focused 30-minute remote session through the Tailscale admin console located and corrected the misconfiguration.
Expert Insight
Tailscale and similar mesh VPNs are genuinely a good fit for small and mid-sized businesses that need secure device-to-device connectivity without the overhead of a traditional site-to-site VPN, including setups like this one where a traveling laptop needs to reach devices left back at the office. The trade-off is that the configuration surface — particularly access control lists and per-device settings — is easy to get subtly wrong, and a wrong setting there fails silently rather than throwing a clear error. Our approach in cases like this is to fully rule out the local network and OS configuration first, since that is fast to verify, before escalating to a specialist review of the VPN layer itself.
References & Sources