Drei 5G: WireGuard VPN funktioniert nicht – warum ich am Ende nicht den Port repariert habe

WireGuard lief.

Zumindest behauptete mein Router das.

Interface aktiv.

Schlüssel geladen.

UDP-Port eingetragen.

Nur der Handshake kam nie.

Ich hatte meinen Internetanschluss zu Hause auf Drei 5G umgestellt und wollte etwas eigentlich Simples: Auf Reisen sollte mein Laptop eine WireGuard-Verbindung nach Hause aufbauen, damit ich in fremden WLANs nicht ungeschützt arbeiten musste.

Mit dem alten Anschluss hatte ich ähnliche Dinge schon eingerichtet. Deshalb begann ich dort, wo man bei WireGuard-Problemen fast automatisch beginnt.

Port prüfen.

Firewall prüfen.

Schlüssel neu erzeugen.

Router neu starten.

Noch einmal verbinden.

Nichts.

Am nächsten Morgen saß ich mit dem Laptop in einem Café, probierte es über das WLAN und danach über den Handy-Hotspot.

Immer derselbe Zustand.

Kein Handshake.

Irgendwann hörte ich auf, WireGuard zu reparieren, und stellte eine andere Frage:

Brauche ich wirklich einen von außen erreichbaren VPN-Server zu Hause – oder brauche ich einfach nur jetzt eine geschützte Verbindung?

Drei blockierte WireGuard offenbar nicht einfach grundsätzlich

Das war meine erste falsche Vermutung.

„Vielleicht blockiert Drei WireGuard.“

Die Erklärung wäre angenehm gewesen, weil sie das Problem aus meinem Router herausgeschoben hätte.

Nur passte sie nicht besonders gut zu den Fakten.

Drei veröffentlichte im April 2026 selbst eine Anleitung für VPN-Verbindungen am Router und nennt dabei ausdrücklich WireGuard und OpenVPN. Auch die aktuellen 5G- und Outdoor-Router werden dort als Geräte beschrieben, die VPN-Verbindungen auf Systemebene unterstützen können.

Eine pauschale WireGuard-Sperre wäre damit eine ziemlich schlechte Erklärung.

Der entscheidende Unterschied lag woanders:

Ich benutzte WireGuard nicht nur über meinen Drei-Anschluss.

Ich wollte einen WireGuard-Server hinter diesem Anschluss von außen erreichen.

Und das ist eine ganz andere Aufgabe.

Mein Port Forwarding endete am eigenen Router

Ich hatte UDP 51820 sauber weitergeleitet.

Auf dem Papier sah alles richtig aus.

Das Problem: Eine Weiterleitung auf meinem Router hilft nur bei Datenverkehr, der überhaupt dort ankommt.

Mobilfunknetze können öffentliche IPv4-Adressen zwischen mehreren Kunden teilen. Bei Carrier Grade NAT sitzt eine weitere Adressübersetzung im Netz des Providers. Die dafür reservierte „Shared Address Space“ ist nicht global routbar.

Für mich ließ sich das viel kürzer übersetzen:

Mein Router konnte keinen eingehenden Port öffnen, über den er außerhalb meines Anschlusses gar nicht selbst verfügte.

Damit erklärte sich auch der merkwürdige WireGuard-Zustand.

Der Server lief.

Der Port war lokal eingetragen.

Aber der Verbindungsversuch von draußen erreichte ihn nicht.

Und plötzlich wirkte es ziemlich sinnlos, zum fünften Mal denselben WireGuard-Schlüssel neu anzulegen.

Andere Drei-Nutzer waren an genau derselben Stelle gelandet

Ein öffentlicher Bericht passte fast unangenehm gut: Ein Drei-5G-Nutzer hatte WireGuard sowohl in Docker als auch über die VPN-Funktion seines Routers eingerichtet, bekam den Server von außen aber nicht erreichbar. In der Diskussion wurde auf CGNAT und die bei Drei bekannte Option „Open Internet“ beziehungsweise eine öffentliche IPv4 als Ausweg verwiesen.

Mehr brauchte ich aus dieser Diskussion nicht.

Sie bestätigte vor allem, dass „WireGuard läuft, aber niemand kommt hinein“ bei einem 5G-Heimanschluss eine andere Fehlerklasse ist als „WireGuard-Protokoll kaputt“.

Damit hatte ich zwei Möglichkeiten.

