NAT-Konfiguration auf Cisco-Routern: Büro-Use-Cases + erwartete Ergebnisse

NAT (Network Address Translation) ist in Büro- und Unternehmensnetzen einer der häufigsten Cisco-Router-Use-Cases: Private RFC1918-Netze sollen sicher ins Internet, einzelne interne Dienste müssen gezielt von außen erreichbar sein, und VPN-Traffic darf dabei nicht „aus Versehen“ genattet werden. Dieser Leitfaden zeigt praxisorientiert typische NAT-Szenarien auf Cisco-Routern, passende CLI-Konfigurationen und die erwarteten Ergebnisse, die Sie mit klaren Checks verifizieren können.

NAT-Grundlagen: Was wird übersetzt und warum?

NAT übersetzt IP-Adressen (und bei PAT zusätzlich Ports), damit private Netze mit öffentlichen Netzen kommunizieren können. Im Büroalltag ist PAT („Overload“) der Standard: Viele interne Clients teilen sich eine öffentliche IP.

• Static NAT: 1:1-Zuordnung einer internen zu einer öffentlichen IP
• Dynamic NAT: Pool-basierte, dynamische 1:1-Zuordnung
• PAT (NAT Overload): Viele interne Hosts teilen sich eine öffentliche IP über Portübersetzung
• Inside/Outside: Definition der NAT-Grenze über Interface-Rollen

Voraussetzungen: Interfaces, Adressierung und Default-Route

Bevor NAT funktioniert, muss das Routing stimmen: Inside-Netze müssen geroutet werden, und der Router braucht eine funktionierende Default-Route ins Internet. Außerdem müssen Inside/Outside-Interfaces korrekt gesetzt sein.

Minimal-Setup (WAN + LAN + Default-Route)

interface GigabitEthernet0/0
 description WAN-ISP
 ip address 198.51.100.2 255.255.255.252
 ip nat outside
 no shutdown
interface GigabitEthernet0/1

description LAN

ip address 10.10.10.1 255.255.255.0

ip nat inside

no shutdown
ip route 0.0.0.0 0.0.0.0 198.51.100.1

Use-Case 1: Standard-Internet für Büro (PAT/Overload)

Der Klassiker: Alle internen Clients (z. B. 10.10.10.0/24) sollen ins Internet. Dafür wird eine Standard-ACL als NAT-Quelle genutzt und die Übersetzung auf die WAN-Interface-IP durchgeführt.

Konfiguration: NAT Overload für ein internes Netz

ip access-list standard NAT_INSIDE
 permit 10.10.10.0 0.0.0.255
ip nat inside source list NAT_INSIDE interface GigabitEthernet0/0 overload

Erwartete Ergebnisse

• Clients im LAN erreichen Internetziele (DNS/HTTP/HTTPS) über die WAN-IP
• Mehrere Clients können gleichzeitig raus, da Ports übersetzt werden
• In NAT-Tabellen erscheinen dynamische Übersetzungen während aktiver Sessions

Verifikation: Was Sie sehen sollten

show ip nat translations
show ip nat statistics
ping 8.8.8.8 source 10.10.10.1
traceroute 1.1.1.1 source 10.10.10.1

Use-Case 2: Mehrere VLANs ins Internet (zentrales Büro-Design)

In Büros gibt es meist mehrere Segmente: Users, Voice, Guest, IoT. NAT sollte nur die Segmente erfassen, die tatsächlich ins Internet dürfen. Guest wird oft separat behandelt (z. B. über eigenen ISP oder restriktivere Policies).

Konfiguration: NAT für mehrere interne Netze

ip access-list standard NAT_INSIDE
 permit 10.10.10.0 0.0.0.255
 permit 10.10.20.0 0.0.0.255
 permit 10.10.40.0 0.0.0.255
ip nat inside source list NAT_INSIDE interface GigabitEthernet0/0 overload

Erwartete Ergebnisse

• Nur erlaubte VLANs erhalten Internetzugang
• Nicht gelistete Netze bleiben ohne NAT und damit typischerweise ohne Internet (sofern kein anderes Routing existiert)
• NAT-Statistik zeigt höhere Hits, wenn mehrere VLANs aktiv sind

Use-Case 3: Portweiterleitung (Static PAT) für einen internen Dienst

Wenn ein interner Dienst von außen erreichbar sein muss (z. B. VPN-Gateway, Webservice, Remote-Management über Jump Host), wird Static PAT eingesetzt. Dabei wird ein öffentlicher Port auf einen internen Host/Port gemappt.

Konfiguration: Öffentliche HTTPS-Anfrage auf internen Server weiterleiten

ip nat inside source static tcp 10.10.10.50 443 198.51.100.2 443

Erwartete Ergebnisse

• Externe Clients erreichen den internen Server über die öffentliche WAN-IP und Port 443
• In der NAT-Tabelle erscheint eine statische Zuordnung
• Firewall/ACLs müssen den Inbound-Port zusätzlich erlauben (NAT allein ist keine Freigabe)

