Troubleshooting IPsec Deep Dive: SAs, Rekey, NAT-T, Fragmentierung

IPsec-Probleme wirken im Betrieb oft „mysteriös“: Der Tunnel ist „up“, aber Traffic geht nicht. Oder alles läuft, bis ein Rekey kommt – dann gibt es kurze Aussetzer. Oder nur große Transfers brechen, während Ping/SSH noch funktionieren. In fast allen Fällen steckt dahinter eine saubere, erklärbare Ursache: falsche SA-States, Rekey-Mismatches, NAT-Traversal (NAT-T) Effekte oder Fragmentierung/PMTUD-Blackholes. Dieses Deep-Dive-Tutorial zeigt ein systematisches Troubleshooting-Vorgehen auf Cisco (IOS/IOS XE) mit Fokus auf SAs, Rekey, NAT-T und Fragmentierung – inklusive praxistauglicher „Copy & Paste“-Checks.

Debugging-Modell: Control Plane vs. Data Plane

IPsec hat eine klare Schichtung: IKE (Phase 1) baut die sichere Control Plane auf, IPsec (Phase 2) transportiert Nutztraffic. Viele Fehler entstehen, wenn Phase 1 „gesund“ aussieht, aber Phase 2 nicht (oder umgekehrt). Deshalb debuggt man immer in Ebenen.

• IKEv1/IKEv2 SA: Auth, Key Exchange, Rekey der IKE-SA
• IPsec SA: ESP/AH Parameter, Rekey der Child-SAs
• Data Plane: Encaps/Decaps, Drops, MTU/Fragmentierung

Merker

$\text{VPN ok}\iff \text{IKE SA up}+\text{IPsec SA up}+\text{Encaps/Decaps steigen}$

Step 1: IKE SA prüfen (Phase 1) – ist die Control Plane stabil?

Wenn die IKE SA nicht stabil ist, brauchst du Phase-2-Debugging noch nicht anfangen. Prüfe zuerst, ob die SA existiert, welcher State aktiv ist, und ob DPD/Keepalives auffällig sind.

IKEv2 Status

show crypto ikev2 sa
show crypto ikev2 sa detail

IKEv1 Status (falls relevant)

show crypto isakmp sa
show crypto isakmp sa detail

Typische IKE-Fehlerbilder

• Keine SA: Routing/ACL/UDP 500/4500 blockiert
• SA flapt: DPD zu aggressiv, Underlay Loss/Jitter
• Auth fail: PSK/Zertifikat/Identity Match falsch

Step 2: IPsec SA prüfen (Phase 2) – Child SAs, Selector, Lifetimes

Wenn IKE steht, aber kein Traffic geht, ist Phase 2 der Fokus. Du prüfst, ob IPsec SAs existieren, welche Transform-Parameter verhandelt wurden und ob Encaps/Decaps Counter steigen.

IPsec Status

show crypto ipsec sa
show crypto ipsec sa detail

Interpretation der Counter

• encaps steigt, decaps bleibt 0: Rückweg/Asymmetry/Remote drop
• decaps steigt, encaps bleibt 0: Traffic läuft „falsch“ (Routing/Policy)
• beide 0: keine „interesting traffic“ trifft Tunnel (Selector/Routing)

Rekey Deep Dive: Warum Rekeys kurze Outages erzeugen

Rekey ist normal und notwendig. Outages entstehen, wenn Lifetimes nicht zusammenpassen, Rekeys synchronisiert werden (viele Tunnel gleichzeitig), oder wenn Underlay-Loss während Rekey die neue SA nicht sauber etabliert. Besonders kritisch sind Child-SA-Rekeys (Phase 2), weil sie direkt den Traffic-Pfad betreffen.

• IKE Rekey: meist weniger sichtbar, aber kann Session beeinflussen
• Child-SA Rekey: kann Traffic kurz unterbrechen
• Mismatched Lifetimes: unnötige Rekeys oder Rekey-Stürme

Rekey-Last (vereinfacht)

$\text{Rekeys pro Stunde}\approx \frac{\text{Anzahl\_Tunnel}}{\text{Lifetime\_hours}}$

Praxischecks rund um Rekey

show crypto ikev2 sa detail
show crypto ipsec sa | include remaining|lif|rekey
show logging | include IKE|IPSEC|rekey|DPD

NAT-T verstehen: Wenn IPsec durch NAT „anders“ wird

Wenn zwischen Peers NAT vorhanden ist, wechselt IPsec in NAT-Traversal (NAT-T): ESP wird in UDP/4500 gekapselt. Das ist technisch robust, hat aber operative Konsequenzen: NAT-State muss stabil sein, Keepalives sind wichtiger, und asymmetrische Pfade sind noch gefährlicher.