Ich konnte meinen Drei-Anschluss so umbauen, dass mein eigener Server von außen erreichbar wurde.

Oder ich konnte noch einmal überlegen, was ich eigentlich erreichen wollte.

Ich wollte gar keinen Server administrieren

Das war der etwas peinliche Teil.

Ich brauchte keinen Zugriff auf Home Assistant.

Keinen NAS.

Keine Kamera.

Keinen Rechner im Heimnetz.

Mein ursprünglicher Plan war viel banaler.

Wenn ich mit dem Laptop unterwegs war, wollte ich in einem Hotel, Café oder Coworking-Space eine verschlüsselte Verbindung einschalten und danach arbeiten.

Der WireGuard-Server zu Hause war nur das Mittel gewesen, das ich dafür gewählt hatte.

Und nun verbrachte ich mehr Zeit damit, dieses Mittel erreichbar zu machen, als mein eigentliches Problem wert war.

Natürlich hätte ich weitergehen können.

Öffentliche IPv4 organisieren.

Open Internet prüfen.

DynDNS einrichten, falls sich die Adresse ändert.

Firewall kontrollieren.

Danach WireGuard wieder testen.

Für einen Heimserver kann sich das absolut lohnen.

Für meine Aufgabe am Café-Tisch begann es sich eher nach Infrastrukturpflege anzufühlen.

Also ließ ich den Server vorerst in Ruhe.

Die zweite Verbindung brauchte meinen Drei-Router überhaupt nicht

Auf dem Laptop öffnete ich OnlydogVPN^↗.

Das änderte die Richtung der Verbindung.

Mein selbst gehostetes WireGuard brauchte einen Weg von draußen in meinen Drei-Anschluss hinein.

Die kleinere App musste diesen Eingang nicht öffnen. Sie baute die geschützte Verbindung vom Gerät selbst nach außen auf.

Das klingt nach einem kleinen Unterschied.

Auf einem Mobilfunkanschluss ist es ein ziemlich entscheidender.

Ich wählte die passende Nutzungssituation und verband.

Die Verbindung stand.

Browser geöffnet.

Arbeitsportal geladen.

Mail geöffnet.

Dann lud ich die Datei hoch, wegen der ich überhaupt im Café den Laptop aufgeklappt hatte.

Der Upload lief durch.

Kein Port Forwarding.

Kein DynDNS.

Keine öffentliche Adresse am Heimrouter.

Und vor allem kein weiterer Versuch, einen WireGuard-Hand­shake an einem Anschluss zu erzwingen, den ich für diese Aufgabe gar nicht mehr brauchte.

Erst jetzt wurde mir klar, dass ich zwei VPN-Probleme vermischt hatte

„VPN funktioniert nicht“ kann zwei völlig unterschiedliche Dinge bedeuten.

Variante eins:

Ich möchte in mein Heimnetz hinein.

Dann muss mein VPN-Server von außen erreichbar sein. CGNAT und öffentliche IP-Adressen werden wichtig.

Variante zwei:

Ich möchte von meinem aktuellen Gerät sicher ins Internet hinaus.

Dann kann die Verbindung vom Gerät selbst gestartet werden.

Mein Drei-Problem gehörte technisch zur ersten Variante.

Mein tatsächlicher Bedarf gehörte zur zweiten.

Sobald ich diese beiden Dinge getrennt hatte, wurde die Lösung erstaunlich kurz.

Ich musste WireGuard nicht besiegen.

Ich musste aufhören, für eine ausgehende Aufgabe eine eingehende Verbindung zu bauen.

Auch der APN war plötzlich leichter einzuordnen

Drei selbst bezeichnet den APN als den Zugangspunkt des Mobilfunkgeräts zum Internet und weist ausdrücklich darauf hin, dass die APN-Konfiguration auch bei VPN-Verbindungen relevant sein kann.

Vorher hätte mich das sofort wieder in ein Einstellungsmenü geschickt.

Welcher APN?

Welche IP?

Welches NAT?

Welcher Port?

Nach dem erfolgreichen Test war diese Information eher eine Erklärung dafür, warum zwei vermeintlich identische Internetanschlüsse unterschiedliche Bedingungen für einen selbst gehosteten Server schaffen können.

Die Standardkonfiguration meines Drei-Routers konnte für normales Surfen hervorragend funktionieren und trotzdem nicht die öffentliche Erreichbarkeit liefern, die mein WireGuard-Server brauchte.

