Drei 5G Home Internet und Heim-VPN: Warum die Portfreigabe nicht das eigentliche Problem war

Der WireGuard-Server war eingerichtet. Schlüssel stimmten. Portweiterleitung stimmte. Zu Hause im WLAN konnte ich die Maschine erreichen. Dann schaltete ich am Telefon WLAN aus, ging über Mobilfunk und wartete auf den Handshake. Nichts.

Also änderte ich die Portfreigabe. Startete den Router neu. Kontrollierte die Firewall. Generierte sogar einen neuen Client.

Wieder nichts.

Das irritierte mich vor allem deshalb, weil mein Drei-5G-Anschluss ansonsten völlig gesund wirkte. Webseiten öffneten schnell, Videostreams liefen, der Speedtest sah gut aus.

Erst der Vergleich zweier IP-Adressen brachte mich auf die richtige Spur.

Mein Router kam ins Internet – das Internet aber nicht zu meinem Router

Ich verglich die WAN-Adresse im 5G-Router mit der öffentlichen IP, die mir eine externe Webseite anzeigte.

Sie waren nicht identisch.

Damit wurde plötzlich klar, warum die schönste Portfreigabe nichts brachte.

Mobilfunkanschlüsse können hinter einer NAT-Struktur des Providers liegen. Die österreichische RTR weist ausdrücklich darauf hin, dass Mobilfunkkunden häufig private Adressen hinter NAT erhalten. Wer dagegen einen eigenen Dienst aus dem Internet erreichbar machen möchte, braucht eine öffentliche IP-Adresse am Anschluss.

Das war mein Problem in einem Satz. Mein WireGuard-Server wartete korrekt hinter dem Router. Nur kam der Verbindungsversuch von draußen dort gar nicht an. Und damit hatte ich mehrere Stunden am falschen Ende der Verbindung gearbeitet.

Portfreigabe hilft erst, wenn der Router überhaupt erreichbar ist

Danach wurde meine Fehlersuche wesentlich kürzer. Eine Portfreigabe sagt dem Router nur: Wenn auf diesem Port etwas ankommt, leite es zu diesem Gerät weiter. Wenn die Verbindung schon im Providernetz endet, hat diese Regel nichts weiterzuleiten.

Deshalb würde ich bei einem nicht erreichbaren VPN-Server hinter Drei 5G heute nicht zuerst WireGuard neu installieren.

Ich würde zuerst prüfen:

Welche WAN-IP zeigt mein Router – und welche öffentliche IP sieht das Internet?

Passen beide nicht zusammen, würde ich die öffentliche Erreichbarkeit klären, bevor ich auch nur einen weiteren Schlüssel austausche.

Genau diese Sackgasse taucht auch bei anderen Drei-Nutzern auf: WireGuard und Portweiterleitung sehen korrekt aus, während die eigentliche Hürde erst bei der öffentlichen IPv4 sichtbar wird.

Das war für mich beruhigend – nicht weil das Problem dadurch kleiner wurde, sondern weil ich endlich wusste, welches Problem ich überhaupt lösen musste.

Bei Drei führte der Weg deshalb zuerst zur öffentlichen IPv4

Die RTR hält fest, dass österreichische Internetkunden auf Nachfrage Anspruch auf eine kostenlose dynamische öffentliche IPv4-Adresse haben; eine kostenlose feste Adresse ist dagegen nicht verpflichtend.

Für meinen Heim-VPN war die dynamische Variante völlig ausreichend.

Ich brauchte keine Business-Leitung und keine dauerhaft gleichbleibende Adresse.

Ich brauchte lediglich einen Anschluss, an dem eine eingehende Verbindung grundsätzlich bis zu meinem Router kommen konnte.

Nachdem das geklärt war, ergaben auch die nächsten Schritte wieder Sinn: Portfreigabe zum WireGuard-Server. DynDNS für die wechselnde Adresse. Client verbinden. Handshake. Zum ersten Mal kam er an. Das Heim-VPN funktionierte. Eigentlich hätte die Geschichte hier enden können. Tat sie aber nicht.

Denn während ich mich über den erfolgreichen Handshake freute, fiel mir auf, dass ich diesen ganzen Aufbau für zwei sehr unterschiedliche Aufgaben verwendete.

Für den Zugriff nach Hause war die Arbeit notwendig

Wenn ich auf mein NAS zugreifen wollte, brauchte ich den Heim-VPN.

Dasselbe galt für Home Assistant oder andere Geräte in meinem privaten Netz.

In diesen Fällen muss tatsächlich eine Verbindung zu meinem Zuhause entstehen. Dann sind öffentliche Erreichbarkeit, DynDNS und Routerkonfiguration keine überflüssigen Details, sondern Teil der Aufgabe.

