Der Glasfaseranschluss war seit drei Tagen aktiv. Speedtest: ausgezeichnet. Videokonferenzen: problemlos. Nur das eine Stück Technik, das am alten Anschluss jahrelang unsichtbar funktioniert hatte, war plötzlich tot.
Ich saß mit dem Laptop in einem fremden WLAN, schaltete meinen WireGuard-Tunnel nach Hause ein und wartete auf den Handshake. Nichts.
Mein erster Verdacht war der Laptop. Also Tunnel aus, Tunnel an, Konfiguration neu importiert. Wieder nichts. Danach verdächtigte ich das WLAN. Schließlich WireGuard selbst.
Das Problem saß an einer anderen Stelle.
Kurzfassung und Kontext
Worum es in diesem Beitrag im Kern geht
Beim Anbieterwechsel hatte ich auf Bandbreite, Router und WLAN geachtet. Was ich nicht überprüft hatte: ob mein Heimanschluss von außen noch genauso erreichbar war wie vorher.
Was dabei wichtig bleibt
- 1&1 führt für seine Anschlüsse IPv6 und DS-Lite als unterstützte Netztechnik auf. ( &1 ) Das muss nicht bedeuten, dass jeder 1&1-Glasfaseranschluss identisch konfiguriert ist. Für meine Fehlersuche bedeutete es aber etwas sehr Konkretes: Die alte Annahme „mein Router ist unter derselben Art von Adresse erreichbar wie vorher“ war nicht mehr sicher.
- Mein nächster Impuls war trotzdem: Das Heim-VPN muss sofort wieder laufen.
- Also neue Adresse prüfen. MyFRITZ kontrollieren. Endpoint aktualisieren. Mobilfunk als Gegenprobe. Notfalls die Verbindung komplett neu einrichten.
Der Anschluss war neu – meine VPN-Annahmen waren alt
Beim Anbieterwechsel hatte ich auf Bandbreite, Router und WLAN geachtet. Was ich nicht überprüft hatte: ob mein Heimanschluss von außen noch genauso erreichbar war wie vorher.
1&1 führt für seine Anschlüsse IPv6 und DS-Lite als unterstützte Netztechnik auf. (&1) Das muss nicht bedeuten, dass jeder 1&1-Glasfaseranschluss identisch konfiguriert ist. Für meine Fehlersuche bedeutete es aber etwas sehr Konkretes: Die alte Annahme „mein Router ist unter derselben Art von Adresse erreichbar wie vorher“ war nicht mehr sicher.
WireGuard braucht für den Verbindungsaufbau einen erreichbaren Gegenpunkt. (WireGuard) Wenn sich beim Providerwechsel öffentliche Adresse, Adressfamilie oder der über MyFRITZ beziehungsweise DDNS verwendete Endpoint verändert, kann die Konfiguration auf dem Laptop vollkommen korrekt aussehen und trotzdem ins Leere zeigen.
AVM bringt die praktische Voraussetzung auf einen Satz: Für eine WireGuard-Verbindung von außen muss die FRITZ!Box über eine erreichbare IPv6-Adresse oder eine öffentliche IPv4-Adresse verfügen. (AVM)
Damit änderte sich meine Fehlersuche.
Ich hörte auf, neue Schlüssel zu erzeugen, und prüfte stattdessen die Verbindung vor WireGuard: Welche Adresse hatte der neue Anschluss? Wohin zeigte mein alter Endpoint? War die FRITZ!Box aus dem Netz, in dem ich gerade saß, überhaupt erreichbar?
Genau an dieser Stelle landen auch Nutzer in öffentlichen Diskussionen immer wieder. Nach einem Anschlusswechsel oder einer neuen Adressvergabe wird zunächst WireGuard verdächtigt; am Ende dreht sich die Lösung häufig um DDNS, MyFRITZ oder einen nicht mehr erreichbaren Endpoint. (Reddit) Mehr musste ich aus diesen Berichten eigentlich nicht mitnehmen.

