NAT-Probleme entstehen meist durch doppeltes NAT, CGNAT beim Provider, falsche Portweiterleitung oder blockierende Firewall-Regeln. Prüfen Sie zuerst, ob die WAN-Adresse des Routers eine öffentliche IP ist, deaktivieren Sie NAT auf einem der Geräte bei Kaskadierung und korrigieren Sie Portregeln samt Protokoll und interner Ziel-IP.
Symptome
- Online-Spielekonsolen melden dauerhaft „NAT-Typ streng
- Portweiterleitungen greifen nicht, obwohl im Router korrekt eingetragen
- VoIP-Verbindungen brechen nach wenigen Sekunden ab oder haben Einweg-Audio
- Externe Zugriffe auf VPN-, RDP- oder Webdienste laufen ins Leere
- tracert zeigt mehrere private Hops (10.x, 192.168.x), bevor eine öffentliche IP erscheint
Häufige Ursachen
Doppeltes NAT durch kaskadierte Router
Ein zweiter Router hinter dem Provider-Gerät führt eine zusätzliche Übersetzung durch. Eingehende Verbindungen enden am oberen Gerät und erreichen den internen Zielhost nicht.
Carrier-Grade NAT (CGNAT) beim Provider
Der ISP vergibt keine öffentliche IPv4 mehr, sondern teilt eine Adresse unter vielen Kunden. Portweiterleitung, VPN-Einwahl und viele P2P-Dienste funktionieren dadurch nicht.
Fehlerhafte Portweiterleitungsregel
Häufige Fehler sind falsches Protokoll (TCP statt UDP), abweichende interne Zielports, wechselnde DHCP-Adressen des Zielservers oder eine Regel, die auf dem falschen WAN-Interface aktiv ist.
Überlappende private Subnetze
Wenn LAN und WAN dasselbe Netz nutzen (z. B. beide 192.168.1.0/24), kann der Router den Rückweg nicht korrekt bestimmen. Die NAT-Tabelle findet keinen passenden Eintrag.
Firewall- oder ALG-Regeln blockieren Sessions
Restriktive Ausgangsfilter, aktives SIP-ALG oder aggressive Session-Timer verwerfen NAT-Einträge zu früh. VoIP und langlebige TCP-Verbindungen sind besonders betroffen.
Schritt-für-Schritt-Lösung
- WAN-Adresse mit tatsächlicher Internet-IP abgleichen
Öffnen Sie die Statusseite des Routers und notieren Sie die WAN-IP. Vergleichen Sie sie mit der auf einem externen Dienst angezeigten öffentlichen Adresse. Weichen beide ab oder liegt die WAN-IP im Bereich 100.64.0.0/10, arbeitet der Provider mit CGNAT. - Doppel-NAT per traceroute nachweisen
Führen Sie unter Windows tracert 8.8.8.8, unter Linux/macOS traceroute 8.8.8.8 aus. Erscheinen vor dem ersten öffentlichen Hop zwei oder mehr private IP-Adressen, existiert eine Router-Kaskade. Ein Gerät muss dann in den Bridge- oder AP-Modus wechseln. - Kaskade auflösen: Bridge-Mode oder DMZ
Am saubersten ist der Bridge-Mode am Provider-Router, sodass nur der zweite Router NAT und PPPoE übernimmt. Ist Bridging nicht möglich, tragen Sie die WAN-IP des Zweitrouters als exposed host bzw. DMZ im Provider-Gerät ein. - Feste interne IP für den Zieldienst vergeben
Weisen Sie dem Server, der Konsole oder dem NAS im DHCP-Server eine reservierte Adresse zu. Portweiterleitungen zeigen sonst nach einem Lease-Wechsel ins Leere. Prüfen Sie danach, ob der Dienst tatsächlich auf der erwarteten IP und dem erwarteten Port lauscht (netstat -an bzw. ss -tulpn). - Portweiterleitung korrekt anlegen und testen
Legen Sie die Regel mit richtigem Protokoll (TCP, UDP oder beide) an. Externer Port und interner Port dürfen abweichen, die interne Ziel-IP muss stimmen. Testen Sie von einem externen Netz aus, etwa per Mobilfunk, mit nmap -Pn -p <port> <öffentliche-IP> oder einem Portcheck-Dienst. - Firewall, ALG und Session-Timer prüfen
Deaktivieren Sie testweise SIP-ALG, wenn VoIP-Gespräche einseitig sind. Erhöhen Sie bei häufigen Verbindungsabbrüchen die UDP- und TCP-Session-Timeouts. Kontrollieren Sie zusätzlich Ausgangsregeln, die bestimmte Ports (z. B. 5060, 3478, 500/4500) blockieren könnten. - Kollidierende Subnetze umnummerieren
Nutzen WAN und LAN denselben Bereich, verschieben Sie das interne Netz auf ein weniger übliches Präfix wie 192.168.30.0/24 oder 10.20.0.0/24. Passen Sie DHCP-Bereich, statische Reservierungen und Firewall-Objekte entsprechend an. - CGNAT beim Provider adressieren
Wenn eine öffentliche IPv4 nicht verfügbar ist, fragen Sie den ISP nach einer öffentlichen Adresse (oft kostenpflichtig) oder nutzen Sie IPv6 für eingehende Dienste. Alternativ lassen sich Reverse-Tunnel über einen externen VPS oder Dienste wie WireGuard-Relays einsetzen.
Symptome, Ursachen und passende NAT-Korrekturen
| Symptom | Wahrscheinliche Ursache | Korrektur |
|---|---|---|
| Konsole meldet strengen NAT-Typ | Doppel-NAT oder blockierte UDP-Ports | Provider-Router in Bridge-Mode; UPnP oder feste Weiterleitungen setzen |
| Portweiterleitung nicht erreichbar | Falsches Protokoll oder DHCP-Wechsel | IP reservieren, Protokoll prüfen, extern testen |
| VoIP mit Einweg-Audio | SIP-ALG verändert Header | SIP-ALG deaktivieren, RTP-Ports weiterleiten |
| Öffentliche IP wirkt privat (100.64.x.x) | CGNAT beim Provider | Öffentliche IPv4 anfordern oder IPv6/Relay nutzen |
| Kein Zugriff auf LAN-Ressourcen nach Router-Tausch | Subnetz-Konflikt WAN/LAN | Internes Netz auf abweichendes Präfix umstellen |
| Verbindungen brechen nach kurzer Ruhephase ab | NAT-Session-Timeout zu niedrig | UDP/TCP-Timeouts erhöhen, Keepalive aktivieren |
So beugen Sie vor
- DHCP-Reservierungen für alle Hosts mit Portweiterleitung führen
- Nur einen Router NAT betreiben lassen, weitere Geräte als Access Point konfigurieren
- Portweiterleitungen und Firewall-Regeln in einer Änderungsdokumentation festhalten
- Regelmäßig von extern per Portscan prüfen, ob nur beabsichtigte Dienste erreichbar sind
Häufige Fragen
Woran erkenne ich verlässlich, ob mein Provider CGNAT einsetzt?
Vergleichen Sie die WAN-IP am Router mit der auf einem externen Dienst angezeigten öffentlichen Adresse. Weichen beide ab oder liegt die WAN-IP im reservierten Bereich 100.64.0.0/10, handelt es sich um CGNAT. Auch ein tracert zu einem externen Ziel, der zusätzliche private Hops zeigt, spricht dafür. Der Provider bestätigt dies auf Nachfrage meist direkt.
Ist UPnP eine sinnvolle Lösung für NAT-Probleme?
UPnP kann für Konsolen und Spiele-Clients kurzfristig helfen, weil Anwendungen selbst Ports öffnen. Für produktive Serverdienste ist es allerdings ungeeignet, da Regeln unkontrolliert entstehen und Sicherheitsrisiken bestehen. Nutzen Sie UPnP höchstens in getrennten Client-Netzen und definieren Sie kritische Weiterleitungen manuell mit festen internen Adressen.
Warum funktioniert meine Portweiterleitung intern, aber nicht extern?
Viele Router unterstützen kein NAT-Reflection (Hairpinning), sodass Tests aus dem eigenen LAN über die öffentliche IP scheitern, obwohl die Regel korrekt ist. Testen Sie immer aus einem fremden Netz, etwa per Mobilfunk oder externem Portcheck. Prüfen Sie zusätzlich, ob eine Host-Firewall am Zielserver den Port blockiert.
Lassen Sie Ihre NAT- und Firewall-Konfiguration von unserem Netzwerkteam prüfen und sauber dokumentieren.