Dafür würde ich meinen WireGuard-Server auch weiterhin betreiben. Nur benutzte ich denselben Server auf Reisen noch für etwas anderes: Hotel-WLAN absichern. Am Flughafen surfen. Im Café arbeiten.

Und dafür brauchte ich plötzlich einen zu Hause erreichbaren Router, DynDNS und einen laufenden VPN-Server, obwohl ich gar nicht nach Hause wollte.

Je länger ich darüber nachdachte, desto unnötiger wirkte das.

Für normales Reisen wollte ich mein Zuhause nicht mehr als Zwischenstation brauchen

Auf der nächsten Reise ließ ich den Heim-VPN deshalb bewusst in Ruhe. Wenn ich mein NAS brauchte, verband ich mich weiterhin nach Hause. Für normales Internet im Hotel öffnete ich stattdessen OnlydogVPN^↗. Situation auswählen. Verbinden. Browser öffnen. Fertig. Der Unterschied lag nicht in einer spektakulären Serverzahl. Er lag in der Richtung der Verbindung.

Mein Laptop baute den Tunnel selbst nach außen auf. Für diesen Zweck musste niemand aus dem Internet eine neue Verbindung zu meinem Drei-Router herstellen.

Damit verschwanden für diese Aufgabe auf einmal genau die Dinge, mit denen ich mich vorher so lange beschäftigt hatte:

keine Portfreigabe, kein DynDNS, keine öffentliche IPv4 am Heimanschluss, kein laufender WireGuard-Server zu Hause. Die App „reparierte“ also nicht meinen Drei-Anschluss. Sie machte ihn für diese Aufgabe schlicht irrelevant. Und genau das war nützlicher.

Ein Netzwechsel machte den Unterschied noch deutlicher

Im Hotel wurde das WLAN später instabil, also wechselte ich auf den Handy-Hotspot.

Die kleinere App stellte die Verbindung wieder her, ohne dass ich mich erneut durch Router- oder Client-Einstellungen arbeiten musste.

Sie ist auf schwache und wechselnde Netze ausgelegt – ein Szenario, das auf Reisen wesentlich häufiger vorkommt als in meinem Wohnzimmer.

Damit bekam mein Setup endlich eine klare Arbeitsteilung. Der Heim-VPN war für Zugriff auf mein Heimnetz da. Die kleinere App war für VPN unterwegs da. Das klingt fast banal. Für mich war es aber die wichtigere Erkenntnis als jede weitere Optimierung an WireGuard.

Was ich heute zuerst prüfen würde

Wenn ein VPN-Server hinter Drei 5G Home Internet trotz korrekter Portfreigabe nicht erreichbar ist, würde ich in dieser Reihenfolge vorgehen:

Zuerst WAN-IP und öffentliche IP vergleichen.

Dann klären, ob am Anschluss eine öffentliche dynamische IPv4 verfügbar ist. Die RTR bestätigt diesen Anspruch für österreichische Internetkunden.

Erst danach Portfreigabe und DynDNS prüfen.

Nicht umgekehrt.

Ich kann dabei nicht sehen, welche internen NAT- und Routingregeln Drei für jeden einzelnen Anschluss im Hintergrund anwendet. Entscheidend ist deshalb die von außen beobachtbare Frage: Erreicht eine neue Verbindung überhaupt meinen Router?

Wenn ja, lohnt sich die WireGuard-Fehlersuche.

Wenn nein, beginnt das Problem davor.

Am Ende brauchte ich zwei Lösungen statt einer komplizierten

OnlydogVPN hat weniger Standorte und eine kürzere öffentliche Historie als große VPN-Anbieter.

Für den Aufbau eines eigenen Heimzugangs ist das ohnehin nicht der relevante Vergleich – ein kommerzieller VPN ersetzt meinen WireGuard-Zugang zum NAS nicht.

Aber für den anderen Teil meines Alltags war die kleinere App überzeugender. Ich musste meinen Heimanschluss nicht mehr für jede Hotelsitzung erreichbar halten. Kein Router zu Hause musste mitspielen. Kein DynDNS musste stimmen. Ich brauchte nur die Verbindung auf dem Gerät vor mir.

Der größte Fehler bei meinem Drei-5G-Heim-VPN war deshalb nicht eine falsche WireGuard-Einstellung.

Es war die Annahme, dass jede VPN-Aufgabe denselben Weg durch mein Zuhause nehmen müsse. Den Heimserver habe ich behalten. Aber nur noch für die Aufgabe, für die seine öffentliche Erreichbarkeit wirklich zählt: wenn ich tatsächlich nach Hause will.