• NAT-T: UDP/4500 statt „reines“ ESP
• NAT-State: muss für die Dauer der Session bestehen
• Carrier- oder CGNAT-Pfade: erhöhen Flap-Risiko

NAT-T Indizien

show crypto ikev2 sa detail
show crypto ipsec sa

Asymmetry und State: Der Klassiker bei Dual-WAN und Failover

IPsec ist zustandsbehaftet. Wenn Hin- und Rückweg über unterschiedliche Underlays laufen oder wenn Failover ohne klare Priorität passiert, entstehen Drop-Situationen: decaps fehlen, oder Pakete landen am falschen Peer/Interface.

• Dual-WAN ECMP: einzelne Flows laufen über unterschiedliche Pfade
• Failover ohne Hysterese: Rekey + Flap = instabiler Tunnel
• Upstream asymmetrisch: Rücktraffic kommt über anderen ISP zurück

Pfadbeweis

show ip route <peer-public-ip>
show ip cef <peer-public-ip> detail
show ip cef exact-route <local-wan-ip> <peer-public-ip>

Fragmentierung und PMTUD: „Small works, large fails“

Wenn nur große Transfers brechen, ist MTU/PMTUD fast immer der Grund. IPsec erhöht Overhead; GRE over IPsec erhöht ihn weiter. Wenn ICMP (IPv4 Fragmentation Needed / IPv6 Packet Too Big) gefiltert wird, entsteht ein Blackhole. MSS Clamping ist der pragmatische TCP-Fix.

• Symptom: Ping/SSH ok, Downloads/TLS brechen
• Ursache: PMTUD kaputt oder Pfad-MTU kleiner als erwartet
• Fix: MSS Clamping auf Tunnel/Edge

DF-Ping für MTU (IPv4)

ping <remote-host> df-bit size 1472 repeat 5
ping <remote-host> df-bit size 1400 repeat 5

MSS Clamping (Pattern)

interface Tunnel100
 ip tcp adjust-mss 1360

Selector und „Interesting Traffic“: Crypto Map vs. VTI Fehlerbilder

Bei Crypto Maps ist der häufigste Fehler ein Selector-Mismatch: Die ACL passt nicht zu den Remote-Selectoren, oder NAT-Exemptions fehlen. Bei VTIs ist der häufigste Fehler Routing: Traffic nimmt nicht den Tunnel, obwohl er soll (oder umgekehrt).

• Crypto Map: ACL/Proxy-ID Mismatch, NAT Exempt fehlt
• VTI: falsche Route/Policy, Tunnel up aber kein Traffic

Crypto Map Checks

show crypto map
show access-lists
show ip nat translations | include <vpn-prefix>

VTI Checks

show interface Tunnel100
show ip route <remote-prefix>
show ip cef <remote-host> detail

Drops und Replay: Data Plane Hinweise, die oft übersehen werden

Wenn SAs stehen, aber Traffic nicht sauber fließt, sind Drops ein Schlüssel. Replay Drops können durch Out-of-Order (ECMP, Jitter) entstehen. QFP/ASIC Drops zeigen, ob es ein Hardware- oder Queueing-Problem ist.

Replay/Drops prüfen

show crypto ipsec sa | include replay|drop
show interfaces | include drops|error
show platform hardware qfp active statistics drop

Systematischer Workflow: Von „SA“ zu „Traffic“ zu „MTU“

Dieser Workflow ist in produktiven Incidents bewährt: erst SAs, dann Counter, dann Pfad/Asymmetry, dann MTU/PMTUD und Drops. Damit vermeidest du blindes Debugging.

• 1) IKE SA up?
• 2) IPsec SA up?
• 3) Encaps/Decaps steigen?
• 4) Pfad symmetrisch zum Peer?
• 5) MTU/PMTUD ok?
• 6) Drops/Replay auffällig?

Quick-Runbook: IPsec Deep Dive (Copy & Paste)

Diese Sequenz ist für „Tunnel up, aber Traffic kaputt“ optimiert.

! 1) SAs
show crypto ikev2 sa
show crypto ikev2 sa detail
show crypto ipsec sa
show crypto ipsec sa | include encaps|decaps|replay|drop
! 2) Path / Asymmetry

show ip route 

show ip cef  detail
! 3) MTU / PMTUD

ping  df-bit size 1400 repeat 5

show interfaces | include MTU|drops|error
! 4) Platform drops (IOS XE)

show platform hardware qfp active statistics drop

Konfiguration speichern

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.