Ein Kunde bereitete sich auf eine bevorstehende Geschäftsreise vor und benötigte eine zuverlässige Möglichkeit, drei Firmen-Laptops über Tailscale, ein sicheres Mesh-VPN, miteinander zu verbinden: Zwei Laptops sollten im Büro bleiben, der dritte sollte ihn auf die Reise begleiten. Ziel war, dass Dateizugriff, Drucker-Freigaben und Remote-Desktop-Sitzungen zwischen allen drei Geräten funktionieren, unabhängig davon, wo sich der reisende Laptop gerade befand. Alle drei Geräte liefen unter Windows 11 Pro. Vor der Kontaktaufnahme hatte der Kunde bereits die üblichen Punkte geprüft: Remote-Desktop aktiviert, Firewall-Regeln für eingehendes RDP gesetzt und das Netzwerkprofil auf allen drei Laptops auf „Privat” gestellt. Nichts davon half — die Laptops konnten sich weder im lokalen Netzwerk noch über Portweiterleitung erreichen.
Dieses Muster sehen wir häufig bei Remote-Access- und VPN-Mesh-Netzwerken: Das Problem wirkt wie ein Windows-Netzwerkproblem, die eigentliche Ursache liegt aber eine Ebene höher — in der VPN- beziehungsweise Tunneling-Konfiguration selbst.
Schritt 1: Die eigentliche Anforderung verstehen
Als die Anfrage einging, stellte unser Support-Team zunächst gezielte Rückfragen, bevor vorschnell von einem klassischen Remote-Desktop-Protocol-(RDP)-Problem ausgegangen wurde. Dabei wurde klar: Das eigentliche Ziel des Kunden war umfassender als „ein paar Laptops verbinden” — er benötigte ein dauerhaftes, sicheres Tailscale-Netzwerk über alle drei Firmengeräte, das auch von unterwegs zuverlässig funktioniert, insbesondere damit der reisende Laptop weiterhin die beiden im Büro gebliebenen Geräte erreichen konnte. RDP war lediglich der Dienst, der später auf diesem Netzwerk laufen sollte.
Wir boten dem Kunden noch in derselben Woche einen Techniker-Termin mit zwei möglichen Zeitfenstern an und baten ihn, in der Zwischenzeit eine einfache Verbindungsprüfung durchzuführen: die lokale IP-Adresse eines Laptops von einem anderen aus anzupingen, solange sich alle drei noch im selben lokalen Netzwerk befanden. So lässt sich schnell klären, ob das Problem auf Ebene des lokalen Netzwerks liegt oder weiter oben im Stack — und unser Techniker konnte mit einem klareren Ausgangspunkt vor Ort starten.
Schritt 2: Diagnose vor Ort
Unser Außendiensttechniker prüfte die Verbindungen vor Ort von Grund auf: ob alle drei Geräte sich im lokalen Netzwerk erreichen konnten, ob Windows-Firewall und Remote-Desktop-Einstellungen auf jedem Gerät korrekt gesetzt waren, und ob die Portweiterleitung am Router funktionierte. Jede dieser Prüfungen fiel einwandfrei aus. Die Geräte waren in Ordnung, das lokale Netzwerk war in Ordnung, und Windows war auf allen drei Laptops korrekt konfiguriert.
Genau dieses durchgehend saubere Ergebnis bei jedem lokalen Test war das entscheidende diagnostische Signal. Es bedeutete, dass der Fehler nicht in der Windows-Konfiguration oder im lokalen Router liegen konnte — er musste in der Ebene liegen, auf die sich der Kunde verließ, um die drei Laptops überhaupt zu verbinden: dem Tailscale-Netzwerk selbst.
Schritt 3: Eskalation und Remote-Prüfung der Tailscale-Konfiguration
Der Fall wurde an einen unserer Level-3-Engineers eskaliert, der den Vor-Ort-Bericht im Detail prüfte. Das Ergebnis: Es lag überhaupt nicht am lokalen Netzwerk oder an den Geräten — sondern an der Tailscale-Konfiguration. Tailscale eignet sich grundsätzlich sehr gut, um eine kleine Anzahl von Firmengeräten wie in diesem Drei-Laptop-Setup sicher zu verbinden, die Einrichtung kann aber schnell detailliert werden, insbesondere bei Zugriffskontrolllisten (ACLs) und geräteseitigen Einstellungen — eine Fehlkonfiguration dort kann den Datenverkehr zwischen bestimmten Geräten blockieren, ohne dass lokal irgendetwas falsch aussieht.
Anstatt einen zweiten vollständigen Vor-Ort-Termin anzusetzen und erneut zu raten, schlug der Level-3-Engineer eine gezielte Remote-Sitzung von etwa 30 Minuten vor, bei der der Kunde in der Tailscale-Admin-Konsole angemeldet ist — als schnellsten Weg zur Lösung, mit einem erneuten Vor-Ort-Termin als Alternative, falls das für den Kunden passender wäre.
Schritt 4: Lösung und Verifizierung
Der Kunde entschied sich für die Remote-Sitzung. Gemeinsam ging unser Engineer direkt in der Tailscale-Admin-Konsole die Zugriffskontrollen und Geräteeinstellungen für alle drei Laptops durch, fand die Einstellung, die die Verbindungen zwischen ihnen unbemerkt blockierte, und korrigierte sie live. Nach der Korrektur verbanden sich alle drei Laptops sofort über das Tailscale-Netzwerk — einschließlich desjenigen, mit dem er in Kürze verreisen würde — und der Kunde bestätigte, dass Remote-Desktop genau wie benötigt vor der Reise funktionierte.
Warum das auch für andere Unternehmen wichtig ist
Die wichtigste Erkenntnis aus diesem Fall ist nicht spezifisch für Tailscale — sie gilt für jedes VPN-Mesh-Netzwerk oder Zero-Trust-Remote-Access-Setup mit mehreren Geräten, ob zwei, drei oder mehr: Wenn jede lokale Netzwerk- und Windows-Einstellung einwandfrei ist, die Geräte sich aber trotzdem nicht erreichen, sollte man aufhören, die lokale Ebene zu untersuchen, und stattdessen die Tunneling-/VPN-Konfiguration selbst prüfen. Strukturierte, methodische Diagnostik — Schritt für Schritt Ursachen ausschließen und dann an die richtige Fachebene eskalieren, statt dieselben Vor-Ort-Prüfungen zu wiederholen — macht aus einem tagelang festgefahrenen Problem eine Lösung in 30 Minuten.
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