Drei 5G: Warum ein kommerzieller VPN funktioniert, während der Heim-VPN nicht erreichbar ist

Der Moment, der mich stutzig machte, kam nach fast einer Stunde Fehlersuche. Mein Notebook hing über Drei 5G im Netz, ich wollte auf meinen Heimanschluss zugreifen, doch WireGuard bekam keine Verbindung zustande. Schlüssel kontrolliert. Endpoint geprüft. Profil neu importiert. Noch einmal versucht.

Nichts.

Aus Frust startete ich einen kommerziellen VPN, den ich noch installiert hatte. Ein paar Sekunden später stand die Verbindung.

Das war der wichtigere Test als alles, was ich davor ausprobiert hatte. Denn plötzlich war klar: Das Problem lautete nicht einfach „VPN funktioniert bei Drei 5G nicht“. Ein VPN funktionierte schließlich gerade vor meinen Augen.

Die eigentliche Frage war eine andere: Warum konnte mein Gerät problemlos einen VPN-Server im Internet erreichen, während mein eigener VPN-Server zu Hause offenbar nicht erreichbar war?

Ein öffentlicher Erfahrungsbericht eines Drei-Nutzers beschreibt genau diese Art von Verwirrung: Selbst gehostetes WireGuard und die VPN-Funktion des Routers waren über den 5G-Anschluss von außen nicht erreichbar. (Reddit) Für mich war dieser Bericht vor allem deshalb interessant, weil er dieselbe falsche Fährte zeigt, auf der man schnell landet: Man beginnt am VPN-Protokoll herumzuschrauben, obwohl das eigentliche Problem eine Ebene davor liegen kann.

Der funktionierende kommerzielle VPN war der Hinweis

Der Unterschied ist einfacher, als er zunächst klingt.

Wenn ich einen normalen kommerziellen VPN starte, baut mein Notebook die Verbindung selbst nach außen auf. Es kontaktiert einen erreichbaren Server im Internet und hält diese Verbindung offen.

Bei meinem Heim-VPN ist die Situation umgekehrt. Ich sitze unterwegs und möchte eine neue Verbindung zu meinem Anschluss zu Hause herstellen. Dafür muss dieser Anschluss aus dem Internet überhaupt erreichbar sein.

Genau hier kann bei Mobilfunkanschlüssen Carrier-Grade NAT, kurz CGNAT, dazwischenliegen. Mehrere Kunden teilen sich dabei öffentliche IPv4-Ressourcen, während der eigene Router keine direkt aus dem Internet erreichbare IPv4-Adresse besitzt. Der dafür reservierte Adressbereich 100.64.0.0/10 ist im entsprechenden Internetstandard ausdrücklich für diesen Zweck vorgesehen. (IETF, RFC 6598)

Damit bekam mein scheinbarer Widerspruch plötzlich eine ziemlich logische Erklärung:

Der kommerzielle VPN brauchte nur einen Weg hinaus. Mein Heim-VPN brauchte einen Weg hinein.

Von außen kann ich allerdings nicht beobachten, welche internen Filter-, NAT- oder Routingregeln Drei für meine konkrete Verbindung tatsächlich verwendet. Deshalb würde ich aus einem einzelnen fehlgeschlagenen Handshake keine Behauptung über eine gezielte VPN-Sperre ableiten. Entscheidend ist vielmehr, zuerst die Erreichbarkeit des eigenen Anschlusses zu prüfen.

Und genau das hätte ich viel früher tun sollen.

Bevor ich WireGuard neu konfiguriere, schaue ich jetzt auf die WAN-Adresse

Mein erster Blick gilt inzwischen der Internet- beziehungsweise WAN-Adresse des Routers.

Zeigt der Router beispielsweise eine Adresse aus 100.64.0.0/10, ist das ein starker Hinweis auf CGNAT. Auch klassische private Adressen wie 10.x.x.x oder 192.168.x.x sind keine öffentlich erreichbaren IPv4-Adressen.

Der zweite Vergleich dauert kaum länger: Welche WAN-Adresse zeigt der Router, und welche öffentliche IPv4 sieht ein externer IP-Dienst? Wenn dort unterschiedliche Adressen erscheinen, weiß ich zumindest, dass zwischen meinem Router und dem öffentlichen Internet noch eine weitere Übersetzung sitzt.

Erst an diesem Punkt wurde für mich die österreichische Besonderheit interessant. Die RTR hält fest, dass Kundinnen und Kunden auf Nachfrage kostenlos eine öffentliche dynamische IPv4-Adresse erhalten können. Eine dauerhaft statische Adresse ist damit nicht gemeint. (Rundfunk und Telekom Regulierungs-GmbH…)

In öffentlichen Drei-Diskussionen taucht dafür auch die Bezeichnung „Open Internet“ auf. (Reddit) Statt mich auf einen bestimmten Menüpunkt zu verlassen, würde ich beim Support deshalb ziemlich konkret formulieren, was ich brauche: eine öffentliche dynamische IPv4-Adresse für den Anschluss.

