NAT Troubleshooting: Wenn Internet nicht funktioniert

Wenn das Internet „plötzlich nicht mehr funktioniert“, ist NAT in Cisco-Umgebungen oft der erste Verdächtige – und zugleich einer der häufigsten Bereiche, in denen kleine Konfigurationsfehler große Auswirkungen haben. Genau deshalb ist NAT Troubleshooting ein fester Bestandteil der täglichen Netzwerkarbeit: Clients bekommen zwar eine IP-Adresse, können interne Systeme erreichen, aber Webseiten laden nicht, VPNs brechen ab, Updates scheitern oder bestimmte Anwendungen funktionieren nur sporadisch. In den meisten Fällen ist NAT selbst nicht „kaputt“, sondern die Übersetzung greift nicht, greift auf dem falschen Interface, matcht nicht die richtigen Quellen oder scheitert an Routing, ACLs, DNS oder Rückwegen. Besonders tückisch: NAT-Probleme sehen aus Sicht der Nutzer identisch aus – egal ob die Default Route fehlt, die NAT-ACL falsch ist, ein WAN-Interface down ist oder ein Provider die Rückroute nicht mehr liefert. Dieses Troubleshooting-Playbook führt Sie systematisch durch die häufigsten Fehlerquellen, zeigt Ihnen die entscheidenden Cisco-Show-Befehle, erklärt typische Symptome und liefert konkrete Fixes. Ziel ist, dass Sie innerhalb weniger Minuten feststellen können, ob das Problem bei Layer 1/2, Routing, NAT-Regeln, Access-Listen, DNS oder beim Upstream liegt – und dass Sie Änderungen so durchführen, dass der Betrieb stabil bleibt.

Grundlage: Was muss bei NAT grundsätzlich stimmen?

Bevor Sie in Details gehen, lohnt sich ein kurzer Realitätscheck: NAT ist nur eine Übersetzungsfunktion. Damit Internetzugang funktioniert, braucht es zusätzlich eine funktionierende Layer-3-Konnektivität nach außen und einen plausiblen Rückweg. In klassischen Cisco-Setups sind die Minimalanforderungen:

• Inside/Outside korrekt gesetzt: ip nat inside auf LAN-Interface, ip nat outside auf WAN-Interface.
• NAT-Regel existiert: PAT (Overload) oder Dynamic/Static NAT passend zum Use Case.
• NAT-ACL matcht den Traffic: Die definierte Quelladresse muss wirklich getroffen werden.
• Default Route nach außen: Router kennt den Upstream (meist ip route 0.0.0.0 0.0.0.0 <ISP-GW>).
• Rückweg stabil: Antworten kommen wieder an (Provider-Routing, Firewall-State, kein asymmetrischer Pfad).

Als Cisco-Referenz für NAT-Szenarien ist der Anchor-Text Cisco NAT Konfigurationsbeispiele hilfreich, insbesondere wenn Sie plattformspezifische Varianten vergleichen möchten.

Die wichtigste Diagnose-Regel: Erst Routing, dann NAT

Ein häufiger Fehler im Troubleshooting ist, sofort an NAT-Regeln zu drehen, obwohl das Problem in Wirklichkeit eine fehlende Default Route oder ein Down-Link ist. NAT kann Übersetzungen erzeugen, aber wenn der Router das Paket anschließend nicht ins Internet routen kann, ist der Effekt für den Nutzer identisch: „kein Internet“.

• Wenn der Router selbst keine externen Ziele erreicht, ist NAT nicht der primäre Fehler.
• Wenn der Router extern erreichbar ist, aber Clients nicht, ist NAT/ACL/Inside/Outside sehr wahrscheinlich.

Schnellstart: 10-Minuten-Checkliste für „Internet geht nicht“

• 1) Interface-Status prüfen: show ip interface brief
• 2) Default Route prüfen: show ip route | include 0.0.0.0
• 3) Next Hop pingen: ping <ISP-Gateway>
• 4) Externe IP pingen (wenn erlaubt): ping 1.1.1.1 oder ein internes Upstream-Testziel
• 5) NAT-Stats prüfen: show ip nat statistics
• 6) NAT-Translations prüfen: show ip nat translations
• 7) NAT-ACL Hits prüfen: show ip access-lists
• 8) Inside/Outside prüfen: show running-config interface <IF>
• 9) WAN-ACL/Firewall prüfen (falls vorhanden): show running-config interface <WAN>
• 10) Client-Gateway und DNS prüfen (Clientseite)

