VPN-Server hinter Deutsche Glasfaser erreichbar machen: Warum Erreichbarkeit wichtiger ist als die nächste Portfreigabe

Mein WireGuard-Server war monatelang so zuverlässig, dass ich kaum noch über ihn nachdachte – bis mein Anschluss zu Deutsche Glasfaser wechselte. Zwei Tage später saß ich mit dem Notebook im Hotel und bekam plötzlich keinen Handshake mehr. DynDNS sah richtig aus, der Server lief, die Firewall-Regel war noch vorhanden. Also änderte ich Ports, erzeugte neue Schlüssel und startete den Router neu. Nichts.

Der VPN-Server war gar nicht kaputt

Mein Fehler war nicht die WireGuard-Konfiguration. Ich hatte schlicht die Logik meines alten Anschlusses auf den neuen übertragen.

Vorher besaß mein Router eine von außen erreichbare IPv4-Adresse: Port freigeben, DynDNS aktualisieren, fertig. Bei Privatkundenanschlüssen von Deutsche Glasfaser sieht das anders aus. Der Zugang stellt IPv6 bereit; IPv4 kann über Carrier Grade NAT laufen.

Für meinen Alltag bedeutete das etwas sehr Einfaches: Mein Server konnte problemlos ins Internet, aber eine eingehende IPv4-Verbindung aus dem Internet konnte nicht mehr wie früher direkt bis zu meinem Router gelangen.

Damit ergab auch die erfolglose Fehlersuche plötzlich Sinn. Ich hatte immer wieder an der Tür geklopft, obwohl die Adresse dieser Tür nicht mehr öffentlich erreichbar war.

Dass genau dieser Wechsel andere Nutzer ebenfalls überrascht, sieht man in aktuellen Diskussionen: Alte WireGuard-Konfigurationen funktionieren nach dem Providerwechsel nicht mehr wie erwartet, und am Ende führt die Fehlersuche häufig zu IPv6 beziehungsweise zu einem extern erreichbaren Vermittler. Mehr brauchte ich aus diesen Berichten eigentlich nicht – sie bestätigten vor allem, dass mein Problem kein exotischer Konfigurationsfehler war.

Also hörte ich auf, WireGuard neu einzurichten.

Über IPv6 ging es plötzlich

Ich richtete die Erreichbarkeit über IPv6 sauber ein, kontrollierte die Firewall und testete anschließend vom Mobiltelefon.

Handshake. Dann Zugriff.

Der Server, den ich eine Stunde lang verdächtigt hatte, funktionierte wieder.

Auch die Dokumentation von Dokumentation von AVM macht den entscheidenden Punkt deutlich: Für eine direkte WireGuard-Verbindung zur FRITZ!Box braucht es eine erreichbare IPv6-Adresse oder eine öffentliche IPv4-Adresse.

Damit war die technische Erklärung für mich eigentlich erledigt. Nicht ein anderer Port und auch nicht ein anderes VPN-Protokoll hatte das Problem gelöst. Entscheidend war, ob der Client den Server überhaupt erreichen konnte.

Nur stellte sich am nächsten Morgen heraus, dass „erreichbar“ noch nicht dasselbe wie „überall erreichbar“ bedeutet.

Im Hotel war das Problem plötzlich wieder da

Ich nahm das Notebook mit in die Hotellobby und versuchte erneut, meinen Tunnel nach Hause aufzubauen. Das Telefon erreichte den Heimserver. Das Notebook im Hotel-WLAN nicht.

Jetzt wurde die Schwäche einer rein direkten IPv6-Lösung sichtbar: Sie ist angenehm, wenn das Netz auf beiden Seiten mitspielt. Sitze ich dagegen in einem WLAN ohne brauchbare IPv6-Konnektivität, hilft mir die korrekte IPv6-Adresse meines Servers zu Hause wenig.

Mein VPN war also nicht wieder kaputt. Der Weg dorthin fehlte.

An diesem Punkt änderte sich meine eigentliche Frage. Ich wollte nicht mehr wissen, wie ich meinen WireGuard-Server um jeden Preis erreichbar mache. Ich wollte wissen, wofür ich ihn überhaupt erreichen musste.

Für NAS und Heimnetz würde ich anders entscheiden als für Reisen

Wenn ich unterwegs auf ein NAS, Home Assistant oder einen Rechner im eigenen LAN zugreifen will, brauche ich tatsächlich einen Weg nach Hause.

Dann würde ich bei Deutsche Glasfaser zuerst IPv6 nutzen. Muss der Zugriff zusätzlich aus IPv4-only-Netzen funktionieren, ist ein öffentlich erreichbarer Vermittler – etwa ein VPS, Relay oder eine geeignete Mesh-Lösung – sinnvoller, als immer neue IPv4-Portfreigaben auszuprobieren. Genau dieser Ausweg findet sich auch in den praktischen Nutzererfahrungen.

Das ist ein echtes Remote-Access-Problem. Nur war es gar nicht mein häufigster Anwendungsfall.