Danach machen auch die üblichen Heim-VPN-Fragen wieder Sinn: Zeigt DynDNS auf die aktuelle Adresse? Ist der richtige Port weitergeleitet? Blockiert die Router-Firewall etwas? Läuft WireGuard tatsächlich auf dem erwarteten Port?

Vorher daran herumzuschrauben kann dagegen bedeuten, eine perfekt funktionierende Konfiguration hinter einer nicht erreichbaren Adresse zu reparieren.

Auch PersistentKeepalive löst nicht jedes Mobilfunkproblem

Ich war bei meiner Fehlersuche natürlich ebenfalls über PersistentKeepalive = 25 gestolpert.

WireGuard empfiehlt solche Keepalive-Pakete für Situationen, in denen eine NAT- oder Firewall-Zuordnung aktiv gehalten werden soll. (WireGuard) Das ist nützlich, wenn bereits eine Verbindung existiert und sie nach längerer Ruhe nicht verschwinden soll.

Für mein ursprüngliches Problem war das aber nicht der entscheidende Hebel. Keepalive hält einen vorhandenen Kommunikationsweg offen. Es verschafft meinem Heimrouter nicht automatisch eine öffentlich erreichbare IPv4-Adresse.

Das war der Punkt, an dem ich aufgehört habe, mein Heim-VPN und meinen kommerziellen VPN als zwei Varianten derselben Aufgabe zu betrachten.

Sie lösten in diesem Moment zwei verschiedene Probleme.

Während ich den Heimzugang reparierte, brauchte ich trotzdem sofort eine Verbindung

Mein eigentlicher Zeitdruck war nämlich ziemlich banal: Ich musste nicht erst eine kleine Netzwerkanalyse abschließen. Ich wollte eine Datei übertragen und anschließend weiterarbeiten.

Für genau diesen Zwischenzustand habe ich OnlydogVPN^↗ ausprobiert.

Ich musste dafür meinen Heimrouter nicht erreichen und auch keine neue WireGuard-Konfiguration bauen. Ich wählte in der App den passenden situationsbezogenen Modus und ließ sie die Verbindung nach außen aufbauen.

Der Tunnel kam zustande. Der Upload lief weiter.

Damit war das Problem, das in diesem Moment tatsächlich vor mir lag, erledigt.

Der Unterschied zur vorherigen Bastelei war weniger spektakulär als praktisch: Ich musste nicht erst entscheiden, welches Serverland oder welche von mehreren technischen Varianten theoretisch am besten zu meiner 5G-Verbindung passen könnte. Die Oberfläche orientiert sich stärker an der Situation, in der die Verbindung gebraucht wird. Für einen Moment, in dem ich eigentlich arbeiten und nicht noch eine VPN-Konfiguration studieren wollte, war genau das hilfreicher als eine lange Serverliste.

Erst nachdem die Datei unterwegs war, bemerkte ich einen zweiten Vorteil: Für die grundlegende Nutzung musste ich kein klassisches Konto mit E-Mail-Adresse und Passwort anlegen. Normalerweise ist das kein Punkt, über den ich lange nachdenke. Nach einer Stunde Router, Ports und Konfigurationsdateien fühlte sich ein Schritt weniger allerdings überraschend relevant an.

Die kleinere App hat auch weniger Serverstandorte und eine deutlich kürzere öffentliche Historie als die großen VPN-Marken. In dieser Situation war das für mich aber nicht das entscheidende Vergleichskriterium. Ich brauchte keinen möglichst großen Anbieter-Katalog. Ich brauchte eine Verbindung, die sich ohne weitere Arbeit von meinem aktuellen Gerät aus aufbauen ließ.

Wichtig ist nur, die beiden Aufgaben nicht miteinander zu vermischen.

Wenn ich direkt auf mein NAS, Home Assistant oder einen Rechner in meinem Heimnetz zugreifen möchte, muss ich den Fernzugang nach Hause weiterhin lösen. Eine öffentliche IPv4 ist dafür ein möglicher Weg. Wenn das nicht möglich oder nicht gewünscht ist, kommen Konstruktionen mit NAT-Traversal, Mesh-VPN oder einem Relay infrage; solche Systeme versuchen zunächst eine direkte Verbindung und können bei schwierigen NAT-Konstellationen über einen Vermittlungsserver ausweichen. (Tailscale)

Wenn ich dagegen auf Drei 5G sitze und einfach jetzt einen funktionierenden VPN-Tunnel für mein Notebook oder Smartphone brauche, ist genau diese eingehende Erreichbarkeit meines Heimanschlusses irrelevant.

Das hat meine Fehlersuche am Ende umgedreht. Ein kommerzieller VPN, der funktioniert, obwohl der Heim-VPN ausfällt, ist kein merkwürdiger Sonderfall. Er ist ein Hinweis darauf, dass man zwei unterschiedliche Netzwerkwege testet.

Und für den akuten Moment war deshalb nicht die komplizierteste VPN-Konfiguration die nützlichste, sondern diejenige, die gar nicht erst darauf wartete, dass mein Heimanschluss von außen erreichbar wurde.