Verifikation: Static NAT Eintrag prüfen

show ip nat translations | include 10.10.10.50
show running-config | include ip nat inside source static

Use-Case 4: No-NAT für Site-to-Site VPN (häufigster Büro-Fehlerfall)

Wenn Site-to-Site VPN genutzt wird, darf der „interessante“ VPN-Traffic nicht genattet werden. Sonst passen Selektoren nicht mehr, und Sie erhalten häufig das Symptom „Tunnel up, aber kein Traffic“.

Konzept: NAT-Bypass mit Route-Map

Das folgende Muster setzt voraus, dass die Route-Map zuerst VPN-Traffic matcht (und vom NAT ausnimmt) und danach den restlichen Internetverkehr für Overload zulässt.

ip access-list extended ACL-NONAT-VPN
 permit ip 10.10.0.0 0.0.255.255 10.20.0.0 0.0.255.255

ip access-list standard ACL-NAT-INSIDE
 permit 10.10.0.0 0.0.255.255

route-map RM-NAT permit 10
 match ip address ACL-NONAT-VPN
 set interface Null0

route-map RM-NAT permit 20
 match ip address ACL-NAT-INSIDE

ip nat inside source route-map RM-NAT interface GigabitEthernet0/0 overload

Erwartete Ergebnisse

• Traffic zu 10.20.0.0/16 wird nicht genattet und kann über VPN laufen
• Internetverkehr aus 10.10.0.0/16 wird weiterhin per PAT übersetzt
• Bei VPN-Problemen zählen IPsec-Statistiken Pakete, NAT-Translations bleiben für VPN-Traffic aus

Verifikation: VPN und NAT getrennt prüfen

show ip nat translations
show crypto ipsec sa
show crypto ikev2 sa

Use-Case 5: Dual-ISP NAT (Büro mit Lastverteilung oder Failover)

Bei zwei ISPs ist NAT oft die häufigste Fehlerquelle, weil Return-Traffic zur richtigen öffentlichen Quell-IP passen muss. Ein stabiler Ansatz ist Active/Standby mit Tracking; für gezielte Lastverteilung werden getrennte NAT-ACLs pro ISP verwendet.

Konfiguration: Getrennte NAT-ACLs für zwei WAN-Interfaces (vereinfachtes Muster)

ip access-list standard NAT_ISP1
 permit 10.10.10.0 0.0.0.255
 permit 10.10.20.0 0.0.0.255
ip access-list standard NAT_ISP2

permit 10.10.30.0 0.0.0.255
interface GigabitEthernet0/0

ip nat outside

interface GigabitEthernet0/2

ip nat outside

interface GigabitEthernet0/1

ip nat inside
ip nat inside source list NAT_ISP1 interface GigabitEthernet0/0 overload

ip nat inside source list NAT_ISP2 interface GigabitEthernet0/2 overload

Erwartete Ergebnisse

• Users/Voice gehen über ISP1, Guest über ISP2 (bei passendem Routing/PBR)
• NAT-Translations zeigen unterschiedliche Outside-IPs je Segment
• Bei Failover brechen bestehende NAT-Sessions typischerweise ab, neue Sessions laufen über den aktiven ISP

Typische NAT-Fehlerbilder und schnelle Diagnose

NAT-Probleme zeigen sich oft als „DNS geht, aber Webseiten nicht“ oder „einzelne Ziele gehen nicht“. Ursache ist meist falsches Inside/Outside, fehlende Default-Route, ACL-Match-Probleme oder MTU/Fragmentierung.

Schnelle Checks (SOP)

show ip nat statistics
show ip nat translations
show ip route 0.0.0.0
show interfaces counters errors
show access-lists
show logging | last 50

Häufige Ursachen

• Inside/Outside vertauscht oder auf falschem Interface gesetzt
• ACL matcht nicht (falsche Wildcard, falsches Netz, falsche Richtung)
• Kein Default-Route oder falscher Next-Hop
• No-NAT fehlt bei VPN oder Route-Map-Reihenfolge ist falsch
• Ingress-ACL blockt Rückverkehr oder Inbound-Port für Portweiterleitung fehlt

Erwartete Ergebnisse sauber dokumentieren: Abnahme-Kriterien

Für Büro-Setups sollten NAT-Abnahmen messbar und reproduzierbar sein. Das verhindert Diskussionen und beschleunigt spätere Changes.

• Internet: Ping/Traceroute von LAN-Gateway und Testclient
• DNS/HTTPS: Auflösung und Zugriff auf definierte Testziele
• NAT: Sichtbare Übersetzungen für aktive Sessions, plausible Statistikwerte
• Portweiterleitung: Externer Test gegen öffentliche IP/Port, Service-Response ok
• VPN: Keine NAT-Translations für VPN-Netze, IPsec SA zählt Pakete

Beispiel: Post-Checks als Abnahme-Protokoll

show ip nat translations
show ip nat statistics
ping 8.8.8.8 source 10.10.10.1
traceroute 1.1.1.1 source 10.10.10.1

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.