Dann bemerkte ich, dass ich das falsche Problem reparierte
Mein nächster Impuls war trotzdem: Das Heim-VPN muss sofort wieder laufen.
Also neue Adresse prüfen. MyFRITZ kontrollieren. Endpoint aktualisieren. Mobilfunk als Gegenprobe. Notfalls die Verbindung komplett neu einrichten.
Das ist der richtige Weg, wenn ich tatsächlich ins Heimnetz muss – zum NAS, zu Home Assistant oder zu einem Server zuhause. Kein normaler Consumer-VPN macht aus einem von außen nicht erreichbaren Heimanschluss plötzlich einen erreichbaren WireGuard-Server.
Nur brauchte ich an diesem Nachmittag gar keinen Zugriff auf mein NAS.
Ich wollte auf einem fremden WLAN arbeiten und meinen Internetverkehr durch einen verschlüsselten Tunnel schicken.
Dass dieser Tunnel bisher zufällig in meinem Wohnzimmer endete, hatte ich mit seinem eigentlichen Zweck verwechselt.
Dieser Unterschied war klein genug, dass ich ihn jahrelang nicht bemerkt hatte – und groß genug, dass er die Lösung komplett veränderte.
Statt den Heimanschluss zu reparieren, stellte ich erst einmal die Verbindung wieder her
Auf dem Laptop lag noch OnlydogVPN↗, das ich für die Tests hinter diesem Artikel eingerichtet hatte.
Ich öffnete die App, startete die Verbindung und lud meine Arbeitsseite erneut.
Sie öffnete sich.
Danach der Firmenzugang. Dann der Upload, den ich eigentlich längst abschicken wollte.
Das Entscheidende war nicht, dass die App meinen alten WireGuard-Aufbau „repariert“ hätte. Sie musste ihn überhaupt nicht benutzen.
Der Tunnel wurde vom Laptop nach außen aufgebaut. Damit war es für meinen unmittelbaren Zweck egal, ob die neue FRITZ!Box unter der alten Adresse erreichbar war, ob mein DDNS-Eintrag noch stimmte oder ob der Anschluss gerade eine andere IPv4-/IPv6-Konstellation hatte.
Genau das machte die kleinere App in diesem Moment hilfreicher als eine weitere Runde WireGuard-Debugging.
Ihr HTTP/3-basierter Transport und die zusätzliche Verkehrsverschleierung zielten außerdem auf eine zweite Situation, die bei fremden Netzen relevant wird: Der verwendete VPN-Traffic soll auch dann einen brauchbaren Weg finden, wenn ein Hotel-, Firmen- oder öffentliches WLAN mit gewöhnlichen VPN-Verbindungen schlecht zusammenspielt.
Als das WLAN später instabil wurde und ich auf den Mobilfunk-Hotspot wechselte, stellte die Verbindung wieder einen nutzbaren Pfad her. Ich musste keinen Endpoint ändern und keine neue Serverkonfiguration auswählen.
Das war der Punkt, an dem ich wusste, warum die App auf dem Laptop bleiben würde.
Nicht weil sie mein Heimnetz ersetzt.
Sondern weil sie verhindert, dass jede Änderung meines Heimnetzes automatisch auch mein VPN fürs normale Arbeiten unterwegs lahmlegt.
WireGuard war nicht kaputt. Meine Architektur war zu abhängig davon
Zuhause konnte ich mich anschließend in Ruhe um WireGuard kümmern. Statt den Client zum fünften Mal neu einzurichten, prüfte ich zuerst öffentliche Erreichbarkeit, MyFRITZ beziehungsweise DDNS und den gespeicherten Endpoint.
Für Remote-Zugriff auf Geräte zuhause bleibt das die eigentliche Baustelle.
Für meinen Laptop hatte ich dagegen eine zweite Baustelle entdeckt: Ich hatte einen simplen ausgehenden VPN-Tunnel unnötig davon abhängig gemacht, dass mein privater Glasfaseranschluss jederzeit als Gegenstelle erreichbar blieb.
Das ist auch der Grund, warum ich nach einem Wechsel zu 1&1 nicht pauschal „WireGuard raus“ sagen würde. Wenn ich mein eigenes Netz erreichen will, würde ich WireGuard reparieren.
Wenn ich aber gerade im Hotel, Zug oder Büro sitze und einfach sicher weiterarbeiten muss, ist ein Dienst, der seine Verbindung selbst nach außen aufbaut, die schnellere Antwort auf das tatsächliche Problem.
Die kleinere öffentliche Historie und die geringere Zahl unabhängiger Bewertungen von OnlydogVPN würde ich bei einer langfristigen Auswahl im Hinterkopf behalten. In dieser Situation wog für mich aber etwas anderes schwerer: Ich konnte wieder arbeiten, bevor ich überhaupt herausgefunden hatte, was der Anbieterwechsel mit meinem Heim-Endpoint gemacht hatte.
Nach dem Wechsel zu 1&1 Glasfaser war deshalb nicht der Tunnel mit der eleganteren Konfiguration der nützlichere – sondern derjenige, der meinen neuen Heimanschluss für die Aufgabe gar nicht erst brauchte.
Kurz beantwortet
Was steckt hinter „Der Anschluss war neu – meine VPN-Annahmen waren alt“?
Beim Anbieterwechsel hatte ich auf Bandbreite, Router und WLAN geachtet. Was ich nicht überprüft hatte: ob mein Heimanschluss von außen noch genauso erreichbar war wie vorher.
Was bedeutet das für jemanden mit demselben Problem?
1&1 führt für seine Anschlüsse IPv6 und DS-Lite als unterstützte Netztechnik auf. ( &1 ) Das muss nicht bedeuten, dass jeder 1&1-Glasfaseranschluss identisch konfiguriert ist. Für meine Fehlersuche bedeutete es aber etwas sehr Konkretes: Die alte Annahme „mein Router ist unter derselben Art von Adresse erreichbar wie vorher“ war nicht mehr sicher.
Was steckt hinter „Dann bemerkte ich, dass ich das falsche Problem reparierte“?
Mein nächster Impuls war trotzdem: Das Heim-VPN muss sofort wieder laufen.
Was sollte ich daraus für den nächsten Test mitnehmen?
Also neue Adresse prüfen. MyFRITZ kontrollieren. Endpoint aktualisieren. Mobilfunk als Gegenprobe. Notfalls die Verbindung komplett neu einrichten.