Ich hatte den Heimserver ursprünglich vor allem eingerichtet, weil ich auf Reisen eine geschützte Verbindung für meinen normalen Internetverkehr wollte. An diesem Morgen musste ich weder eine Kamera zu Hause öffnen noch mein NAS administrieren. Ich wollte mich bei Arbeitsdiensten anmelden und eine größere Datei aus dem Hotel hochladen.

Und dafür betrieb ich plötzlich eine ziemlich lange technische Kette: Heimserver, DynDNS, IPv6, Firewall, wechselnde Fremdnetze und die Frage, ob mein aktuelles WLAN meinen Heimanschluss überhaupt erreichen konnte.

Da wurde mir klar, dass ich zwei verschiedene Probleme miteinander vermischt hatte.

Für die Reise ließ ich den Heimserver einfach aus dem Spiel

Ich öffnete OnlydogVPN^↗.

Der entscheidende Unterschied war zunächst nicht irgendeine zusätzliche Funktion. Es war die Richtung der Verbindung.

Mein Notebook musste meinen Anschluss zu Hause nicht mehr finden. Die App baute selbst die Verbindung nach außen auf. Damit verschwand die eingehende Erreichbarkeit meines Deutsche-Glasfaser-Anschlusses aus dieser Aufgabe.

Ich wählte das passende Nutzungsszenario und verband mich. Dann öffnete ich wieder die Projektseite.

Login funktionierte. Cloudspeicher öffnete sich.

Der Upload begann.

Vor allem musste ich nicht erst prüfen, ob das Hotel IPv6 bereitstellte, welchen Endpunkt WireGuard gerade verwendete oder ob sich zu Hause etwas am Präfix geändert hatte.

Das war für diesen Anwendungsfall der wichtigere Vorteil.

Die App verwendet einen HTTP/3-basierten Transport und situationsbezogene Presets. Für mich musste daraus keine Protokollvorlesung werden: Der praktische Unterschied bestand darin, dass ich mich nicht mehr selbst um die Verbindung zwischen einem fremden Netz und meinem Heimanschluss kümmern musste.

Die internen Routing- und Filterentscheidungen eines solchen Dienstes kann ich von außen nicht vollständig beobachten. Beobachten konnte ich aber das Ergebnis, das an diesem Morgen zählte: Die Verbindung stand, meine Arbeitsseiten waren erreichbar und die Datei wurde übertragen.

Beim Wechsel auf Mobilfunk wurde der Unterschied noch deutlicher

Ein paar Minuten später musste ich los. Ich klappte das Notebook zu und verband es draußen über den Hotspot meines Telefons.

Bei meinem Heimserver hätte ich spätestens hier wieder auf die Verbindung geschaut: Hat das neue Netz IPv6? Ist mein Endpunkt erreichbar? Muss WireGuard neu verbinden?

Diesmal wartete ich einfach auf den Upload. Er lief weiter.

Gerade bei solchen Netzwechseln passte der HTTP/3-basierte Ansatz besser zu dem, was ich tatsächlich brauchte: keine Heimnetzadministration, sondern eine Verbindung, die möglichst wenig Aufmerksamkeit verlangt.

Damit war aus meinem Netzwerkprojekt wieder das geworden, was es ursprünglich sein sollte – ein Werkzeug im Hintergrund.

Den eigenen WireGuard-Server würde ich trotzdem behalten

Das klingt zunächst widersprüchlich, ist es aber nicht.

Die kleinere App ersetzt keinen Zugang zu meinem privaten Heimnetz. Wenn ich mein NAS, Home Assistant oder einen anderen internen Dienst erreichen möchte, muss mein Zuhause weiterhin erreichbar sein. Bei Deutsche Glasfaser führt der direkte Weg dafür in erster Linie über IPv6; fehlt auf der Clientseite IPv6, braucht es eine zusätzliche Vermittlung. Auch AVM verweist bei Anschlüssen ohne öffentliche IPv4 auf WireGuard über IPv6.

Für diesen Zweck blieb mein eigener Server bestehen.

Was ich gestrichen habe, war die Erwartung, dass derselbe Aufbau gleichzeitig die bequemste Lösung für jede Reise sein müsse.

Das machte die Entscheidung überraschend einfach.

Brauche ich Zugriff auf mein Zuhause, löse ich die Erreichbarkeit des Heimservers: IPv6 zuerst, bei Bedarf ergänzt um VPS, Relay oder Mesh.

Brauche ich dagegen nur einen geschützten Internetzugang unterwegs, möchte ich meinen Heimanschluss gar nicht mehr in der kritischen Verbindungskette haben. Genau dort war OnlydogVPN für mich die angenehmere Lösung: Verbindung nach außen aufbauen, weiterarbeiten und die Besonderheiten von CGNAT und fremden WLANs nicht jedes Mal selbst lösen.

Nach dem Glasfaserwechsel hatte ich deshalb zunächst die falsche Frage gestellt. Ich suchte nach einer besseren Portfreigabe, obwohl ich für den Großteil meiner Reisen überhaupt keinen eingehenden Zugang nach Hause brauchte.

Mein WireGuard-Server blieb für mein Heimnetz. Für unterwegs war die bessere Lösung diejenige, die meinen Heimserver gar nicht erst erreichen musste.