NAT und VPN sind eine häufige Problemkombination: NAT verändert IP-Adressen und Ports, während VPNs (insbesondere IPsec) Integrität, Peer-Identität und oft auch „No-NAT“-Verhalten erwarten. Typische Symptome sind: Tunnel kommt nicht hoch, Phase 2 bricht, Traffic geht nur in eine Richtung oder bestimmte Subnetze sind nicht erreichbar. Mit sauberer NAT-Exemption, korrektem NAT-T (UDP/4500) und klaren ACLs lassen sich die meisten Fälle zuverlässig lösen.
Warum NAT VPNs stören kann
NAT ändert Header-Informationen. Bei IPsec wird der Verkehr kryptografisch geschützt, wodurch Änderungen am Paket (oder am falschen Paketanteil) zu Drops führen. Zusätzlich können NAT-Geräte Protokolle ohne Ports (ESP) nicht immer sauber „tracken“.
- IPsec ESP (IP-Protokoll 50) hat keine Ports → NAT/PAT ist tricky
- IKE läuft über UDP/500, NAT-T über UDP/4500
- Wenn „interessanter Traffic“ genattet wird, passt die Crypto-Policy nicht mehr
Merker: VPN-Traffic sollte meist nicht genattet werden
Typische Symptome in der Praxis
Die Fehlerbilder wiederholen sich. Wenn du das Symptom erkennst, kannst du die Ursache oft schnell eingrenzen.
- IKE/Phase 1 kommt nicht hoch: UDP/500 blockiert, Peer falsch, NAT-T fehlt
- Phase 2 kommt nicht hoch: Crypto ACL passt nicht, NAT-Exemption fehlt
- Tunnel steht, aber kein Traffic: Routing/ACL/No-NAT falsch, Return Path fehlt
- Nur einseitiger Traffic: Asymmetrie, falsche NAT-Regel-Reihenfolge
Problem 1: NAT Exemption fehlt (häufigster IPsec-Killer)
Bei Site-to-Site-IPsec muss der „interessante Traffic“ (z. B. 192.168.10.0/24 ↔ 192.168.20.0/24) unverändert bleiben. Wenn PAT/Overload diesen Traffic übersetzt, matcht die Crypto ACL nicht mehr und Phase 2 scheitert oder Traffic wird gedroppt.
Fix: No-NAT für VPN-Netze (NAT Exemption) mit ACL
Die genaue Syntax hängt von NAT-Variante/IOS ab. Ein gängiges Muster ist: erst VPN-Traffic per ACL definieren und ihn von NAT ausschließen, danach allgemeines PAT für „Internet“ zulassen.
Router# configure terminal
Router(config)# ip access-list extended ACL-NO-NAT
Router(config-ext-nacl)# permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
Router(config-ext-nacl)# permit ip 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255
Router(config-ext-nacl)# end
Beispielprinzip: NAT-Regeln so bauen, dass VPN zuerst greift
Router# configure terminal
Router(config)# ip access-list standard NAT_INSIDE
Router(config-std-nacl)# permit 192.168.10.0 0.0.0.255
Router(config-std-nacl)# end
Router(config)# end
Verifikation: VPN-Traffic darf keine NAT-Translation bekommen
Router# show ip nat translations
Router# show ip nat translations | include 192.168.10.|192.168.20.
Problem 2: NAT-T (NAT Traversal) nicht aktiv oder UDP/4500 blockiert
Wenn mindestens eine Seite hinter NAT sitzt, wird IPsec typischerweise in UDP/4500 gekapselt (NAT-T). Wenn UDP/4500 blockiert ist, kommt Phase 2 oft nicht stabil hoch oder der Tunnel flapped.
- IKE: UDP/500
- NAT-T: UDP/4500
- ESP (Protokoll 50) kann bei NAT problematisch sein
Fix: UDP/500 und UDP/4500 in ACLs erlauben (am Outside)
Router# configure terminal
Router(config)# ip access-list extended OUTSIDE_IN
Router(config-ext-nacl)# permit udp host 198.51.100.2 host 203.0.113.2 eq 500
Router(config-ext-nacl)# permit udp host 198.51.100.2 host 203.0.113.2 eq 4500
Router(config-ext-nacl)# permit esp host 198.51.100.2 host 203.0.113.2
Router(config-ext-nacl)# deny ip any any
Router(config-ext-nacl)# exit
Router(config)# interface gigabitEthernet0/1
Router(config-if)# ip access-group OUTSIDE_IN in
Router(config-if)# end
Hinweis: Bei NAT-T ist ESP nicht immer zwingend sichtbar
Wenn NAT-T aktiv ist, läuft die Datenebene häufig über UDP/4500 statt nativem ESP.
Problem 3: Crypto ACL und NAT-ACL passen nicht zusammen
Ein häufiger Designfehler ist, dass die Crypto ACL andere Netze/Masken matcht als die NAT-Exemption oder das Routing. Dann steht der Tunnel ggf. kurz, aber Traffic wird nicht verschlüsselt oder falsch geroutet.
Fix: Crypto-Interessensbereich und No-NAT identisch halten
- Gleiche Subnetze, gleiche Masken
- Beide Richtungen abgedeckt (A↔B)
- Keine Overlaps mit Internet-NAT
Quick-Check: Welche ACLs sind im Einsatz?
Router# show running-config | include crypto map|match address
Router# show access-lists
Problem 4: Tunnel steht, aber kein Traffic (Routing/Return Path)
Wenn IKE/SA vorhanden ist, aber kein Nutztraffic durchgeht, ist es häufig kein NAT-Problem mehr, sondern Routing oder ACLs. Prüfe, ob die Remote-Subnetze via Tunnel erreichbar sind und ob der Rückweg stimmt.
Routen prüfen
Router# show ip route 192.168.20.0
Router# traceroute 192.168.20.10
Router# ping 192.168.20.10 source 192.168.10.1
Firewall/ACLs im LAN prüfen
Router# show running-config | include access-group
Router# show ip interface gigabitEthernet0/0
Router# show access-lists
Problem 5: Overlapping Subnets – NAT als Workaround
Wenn beide Standorte die gleichen privaten Netze nutzen (z. B. beide 192.168.10.0/24), funktioniert Site-to-Site-VPN ohne Adress-Umsetzung nicht sauber. In solchen Fällen wird häufig VPN-NAT (Policy NAT) verwendet, um eine Seite in ein „virtuelles“ Netz zu mappen.
- Symptom: Traffic geht an das lokale Netz statt durch den Tunnel
- Sauberste Lösung: Re-Addressing (langfristig)
- Workaround: Policy NAT für VPN (übersetzen nur für Tunneltraffic)
Indiz im Troubleshooting
Router# show ip route 192.168.10.0
Router# show arp | include 192.168.10.
Verifikation: NAT und VPN gemeinsam prüfen
Wenn NAT und VPN zusammenspielen, musst du auf beiden Ebenen verifizieren: NAT-Translations für VPN-Traffic dürfen nicht entstehen, und IPsec muss SAs und Counters erhöhen, wenn du Traffic erzeugst.
NAT prüfen
Router# show ip nat translations
Router# show ip nat statistics
IPsec/IKE prüfen (typische Cisco-Checks)
Router# show crypto isakmp sa
Router# show crypto ipsec sa
Counters: steigen bei Ping/Traffic?
Router# clear crypto sa
Router# ping 192.168.20.10
Router# show crypto ipsec sa
Best Practices: NAT und VPN stabil betreiben
Mit diesen Regeln vermeidest du die meisten NAT/VPN-Fallen und bekommst ein reproduzierbares Design.
- No-NAT (Exemption) für VPN-Subnetze, bevor PAT greift
- Crypto ACL und No-NAT ACL konsistent halten
- UDP/500 und UDP/4500 am Outside erlauben, NAT-T einplanen
- Asymmetrische Pfade vermeiden (Dual-WAN/NAT + Stateful)
- Overlapping Subnets früh im Design vermeiden
Quick-Reference: Checkliste (Copy & Paste)
Diese Befehle decken in kurzer Zeit die häufigsten Ursachen ab: NAT-Zonen, NAT-Regeln, Translations, ACLs sowie IPsec/IKE-Status.
show ip interface brief
show running-config | include ip nat
show access-lists
show ip nat translations
show ip nat statistics
show ip route | include 0.0.0.0|Gateway
show crypto isakmp sa
show crypto ipsec sa
ping 192.168.20.10 source 192.168.10.1
traceroute 192.168.20.10
Konfiguration speichern
Wenn VPN-SAs stabil sind, NAT-Translations für VPN-Traffic ausbleiben und die Netze bidirektional erreichbar sind, speichere die Konfiguration.
Router# copy running-config startup-config
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.