Diese Reihenfolge ist bewusst gewählt: Sie minimiert unnötige Konfigänderungen und führt schnell zur Ursache.

Schritt 1: Interface- und Linkprobleme ausschließen

Wenn ein WAN-Interface down ist, ist jede NAT-Diskussion zweitrangig. Prüfen Sie zuerst, ob LAN und WAN im erwarteten Zustand sind.

• show ip interface brief
• show interfaces gigabitethernet0/0 (oder Ihr WAN-Interface)

Typische Befunde:

• administratively down: Interface ist per shutdown deaktiviert.
• down/down: physisch kein Link (Kabel, SFP, Provider, Switchport).
• up/down: oft Layer-2/Encapsulation oder Provider-Seite; in Ethernet-Szenarien seltener, aber möglich.

Wenn das WAN-Interface flapped oder viele CRC-Fehler zeigt, kann es zu sporadischen Internetproblemen kommen, die wie NAT-Fehler wirken.

Schritt 2: Default Route und Upstream-Erreichbarkeit prüfen

Ohne Default Route erreicht der Router keine Ziele außerhalb seiner bekannten Netze. Das ist eine der häufigsten Ursachen für „NAT geht nicht“ – obwohl NAT korrekt konfiguriert ist.

• show ip route | include 0.0.0.0
• show ip route (zur Gesamtübersicht)

Wenn keine Default Route vorhanden ist, setzen Sie sie (Beispiel):

configure terminal
ip route 0.0.0.0 0.0.0.0 203.0.113.1
end

Danach prüfen Sie die Erreichbarkeit des Next Hops:

ping 203.0.113.1

Wenn schon der Next Hop nicht pingbar ist, liegt das Problem in der Regel nicht bei NAT, sondern bei WAN-Adressierung, VLAN/Encapsulation, Provider oder einem Downstream-Switch.

Schritt 3: Inside/Outside vertauscht – der Klassiker

Ein häufiges Anfängerproblem (und leider auch in hektischen Changes nicht selten): ip nat inside und ip nat outside sind falsch gesetzt oder fehlen. Dann kann NAT nicht korrekt entscheiden, welche Richtung übersetzt werden soll.

• show running-config interface gigabitethernet0/0
• show running-config interface gigabitethernet0/1

Sie sollten auf dem LAN-Interface eindeutig sehen:

ip nat inside

Und auf dem WAN-Interface:

ip nat outside

Wenn es falsch ist, korrigieren Sie es gezielt (Beispiel):

configure terminal
interface gigabitethernet0/1
ip nat inside
interface gigabitethernet0/0
ip nat outside
end

Schritt 4: NAT-Regel existiert, aber matcht nicht (ACL-Problem)

Bei PAT (Overload) ist die NAT-ACL häufig die Ursache. Wenn die ACL nicht matcht, werden keine Übersetzungen erzeugt. Viele Administratoren sehen dann „show ip nat translations“ leer und vermuten ein NAT-Problem – in Wahrheit matcht die Liste nicht den tatsächlichen Quelltraffic.

Typische Fehler in NAT-ACLs

• Falsches Subnetz oder falsche Wildcard-Maske
• Falscher ACL-Typ (z. B. Extended statt Standard, ohne passende Matches)
• ACL referenziert falsche Objekt-/ACL-Nummer in der NAT-Regel
• Client sitzt in einem anderen VLAN/Subnetz als gedacht

Prüfen

• show running-config | include ip nat inside source
• show ip access-lists (Hits prüfen)

Wenn Ihre NAT-Regel z. B. lautet:

ip nat inside source list NAT-LAN interface gigabitethernet0/0 overload

Dann muss die ACL NAT-LAN Traffic matchen. Prüfen Sie die Hit-Counter. Wenn diese bei Null bleiben, passt die Klassifizierung nicht.

Fix-Beispiel: Standard-ACL korrekt setzen

configure terminal
ip access-list standard NAT-LAN
no permit 192.168.1.0 0.0.0.255
permit 192.168.10.0 0.0.0.255
end

Best Practice: Halten Sie NAT-ACLs bewusst klein und dokumentieren Sie, welche Netze NAT nutzen dürfen. Das reduziert unerwartete Nebeneffekte.

Schritt 5: NAT-Translations und NAT-Statistiken richtig lesen