Das eine widerspricht dem anderen nicht.

Und genau deshalb war die größere VPN-Frage für mich inzwischen entschieden.

Ich nahm danach noch das Telefon in die Hand

Der Laptop war geschützt.

Damit war meine eigentliche Aufgabe erledigt.

Dann fiel mir ein, warum ich den Heimserver ursprünglich attraktiv gefunden hatte: Ich wollte nicht für jedes Gerät wieder eine komplett neue Einrichtung.

Also öffnete ich die App auf dem Telefon.

Statt dort noch einmal ein klassisches Konto mit E-Mail-Adresse und Passwort einzurichten, konnte ich das zweite Gerät über einen Verifizierungscode verbinden.

Kurz danach lief auch dort die VPN.

Das war ein kleinerer Vorteil als die funktionierende Laptop-Verbindung.

Aber er beseitigte den letzten Grund, aus dem mir der selbst gehostete Server für diesen Zweck noch überlegen erschienen war.

Laptop und Telefon waren verbunden.

Mein Drei-Router durfte einfach wieder Router sein.

Die Technik dahinter musste nicht komplizierter werden

WireGuard verwendet UDP. OnlydogVPN setzt dagegen auf einen HTTP/3-basierten Transport und zusätzliche Verkehrsverschleierung.

Für meinen Fall war aber nicht der Protokollvergleich allein entscheidend.

Der größere Unterschied war die Architektur.

Der alte Aufbau wartete darauf, dass ein Gerät im Internet meinen Server hinter dem 5G-Anschluss erreicht.

Der neue Aufbau startete die Verbindung direkt von meinem Laptop.

Ich kann nicht beobachten, welche internen NAT-, Routing- oder Filterregeln Drei für jede einzelne Verbindung verwendet.

Das sichtbare Ergebnis reichte mir:

Der selbst gehostete Tunnel bekam von außen keinen Handshake.

Die Geräte-VPN verband sofort und ließ mich die Datei hochladen.

Damit wurde aus einem Netzwerkproblem wieder eine Anwendung.

Wenn ich wirklich ins Heimnetz müsste, würde ich anders entscheiden

Es gibt eine wichtige Grenze.

Wenn mein Ziel der Zugriff auf einen NAS, Home Assistant, eine Kamera oder einen Rechner zu Hause wäre, würde die kleinere VPN mein ursprüngliches WireGuard-Problem nicht ersetzen.

Dann brauche ich tatsächlich eine Lösung für die Erreichbarkeit des Heimnetzes — etwa eine passende öffentliche Adresse, eine von Drei unterstützte Anschlussoption oder eine andere Remote-Access-Architektur.

In diesem Fall lohnt sich die Fehlersuche.

Mein Ziel war aber ein anderes.

Ich wollte unterwegs geschützt arbeiten.

Dafür hatte ich aus Gewohnheit eine technisch aufwendigere Lösung gebaut, als die Aufgabe erforderte.

Und genau das machte den Unterschied zwischen den beiden Ansätzen so deutlich.

„WireGuard funktioniert nicht“ war am Ende die falsche Diagnose

WireGuard war nicht plötzlich unbrauchbar.

Auch Drei 5G war nicht grundsätzlich inkompatibel mit VPNs — Drei dokumentiert inzwischen selbst entsprechende Router-Konfigurationen.

Mein Fehler war, aus einem fehlenden Handshake sofort ein Protokollproblem zu machen.

Tatsächlich hatte ich einen von außen erreichbaren Server hinter einem Mobilfunkanschluss gebaut und mich gewundert, warum eine Portfreigabe auf meinem eigenen Router nicht die gesamte Provider-Infrastruktur kontrollierte.

Als ich zu meiner ursprünglichen Aufgabe zurückging, war der Vergleich viel einfacher.

Der selbst gehostete WireGuard-Tunnel verlangte, dass ich meinen Drei-Anschluss passend machte.

Die kleinere App verlangte nur, dass mein Laptop Internet hatte.

Für meinen Drei-5G-Anschluss war die bessere VPN-Lösung deshalb nicht die, mit der ich endlich einen eingehenden WireGuard-Port zum Leben erweckte – sondern die, bei der ich diesen Port für meine eigentliche Aufgabe gar nicht mehr brauchte.