Wenn ein Port trotz Freigabe geschlossen ist, prüfst du zuerst, ob am Zielgerät überhaupt ein Dienst auf dem Port „lauscht“, testest dann sauber von außen (nicht aus dem eigenen WLAN), und arbeitest dich anschließend systematisch durch Router-NAT, Firewall-Regeln, Provider-Einschränkungen und Spezialfälle wie CGNAT, Doppel-NAT oder IPv6. In sehr vielen Fällen ist der Port nicht „wirklich“ blockiert, sondern die Weiterleitung zeigt auf die falsche interne IP, das Protokoll ist falsch gewählt oder der Portchecker meldet „geschlossen“, weil am Ziel nichts aktiv ist.
Was „Port geschlossen“ in Tools wirklich bedeutet
Ein Port gilt für externe Scanner nur dann als „offen“, wenn am Ende der Kette ein Dienst erreichbar ist, der auf genau diesem Port antwortet. Eine Portfreigabe im Router allein öffnet nichts „magisch“. Sie sagt nur: Wenn ein Paket von außen auf Port X ankommt, leite es an Gerät Y weiter. Wenn Gerät Y dort nicht zuhört oder die Firewall das Paket verwirft, bleibt der Port aus Sicht des Internets geschlossen.
Typische Interpretationen:
- „Closed“: Das Ziel antwortet aktiv mit „hier ist nichts“ (häufig, wenn kein Dienst läuft oder ein System den Port bewusst ablehnt).
- „Filtered“ oder „Timeout“: Etwas blockiert oder verwirft Pakete still (Firewall, Provider-Filter, falsches Routing, CGNAT).
- „Open“: Ein Dienst antwortet und ist erreichbar.
Wichtig: Viele Portchecker testen nur TCP. Wenn du UDP freigegeben hast (bei manchen Spielen, VoIP oder speziellen Protokollen), kann ein TCP-Portcheck trotzdem „geschlossen“ anzeigen, obwohl UDP grundsätzlich funktioniert.
Der häufigste Grund: Am Zielgerät läuft kein Dienst auf dem Port
Das klingt banal, ist aber der Klassiker Nummer 1 bei „Port trotz Freigabe geschlossen“. Ein Router kann nur weiterleiten, was am Ziel auch angenommen wird. Wenn du zum Beispiel eine Software installiert hast, die nur lokal lauscht (127.0.0.1) oder gar nicht gestartet ist, bleibt der Port von außen tot.
Schnelle Plausibilitätsprüfung:
- Ist der Dienst gestartet und läuft dauerhaft?
- Lauscht er auf der richtigen Netzwerkschnittstelle (nicht nur „lokal“)?
- Ist die Portnummer exakt richtig (kein Tippfehler, kein anderer Port in der App)?
- Wird TCP oder UDP verwendet, oder beides?
Auf Windows kannst du grob prüfen, ob ein Port „LISTENING“ ist:
netstat -ano | findstr :PORT
Auf Linux:
ss -tulpen | grep PORT
Wenn hier nichts auftaucht, ist der Port von außen praktisch nie erreichbar, egal wie perfekt die Freigabe ist.
Zweithäufigster Grund: Du testest aus dem eigenen Netz und das verfälscht alles
Viele Router unterstützen kein NAT-Loopback (auch Hairpin NAT genannt) oder nur teilweise. Dann kann es passieren, dass ein Zugriff auf die eigene öffentliche IP aus dem Heimnetz nicht funktioniert, obwohl der Port von außen erreichbar wäre. Umgekehrt kann ein Test aus dem Heimnetz „zufällig“ funktionieren, obwohl es von außen nicht geht, weil intern andere Wege genutzt werden.
Die saubere Regel ist:
- Teste „von außen“ über Mobilfunk oder ein fremdes WLAN.
- Vermeide Tests aus dem eigenen WLAN, wenn du die öffentliche Adresse nutzt.
- Wenn du im Heimnetz testen willst, nutze die interne IP des Zielgeräts.
Bei Smartphones ist es simpel: WLAN ausschalten, nur Mobilfunk nutzen, dann testen. So weißt du, dass du wirklich von außerhalb kommst.
Falsches Protokoll: TCP freigegeben, aber UDP gebraucht (oder umgekehrt)
Router trennen Portfreigaben meist nach Protokoll. Viele Anwendungen nutzen:
- nur TCP (z. B. Webdienste)
- nur UDP (z. B. manche Spiele, Voice, spezielle Tunnel)
- TCP und UDP parallel
Wenn du nur TCP freigibst, aber der Dienst UDP nutzt, wird ein TCP-Portchecker „geschlossen“ melden, und in der App klappt es trotzdem nicht. Umgekehrt gilt das genauso.
Guter Praxisansatz:
- In der Anwendung nachsehen, welches Protokoll wirklich genutzt wird.
- Wenn unklar, testweise TCP und UDP freigeben, aber nur für den final notwendigen Port und nicht als Dauerlösung für große Bereiche.
Portweiterleitung zeigt auf die falsche interne IP
Geräte bekommen im Heimnetz häufig neue IP-Adressen, etwa nach einem Neustart oder wenn DHCP-Leases wechseln. Dann zeigt deine Freigabe weiterhin auf die alte IP und läuft ins Leere. Von außen sieht das aus wie „geschlossen“.
Woran du das erkennst:
- Die Freigabe war früher mal funktionierend.
- Nach Router-Neustart oder Gerätewechsel geht plötzlich nichts mehr.
- Im Router steht eine interne IP, die das Zielgerät nicht mehr hat.
So stabilisierst du das:
- Vergib dem Zielgerät eine feste Zuordnung im Router (DHCP-Reservierung).
- Achte darauf, dass keine zweite Stelle im Heimnetz ebenfalls DHCP macht (Repeater im Routermodus, zweiter Router, falsch konfiguriertes Mesh). Zwei DHCP-Server sind ein Garant für Chaos.
Wenn du mehrere Router im Einsatz hast, steigt die Wahrscheinlichkeit deutlich, dass du an der falschen Stelle weiterleitest oder das Zielgerät in einem anderen Subnetz steckt.
Firewall am Zielgerät blockiert die eingehende Verbindung
Selbst wenn der Dienst läuft und der Router korrekt weiterleitet, kann die lokale Firewall alles abräumen. Das ist besonders oft bei Windows der Fall, weil dort Regeln nach Profilen (privat, öffentlich, Domäne) greifen. Wenn dein Netzwerkprofil „öffentlich“ ist, kann Windows deutlich strenger sein.
Was du prüfen solltest:
- Gibt es eine eingehende Regel für den Port und das korrekte Protokoll?
- Gilt die Regel für das richtige Profil (privat/öffentlich)?
- Greift eine Security-Suite zusätzlich zur Windows-Firewall?
- Lauscht der Dienst vielleicht, aber nur lokale Verbindungen sind erlaubt?
Bei Linux ist es häufig eine Kombination aus iptables/nftables und einer Anwendungskonfiguration. Bei macOS spielt die Anwendungsfirewall eine Rolle, manchmal auch zusätzliche Schutzsoftware.
Ein sehr typischer Stolperstein: Die Anwendung ist „offen“, aber nur für lokale Subnetze. Externe Verbindungen werden verworfen, obwohl der Port technisch erreichbar wäre.
Der Router blockiert selbst oder eine Schutzfunktion greift
Einige Router haben zusätzliche Sicherheitsfunktionen, die eingehenden Verkehr trotz Freigabe blockieren können, z. B.:
- „Port-Schutz“ oder „Stealth Mode“
- Intrusion-Prevention, DoS-Protection zu aggressiv eingestellt
- Kindersicherung oder Zugangsprofile, die eingehende Verbindungen sperren
- Gastnetz- oder Isolationsfunktionen, die das Zielgerät vom restlichen Netz trennen
Wenn du mit Gastnetz, VLANs oder separaten WLANs arbeitest: Achte darauf, dass das Zielgerät wirklich im Netz hängt, auf das die Freigabe zeigt. Ein NAS im isolierten Segment ist intern oft erreichbar, aber eingehender Verkehr wird trotzdem geblockt, weil Routing- oder Firewallregeln zwischen den Netzen fehlen.
Doppel-NAT: Du leitest am falschen Gerät weiter
Doppel-NAT ist einer der häufigsten Gründe, warum Portfreigaben „perfekt“ aussehen, aber nie funktionieren. Das passiert, wenn du zwei Geräte hintereinander hast, die beide routen:
- Anbieterrouter plus eigener Router dahinter
- Kabelmodem/Glasfaserbox mit Routerfunktion plus zusätzlicher Router
- LTE/5G-Router plus zusätzliches WLAN-Router-Setup
Dann gibt es zwei NAT-Grenzen. Eine Portfreigabe im inneren Router reicht nicht, weil der äußere Router die Anfrage nie bis dahin durchreicht.
Typische Anzeichen:
- Dein Router hat als WAN-IP eine private Adresse wie 192.168.x.x oder 10.x.x.x.
- Alles im Heimnetz funktioniert, aber von außen geht gar nichts.
- Der Anbieterrouter verwaltet „das Internet“, dein eigener Router ist nur dahinter.
Die saubere Lösung:
- Entweder den Anbieterrouter in den Bridge-Modus setzen (wenn verfügbar).
- Oder deinen Router in den IP-Client-/Access-Point-Modus setzen, sodass nur ein Router NAT macht.
- Oder Portfreigaben auf beiden Geräten korrekt hintereinander setzen (funktioniert, ist aber fehleranfällig und nicht ideal).
Wenn du nicht sicher bist, ob Doppel-NAT vorliegt, reicht oft ein Blick auf die WAN-IP deines Routers. Ist die WAN-IP privat, bist du nicht direkt im Internet.
CGNAT und DS-Lite: Du hast gar keine echte öffentliche IPv4
Selbst ohne Doppel-NAT kann es sein, dass du gar keine echte öffentliche IPv4 bekommst. Bei vielen Anschlüssen läuft die IPv4-Anbindung über Carrier-Grade NAT (CGNAT). Typisch ist auch DS-Lite, bei dem IPv6 „echt“ öffentlich ist, IPv4 aber über einen Provider-Tunnel läuft.
Ergebnis: Klassische Portweiterleitungen für IPv4 funktionieren dann nicht, weil der Provider selbst NAT macht und keine Ports zu dir mappt. Von außen bleibt der Port geschlossen, egal was du im Router einstellst.
Ein starkes Indiz ist, wenn deine Router-WAN-IP in einem speziellen Bereich liegt, der nicht öffentlich ist. Ein häufiger CGNAT-Bereich ist 100.64.0.0/10. Wenn du so eine WAN-IP siehst, ist Portweiterleitung über IPv4 praktisch tot, solange der Provider nichts daran ändert.
Was du dann tun kannst:
- Prüfen, ob du über IPv6 von außen arbeiten kannst (viele Dienste können das, manche nicht).
- Beim Anbieter eine echte öffentliche IPv4 buchen, falls möglich (manchmal gegen Aufpreis).
- Alternativ statt Portweiterleitung einen sicheren Zugang über VPN nutzen, der von innen nach außen aufgebaut wird. Damit umgehst du das Port-Problem, weil die Verbindung initiiert wird und nicht eingehend sein muss.
Wenn du „Port trotz Freigabe geschlossen“ hast und wirklich alles andere passt, ist CGNAT einer der wichtigsten Punkte auf der Checkliste.
IPv6 ist aktiv, aber du leitest nur IPv4 weiter
Viele denken bei Portfreigaben ausschließlich an IPv4. In modernen Netzen greifen Geräte aber oft bevorzugt IPv6. Dann passiert Folgendes:
- Deine Tests laufen über IPv6, weil dein Mobilfunknetz oder dein Zielgerät IPv6 bevorzugt.
- Du hast aber nur IPv4-Portfreigaben eingerichtet.
- Ergebnis: Der Test „von außen“ sieht nichts von deiner IPv4-Weiterleitung, weil er gar nicht über IPv4 kommt.
Zusätzlich gibt es bei IPv6 kein NAT im klassischen Sinne. Stattdessen brauchst du eine Firewall-Freigabe für eingehenden Verkehr zu einem internen IPv6-Ziel. Manche Router nennen das trotzdem „Freigabe“, technisch ist es aber eine Firewall-Regel.
Praxisregel:
- Prüfe, ob dein externes Testgerät IPv6 nutzt.
- Wenn ja, stelle sicher, dass du auch IPv6-seitig eine passende Freigabe/Firewallregel hast oder bewusst IPv6 für den Test deaktivierst, um IPv4 sauber zu prüfen.
- Achte darauf, dass dein Zielgerät überhaupt eine stabile IPv6-Adresse hat (oder ein korrektes Präfix und eine passende Regel).
Der externe Port ist nicht gleich dem internen Port
Viele Router erlauben „Port extern 12345 auf intern 8080“. Das ist grundsätzlich okay, führt aber zu Fehlern, wenn:
- du im Test den internen Port prüfst, statt den externen
- die Anwendung intern wirklich nur 8080 nutzt, du aber extern 8080 testest, obwohl du 12345 gesetzt hast
- du mehrere Regeln hast, die sich überschneiden
Wenn du eine Abbildung nutzt, notiere dir einmal sauber: Welcher Port kommt von außen rein und wohin geht er intern. In komplexeren Setups mit mehreren Diensten ist das eine der häufigsten Verwechslungen.
Port bereits belegt oder Router kann ihn nicht weiterleiten
Manche Ports sind am Router selbst durch Dienste belegt oder werden intern reserviert. Auch kann es vorkommen, dass ein Port im Zielnetz bereits von einem anderen Dienst genutzt wird, sodass dein eigentlicher Dienst nicht starten kann. Dann läuft die App zwar „irgendwie“, aber nicht auf dem erwarteten Port.
Beispiele für typische Konflikte:
- Verwaltungsoberfläche nutzt bereits 80/443 oder spezielle Ports
- Fernwartungsdienste des Routers blocken Ports
- Eine alte Software-Instanz lauscht noch auf dem Port
- Container-Setups leiten Ports falsch durch (Host-Port vs Container-Port)
Der saubere Weg ist wieder: Prüfen, ob wirklich genau dein Dienst auf dem Port lauscht. Nicht „irgendein Prozess“, sondern der richtige.
UPnP und automatische Regeln funken dazwischen
UPnP kann automatisch Portfreigaben erstellen, oft für Konsolen, Spiele oder Kommunikationssoftware. Das kann gut funktionieren, aber es kann auch manuelle Regeln überlagern oder Konflikte erzeugen:
- Zwei Regeln beanspruchen denselben externen Port.
- UPnP zeigt auf ein anderes Gerät als deine manuelle Regel.
- UPnP erzeugt kurzfristige Regeln, die verschwinden und später anders wiederkommen.
Wenn du sauber arbeiten willst, ist ein klarer Zustand besser:
- Entweder UPnP bewusst nutzen und manuelle Regeln sparsam halten.
- Oder UPnP deaktivieren und alles gezielt manuell einrichten.
Gerade bei „Port trotz Freigabe geschlossen“ lohnt es sich, UPnP testweise auszuschalten, um Konflikte auszuschließen.
Portchecker irrt, weil der Dienst nur unter bestimmten Bedingungen antwortet
Einige Dienste reagieren nicht wie ein typischer Server. Sie antworten nur, wenn sie ein „richtiges“ Protokollpaket bekommen, nicht auf jeden TCP-Connect. Dann kann ein Portchecker „geschlossen“ melden, obwohl die Anwendung in ihrem eigenen Protokoll durchaus erreichbar wäre.
Das gilt besonders bei:
- einigen Game-Servern
- speziellen IoT-Gateways
- Diensten, die IP-Whitelisting oder Authentifizierung früh erzwingen
- UDP-basierten Anwendungen, die auf TCP-Checks nicht reagieren
Die bessere Prüfung ist dann: Teste mit einem echten Client, der das Protokoll spricht, oder nutze ein Tool, das wirklich den passenden Verkehr erzeugt.
Externe Tests scheitern, weil du im selben Netz bist oder weil dein Mobilfunk filtert
Manche Mobilfunkanbieter filtern eingehenden oder ungewöhnlichen ausgehenden Verkehr. Außerdem kann es passieren, dass du im gleichen Netzsegment testest (z. B. Firmen-VPN, Hotelnetz mit Einschränkungen). Dadurch wirken Ports „geschlossen“, obwohl es ein Testumfeldproblem ist.
Wenn du ein sauberes Bild willst:
- Teste einmal über Mobilfunk.
- Teste einmal über ein fremdes WLAN.
- Wenn beides unterschiedlich ist, liegt es sehr wahrscheinlich nicht an deiner Freigabe, sondern am Weg dazwischen.
Sicherheit: Port öffnen ist kein Selbstläufer
Bei aller Fehlersuche solltest du den Sicherheitsaspekt nicht aus dem Blick verlieren. Ein offener Port ist eine Einladung für Scans und automatisierte Angriffe. Das heißt nicht, dass du nie Ports öffnen darfst, aber es heißt:
- Öffne nur, was du wirklich brauchst.
- Nutze möglichst ungewöhnliche externe Ports nur dann, wenn es Sinn ergibt, und nicht als „Sicherheitsmaßnahme“ allein.
- Schütze den Dienst am Ziel zusätzlich (starke Authentifizierung, Updates, Zugriffsbeschränkungen).
- Überlege bei sensiblen Diensten lieber einen VPN-Zugang statt direkter Freigaben.
Gerade bei NAS, Remote-Desktop oder Verwaltungsoberflächen kann ein falsch offener Port schwerwiegende Folgen haben.
Eine bewährte Vorgehensweise, die Fehler schnell sichtbar macht
Wenn ein Port trotz Freigabe geschlossen wirkt, hilft ein Ablauf, der die Ursache zügig eingrenzt, ohne alles gleichzeitig zu ändern.
- Starte den Dienst am Zielgerät neu und prüfe lokal, ob er wirklich auf dem Port lauscht.
- Greife im Heimnetz auf den Dienst zu, aber über die interne IP, nicht über die öffentliche Adresse.
- Prüfe, ob die interne IP des Zielgeräts stabil ist und zur Weiterleitung passt.
- Kontrolliere im Router: Protokoll (TCP/UDP), externer Port, interner Port, Ziel-IP.
- Teste von außen über Mobilfunk oder fremdes WLAN.
- Wenn weiterhin „geschlossen“: Prüfe WAN-IP am Router. Ist sie öffentlich oder privat? Das entscheidet über Doppel-NAT/CGNAT.
- Wenn WAN-IP privat oder CGNAT: Portweiterleitung über IPv4 ist sehr wahrscheinlich nicht möglich, dann musst du den Zugang anders lösen.
- Wenn WAN-IP öffentlich: Fokus auf Firewall am Zielgerät und Router-Schutzfunktionen, außerdem IPv6-Parallelwelt prüfen.
Dieser Ablauf wirkt unspektakulär, spart aber enorm viel Zeit, weil du nicht im Kreis läufst.
Spezialfälle, die oft übersehen werden
Port ist nur intern offen, weil der Dienst an „localhost“ gebunden ist
Einige Anwendungen lauschen standardmäßig nur auf 127.0.0.1. Dann funktioniert es auf dem Gerät selbst, aber nicht im LAN und erst recht nicht von außen. In der App-Konfiguration muss dann die Bind-Adresse auf die LAN-IP oder auf „alle Interfaces“ geändert werden.
Zielgerät hängt im Gastnetz oder hinter einem zweiten Router
Wenn das Zielgerät in einem isolierten WLAN hängt oder hinter einem zusätzlichen Router, kannst du weiterleiten, bis du blau wirst. Der Verkehr landet entweder im falschen Segment oder wird zwischen Segmenten nicht geroutet.
Provider blockiert bestimmte Ports
Einige Anbieter blocken eingehend (und manchmal auch ausgehend) bestimmte Ports, vor allem klassische Mail-Ports oder Ports, die häufig missbraucht werden. Dann sieht es aus wie „geschlossen“, obwohl dein Setup stimmt. Wenn du so einen Port brauchst, hilft manchmal ein anderer externer Port mit interner Umleitung, oder ein anderer Dienstweg.
NAT-Typen und Symmetric NAT bei Spezialanschlüssen
Bei manchen Anschlüssen oder vorgeschalteten Geräten ist NAT so restriktiv, dass eingehende Verbindungen ohne explizite Provider-Unterstützung nicht funktionieren. Das ist selten im klassischen DSL-Heimnetz, aber häufiger bei LTE/5G oder bestimmten Campusnetzen.
Praxisbeispiele
Praxisbeispiel 1: Heimserver weitergeleitet, Portchecker sagt „geschlossen“
Ein kleiner Heimserver sollte von außen erreichbar sein. Die Freigabe war im Router eingerichtet, aber jeder Test meldete „closed“. Der Grund war schlicht: Der Dienst lief nicht mehr, weil ein Update die Konfiguration zurückgesetzt hatte und der Prozess nicht startete. Nachdem der Dienst wieder korrekt lauschte und die Windows-Firewall-Regel für das private Profil aktiv war, wurde der Port sofort als offen erkannt.
Praxisbeispiel 2: Alles richtig, aber Anschluss hat CGNAT
Bei einem Anschluss wurde eine Portfreigabe eingerichtet, Zielgerät und Firewall waren sauber. Trotzdem blieb der Port ausnahmslos geschlossen. Im Router stand als WAN-IP eine Adresse aus 100.64.x.x. Damit war klar: keine öffentliche IPv4, also keine echte eingehende Erreichbarkeit per IPv4-Portweiterleitung. Die Lösung war ein Zugang, der von innen nach außen eine Verbindung aufbaut, statt auf eingehende Ports zu setzen.
Praxisbeispiel 3: Doppel-NAT durch Anbieterrouter plus eigener Router
Ein Nutzer hatte einen Anbieterrouter und dahinter einen eigenen Router. Die Portfreigabe wurde nur im eigenen Router gesetzt. Von außen kam aber nichts an, weil der Anbieterrouter nicht weiterleitete. Erst nachdem der Anbieterrouter in einen Modus gesetzt wurde, bei dem nur ein Gerät NAT macht, funktionierte die Freigabe stabil.
Zusammenfassung
Wenn ein Port trotz Freigabe geschlossen wirkt, liegt es meistens nicht an „einer geheimen Sperre“, sondern an einer klaren Ursache: Kein Dienst lauscht, falsches Protokoll, falsche Ziel-IP, lokale Firewall blockt, Test findet aus dem Heimnetz statt, Doppel-NAT oder CGNAT verhindert eingehende IPv4-Verbindungen, oder IPv6 wird übersehen. Sobald du diese Punkte in einer sauberen Reihenfolge prüfst, verschwindet das Bauchgefühl „alles ist richtig, aber es geht trotzdem nicht“ und du bekommst ein eindeutiges Ergebnis, an welcher Stelle die Kette reißt.
Fazit
Portfreigaben sind technisch simpel, aber in der Realität treffen sie auf viele Schichten: Anwendung, Betriebssystem, Router, Provider und manchmal mehrere Netze gleichzeitig. Genau deshalb fühlt sich die Fehlersuche so oft widersprüchlich an. Wenn du zuerst sicherstellst, dass der Dienst wirklich erreichbar ist, dann korrekt von außen testest und anschließend NAT und Anschlussart (öffentlich, Doppel-NAT, CGNAT) prüfst, findest du die Ursache fast immer schnell. Und wenn sich herausstellt, dass dein Anschluss keine eingehenden IPv4-Ports zulässt, ist das kein „Fehler“, sondern eine Rahmenbedingung, die du mit einem anderen Zugangskonzept umgehen musst.
Häufige Fragen zum Thema
Warum zeigt der Router eine Freigabe, aber der Port ist trotzdem geschlossen?
Die Freigabe leitet nur weiter, sie öffnet keinen Dienst. Wenn am Zielgerät nichts auf dem Port lauscht oder die Firewall blockiert, bleibt der Port aus externer Sicht geschlossen. Häufig ist auch die interne IP nicht mehr aktuell, weil sich die Adresse per DHCP geändert hat.
Muss der Dienst dauerhaft laufen, damit ein Port als offen gilt?
Ja, bei den meisten Tests muss der Dienst zum Zeitpunkt des Scans aktiv antworten können. Wenn der Dienst nur bei Bedarf startet oder nach einem Update nicht mehr läuft, wirkt der Port sofort geschlossen. Das ist besonders typisch bei Heimservern, Containern oder Anwendungen, die im Autostart fehlen.
Warum sagt ein Portchecker „geschlossen“, obwohl die App funktioniert?
Viele Portchecker testen nur TCP und können UDP nicht zuverlässig bewerten. Wenn deine Anwendung UDP nutzt oder nur auf „gültige“ Protokollpakete reagiert, kann ein generischer Scanner falsch negativ melden. Dann ist ein Test mit einem echten Client oft aussagekräftiger.
Wieso funktioniert der Test im Heimnetz nicht, obwohl es von außen gehen müsste?
Das liegt oft an fehlendem NAT-Loopback im Router. Dann kannst du aus dem eigenen WLAN nicht über die öffentliche Adresse zurück ins Heimnetz. Ein Test über Mobilfunk oder ein fremdes WLAN liefert ein deutlich verlässlicheres Ergebnis.
Was ist Doppel-NAT und warum verhindert es Portfreigaben?
Doppel-NAT bedeutet, dass zwei Router hintereinander NAT machen. Eine Portfreigabe im inneren Router reicht dann nicht, weil der äußere Router die Anfrage nicht weitergibt. Du brauchst entweder nur ein NAT-Gerät oder passende Einstellungen auf beiden Geräten, damit der Verkehr wirklich bis zum Ziel kommt.
Wie erkenne ich, ob CGNAT oder DS-Lite der Grund ist?
Ein starkes Indiz ist eine private WAN-IP am Router, oft auch aus dem Bereich 100.64.0.0/10. In solchen Fällen hast du keine echte öffentliche IPv4 und eingehende Portweiterleitungen funktionieren nicht zuverlässig oder gar nicht. Dann ist ein Zugang über IPv6 oder ein von innen initiierter Tunnel meist der bessere Weg.
Kann die Windows-Firewall allein den Port „geschlossen“ machen?
Ja, sehr häufig. Selbst wenn der Dienst lauscht, kann Windows eingehenden Verkehr je nach Netzwerkprofil blockieren. Eine Regel, die nur im privaten Profil gilt, hilft nicht, wenn dein Netzwerk als öffentlich erkannt wurde.
Warum ist die interne Ziel-IP so wichtig?
Die Portfreigabe zeigt immer auf eine bestimmte interne IP. Wenn das Zielgerät eine neue IP erhält oder du versehentlich auf das falsche Gerät weiterleitest, kommt der Verkehr nicht beim richtigen Dienst an. Eine DHCP-Reservierung im Router verhindert solche „stillen“ Umleitungen.
Welche Rolle spielt IPv6 bei Portfreigaben?
Bei IPv6 gibt es meist kein klassisches NAT, sondern Firewall-Freigaben. Wenn dein Testgerät über IPv6 verbindet, aber du nur IPv4-Freigaben gesetzt hast, wirkt der Port geschlossen. Dann musst du IPv6-seitig die passende Regel setzen oder den Test bewusst über IPv4 erzwingen.
Ist es sicher, einfach beliebige Ports zu öffnen, bis es klappt?
Das ist keine gute Idee, weil jeder offene Port zusätzliche Angriffsfläche schafft. Besser ist, den benötigten Port gezielt zu öffnen und den Dienst am Ziel zu härten, etwa durch Updates, starke Authentifizierung und restriktive Regeln. Für sensible Zugriffe ist ein VPN oft die sicherere Alternative.
Warum blockt mein Anbieter manche Ports?
Manche Provider sperren Ports, die häufig für Missbrauch verwendet werden oder bestimmte Dienste betreffen. Dann bleibt der Port trotz Freigabe von außen zu, weil die Pakete schon vorher gefiltert werden. In solchen Fällen hilft oft ein anderer externer Port oder ein anderes Zugangskonzept, das nicht auf eingehenden Ports basiert.