Die beiden wichtigsten NAT-Befehle im Troubleshooting sind:

• show ip nat translations
• show ip nat statistics

Was Sie erwarten sollten

• Bei PAT: viele Einträge mit interner IP:Port → externe IP:Port
• Bei Static PAT: feste Einträge für veröffentlichte Dienste, plus dynamische Einträge für aktive Sessions
• Bei Dynamic NAT: Zuordnungen interner Hosts zu Pool-IP-Adressen

Interpretation typischer Befunde

• Keine Translations, aber Traffic läuft: oft ACL-Mismatch, falsches Interface, Clients nutzen falsches Gateway.
• Translations existieren, aber keine Antwort: oft Routing/Upstream/Firewall/Provider, oder DNS, oder asymmetrischer Rückweg.
• Viele Drops/Fehler in Statistics: kann auf Pool-Exhaustion, Ressourcenprobleme oder Policy-Konflikte hindeuten.

Schritt 6: DNS vs. NAT unterscheiden (typische Fehldiagnose)

Sehr häufig melden Nutzer „Internet geht nicht“, obwohl NAT und Routing funktionieren – aber DNS nicht. Deshalb sollten Sie im Troubleshooting bewusst trennen:

• IP-Konnektivität: funktioniert Ping zu einer externen IP?
• Namensauflösung: funktioniert Zugriff auf Domains?

Wenn ein Client z. B. ping 1.1.1.1 kann, aber keine Domain auflöst, ist NAT meist nicht die Ursache. Dann prüfen Sie DNS-Server, DHCP-Optionen, lokale Firewall oder DNS-Filter. NAT wird in diesem Fall häufig fälschlich verdächtigt.

Schritt 7: WAN-ACLs, Firewalls und Zonenrichtlinien

NAT ist nicht automatisch „durchlässig“. Wenn auf dem WAN-Interface eine Inbound-ACL aktiv ist oder eine Zone-Based Firewall eingesetzt wird, kann Traffic blockiert werden – sowohl eingehend (Port Forwarding) als auch ausgehend (wenn Rücktraffic oder bestimmte Protokolle gefiltert werden).

Prüfen

• show running-config interface <WAN-IF> (ip access-group in/out?)
• show ip access-lists (Hit-Counter, deny logs)
• show logging (Drops, denies, Security-Events)

Typische Fehlerbilder:

• Outbound-NAT funktioniert, aber bestimmte Anwendungen scheitern (z. B. VPN, VoIP) wegen restriktiver ACLs.
• Inbound-Portweiterleitungen funktionieren nicht, weil die WAN-Inbound-ACL den Port nicht erlaubt.

Best Practice: Arbeiten Sie mit „allow-list“-Regeln und dokumentieren Sie, welche Services wirklich nötig sind. Eine herstellerneutrale Orientierung zur Härtung bietet der Anchor-Text CIS Controls.

Schritt 8: Asymmetrischer Rückweg – wenn NAT zwar übersetzt, aber Sessions brechen

NAT ist zustandsbehaftet: Der Router merkt sich die Übersetzung. Wenn der Rückweg nicht über denselben NAT-Punkt zurückkommt (z. B. weil es zwei Internetrouter gibt oder PBR den Hinweg umleitet), brechen Sessions häufig ab. Das wirkt dann wie „Internet geht manchmal“ oder „nur manche Seiten funktionieren“.

Typische Ursachen

• Mehrere WAN-Uplinks ohne klare Egress-Strategie
• Policy-Based Routing leitet Hinweg um, Rückweg folgt normalem Routing
• Firewall-State erwartet Rückweg über dieselbe Security-Kette

Prüfen

• traceroute von innen nach außen und (wenn möglich) von außen nach innen
• Routingtabellen auf allen Edge-Geräten vergleichen
• PBR-Policies prüfen: show route-map, show ip policy (plattformabhängig)

Fix bedeutet hier meist Design-Klarheit: ein definierter NAT-Egress pro Zone oder konsistente Policy, die Hin- und Rückwege stabil hält.

Schritt 9: Dynamic NAT Pool erschöpft oder PAT-Portknappheit

Bei Dynamic NAT kann der Pool voll laufen. Dann funktioniert „Internet“ nur für einige Clients, während neue Sessions nicht mehr aufgebaut werden können. Bei PAT (Overload) kann es bei sehr hohem Verbindungsaufkommen zu Portknappheit oder Ressourcenengpässen kommen, insbesondere in Umgebungen mit vielen kurzlebigen Sessions.

Prüfen

• show ip nat statistics (Pool-Auslastung, aktive Translations)
• show ip nat translations (Menge, Muster, ungewöhnliche Clients)

Typische Fixes

• Dynamic NAT: Pool vergrößern oder auf PAT umstellen
• PAT: NAT-ACL restriktiver machen (nicht jedes Netz muss ins Internet), „chatty“ Clients identifizieren, ggf. mehrere öffentliche IPs nutzen
• Timeouts/Session-Handling: nur mit klarer Begründung und plattformabhängig anpassen

Schritt 10: NAT-Regeln konkurrieren oder Reihenfolge/Typ passt nicht

In realen Konfigurationen existieren oft mehrere NAT-Regeln: PAT fürs LAN, Static PAT fürs Port Forwarding, Ausnahmen (NAT Exempt) für VPNs, eventuell VRFs. Wenn Regeln nicht sauber geplant sind, können sie sich gegenseitig beeinflussen. Typische Symptome sind: VPN funktioniert nicht, obwohl Internet geht; bestimmte Ziele werden falsch genattet; oder Portweiterleitungen zeigen auf den falschen Host.

Prüfen

• show running-config | include ^ip nat
• show ip nat translations (ob Übersetzungen wie erwartet aussehen)

Best Practice

• Regeln sauber gruppieren und kommentieren (Interface-Descriptions, Dokumentation)
• NAT-Ausnahmen für VPNs bewusst definieren (damit Verkehr ins VPN nicht genattet wird)
• Portweiterleitungen strikt mit WAN-ACL absichern

Gezielte Tests: So isolieren Sie die Fehlerquelle

Statt „alles auf einmal“ zu testen, ist ein stufenweiser Test viel aussagekräftiger:

• Test A: Router → ISP-Gateway (Ping)
• Test B: Router → externe IP (Ping/Traceroute)
• Test C: Client → Router (Ping Gateway)
• Test D: Client → externe IP (Ping) + NAT-Translations beobachten
• Test E: Client → Domain (DNS prüfen)

Wenn Test B scheitert, ist NAT selten das Problem. Wenn Test B klappt, aber Test D scheitert und keine NAT-Translations entstehen, ist NAT/ACL/Inside/Outside sehr wahrscheinlich.

Häufige „Fixes“, die Sie vermeiden sollten

Im Stress werden manchmal Änderungen gemacht, die kurzfristig „irgendwie“ helfen, langfristig aber neue Probleme erzeugen. Dazu zählen:

• Zu breite NAT-ACLs: plötzlich NATet der Router mehr Netze als geplant.
• „permit ip any any“ auf WAN: erhöht Angriffsfläche massiv.
• Blindes Löschen der NAT-Tabelle: kann Sessions hart trennen; nur gezielt und im Wartungsfenster.
• Unkoordinierte Default Route Änderungen: kann Routing-Loops oder Asymmetrie erzeugen.

Best Practice ist immer: Ursache lokalisieren, dann minimalinvasiv korrigieren und anschließend verifizieren.

Best Practices für dauerhaft stabiles NAT

• Edge eindeutig definieren: NAT gehört an einen klaren Egress-Punkt.
• Inside/Outside dokumentieren: Interface-Descriptions und Netzplandokumente pflegen.
• NAT-ACL bewusst restriktiv: nur Netze, die wirklich NAT benötigen.
• Inbound-Exposure minimieren: Port Forwarding nur mit ACL/Firewall und bevorzugt in DMZ-Designs.
• Monitoring: NAT-Statistiken, Pool-Auslastung, Interface-Flaps, Default Route Status.
• Change-Disziplin: nach Änderungen immer show ip nat translations und realen Testtraffic prüfen.

Konfiguration speichern und nachvollziehbar absichern

Nachdem Sie das Problem gelöst und mit Tests verifiziert haben, speichern Sie die Konfiguration:

copy running-config startup-config

Für weiterführende NAT-Szenarien, plattformspezifische Syntaxvarianten und Beispiele ist der Anchor-Text Cisco NAT Konfigurationsbeispiele eine gute Referenz. Wenn Sie einzelne Kommandos oder Optionen Ihrer IOS/IOS XE-Version exakt nachschlagen möchten, nutzen Sie den Anchor-Text Cisco IOS Command Reference.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.