VPN Handshake Probleme sind der Klassiker, wenn ein IPsec-Tunnel „eigentlich richtig konfiguriert“ ist, aber trotzdem nicht aufbaut oder sofort wieder abbricht. Besonders bei IKE Phase 1/2 (klassische IKEv1-Terminologie) verlieren viele Teams Zeit, weil sie an der falschen Stelle suchen: Es wird an Routen oder Firewall-Regeln geschraubt, obwohl der Tunnel noch nicht einmal sauber authentifiziert ist – oder umgekehrt wird endlos an Proposals geändert, obwohl das eigentliche Problem eine fehlende Rückroute für die Selektoren ist. Der Trick ist, den Handshake wie eine Kette zu betrachten und schnell zu entscheiden, in welcher Phase es scheitert. In IKEv1 entsprechen Phase 1 und Phase 2 grob dem Aufbau der IKE-SA und der IPsec-SA; in IKEv2 heißen die Bausteine IKE_SA und CHILD_SA. Wenn Sie verstehen, welche Logs und Indikatoren jeweils aussagekräftig sind, lassen sich 80–90 % der Fälle in Minuten eingrenzen: Ports/Erreichbarkeit, NAT-T, Identitäten (IDs), PSK/Zertifikate, Proposal-Mismatch, Selektoren/Proxy-IDs, Rekey-Lifetimes oder MTU/Fragmentierung. Dieser Leitfaden zeigt Ihnen einen praxiserprobten Debug-Ablauf, typische Fehlermeldungen und die schnellsten Fixes – herstellerneutral, aber so konkret, dass Sie es auf gängige Firewalls, Router und Linux-Gateways übertragen können.

Begriffe: Phase 1/2 vs. IKEv2 (IKE_SA/CHILD_SA)

In vielen GUIs und Foren wird noch mit „IKE Phase 1“ und „Phase 2“ gearbeitet. Das stammt aus IKEv1 und ist als Denkmodell weiterhin nützlich:

• IKE Phase 1 (IKEv1): Aufbau der IKE-SA – hier werden Identität, Authentifizierung und ein sicherer Kanal für die weitere Aushandlung etabliert.
• IKE Phase 2 (IKEv1): Aufbau der IPsec-SA (oft ESP-SA) – hier werden die „Traffic Selectors“ (Proxy IDs/Selektoren), ESP-Proposals und PFS für den Datentunnel ausgehandelt.

In IKEv2 wird das klarer benannt:

• IKE_SA: entspricht funktional „Phase 1“ (Schutzkanal, Auth, Schlüsselmaterial).
• CHILD_SA: entspricht funktional „Phase 2“ (eigentliche Daten-SAs für ESP, Traffic Selectors, Rekey).

IKEv2 ist in RFC 7296 definiert, die IPsec-Architektur in RFC 4301. Für NAT-Traversal sind RFC 3947 und RFC 3948 relevant.

Der schnellste Debug-Ansatz: In welcher Phase bricht es?

Bevor Sie Konfigurationen ändern, beantworten Sie diese Frage. Die Symptome sind erstaunlich konsistent:

• Phase 1/IKE_SA scheitert: Kein Tunnel, keine SAs, oft Meldungen wie „no proposal chosen“, „authentication failed“, „peer not responding“.
• Phase 2/CHILD_SA scheitert: IKE ist „up“, aber keine IPsec-SA/Child-SA entsteht oder Traffic bleibt 0; häufig Proxy-ID/Selector-Mismatch oder PFS/ESP-Mismatch.
• Phase 2 steht, aber Traffic geht nicht: SAs sind da, aber Routing/NAT/Firewall/MTU blockieren den Datenpfad (das ist nicht mehr Handshake, wird aber oft dafür gehalten).

Vor dem Handshake: Erreichbarkeit und Ports (die 2-Minuten-Prüfung)

Viele IKE-Probleme sind keine Kryptoprobleme, sondern reine Transportprobleme. Prüfen Sie zuerst:

• UDP/500 erreichbar (IKE)
• UDP/4500 erreichbar (NAT-T, oft zwingend in realen Netzen)
• ESP (IP-Protokoll 50) erreichbar, falls ohne NAT-T gearbeitet wird

In Cloud-Umgebungen ist die häufigste Falle: lokale Firewall ist offen, aber Security Groups/Provider-Firewalls blocken UDP/4500.

• Indikator: Gateway-Logs zeigen gar keine ankommenden IKE-Pakete → vor dem VPN wird geblockt.
• Fix: Ports/Protokolle end-to-end erlauben, Captive Portals/Guest-WLANs berücksichtigen.

Phase 1 schnell debuggen: Die 6 häufigsten Ursachen

Wenn IKE_SA/Phase 1 nicht hochkommt, liegt es fast immer an einem dieser Punkte.

1) Proposal-Mismatch in IKE (Crypto Suite passt nicht)

Symptomatisch sind Meldungen wie „no proposal chosen“, „no matching proposal“, „no acceptable transforms“. Ursache: Client/Gateway haben keine gemeinsame Schnittmenge aus Cipher, PRF/Hash und DH/ECDH-Gruppe.

• Fix: Auf beiden Seiten ein gemeinsames, modernes Set definieren (z. B. AES-GCM + passende PRF + ECP-Gruppe) und Legacy-Fallbacks bewusst steuern.
• Praxis-Tipp: Wenn Sie mehrere Gerätehersteller verbinden, starten Sie mit einem „Kompatibilitäts-Proposal“ (modern, aber breit unterstützt) und härten Sie danach weiter.

2) PSK falsch oder inkonsistente IDs (Identity mismatch)

Bei PSK-basierten Tunneln sind zwei Fehler extrem häufig:

• PSK stimmt nicht: Copy/Paste, falscher Tunnel, falscher Partner.
• ID passt nicht: Die Peer-ID ist auf FQDN konfiguriert, aber das Gerät sendet eine IP (oder umgekehrt).

Fixes:

• PSK neu setzen (lang, zufällig, pro Tunnel einzigartig).
• Lokale/Remote IDs explizit konfigurieren (nicht „auto“), insbesondere bei NAT oder wenn mehrere Tunnels auf einer IP terminieren.

3) Zertifikatsprobleme (X.509) in Phase 1

Bei Zertifikatsauthentifizierung scheitert Phase 1 oft an Trust, Kette oder Namen. X.509-Grundlagen: RFC 5280.

• Chain unvollständig: Intermediate fehlt auf Client oder Gateway.
• EKU falsch: Server/Client Authentication fehlt.
• Name/SAN passt nicht: Client erwartet vpn.example.com, Zertifikat enthält nur anderen Namen.
• Revocation hard-fail: CRL/OCSP nicht erreichbar; OCSP: RFC 6960.

Fix: Kette vollständig ausrollen, SAN korrekt setzen, CRL/OCSP erreichbar machen oder Policy bewusst konfigurieren (und dokumentieren).

4) NAT-T/UDP4500: NAT im Pfad bricht den Aufbau

Wenn eine Seite hinter NAT sitzt, ist NAT-T praktisch Pflicht. Ohne NAT-T kommen ESP und IKE häufig nicht stabil zustande. Standards: RFC 3947, RFC 3948.

• Symptom: IKE startet, aber bricht sporadisch ab oder hängt; in manchen Netzen geht es, in anderen nicht.
• Fix: NAT-T aktivieren, UDP/4500 freigeben, Keepalives/DPD sinnvoll setzen.

5) Zeitdrift (Clock Skew) – unterschätzt, aber fatal

Bei Zertifikaten und Tokens kann eine falsche Systemzeit dazu führen, dass Authentifizierung sofort fehlschlägt. Besonders sichtbar: „certificate not yet valid“ oder „expired“ trotz vermeintlich korrekter Werte.

• Fix: NTP auf Gateways und Systemen, Drift-Monitoring, klare Betriebsstandards.

6) „Peer not responding“: Kein Antwortpaket oder falscher Pfad

Dieser Klassiker bedeutet nicht automatisch, dass der Peer „aus“ ist. Häufige Ursachen:

• Ports geblockt (UDP/500/4500)
• Falsche öffentliche IP/DNS
• Asymmetrisches Routing durch Dual-WAN/Failover
• Rate-Limits/IPS blocken IKE

Fix: Packet Capture auf beiden Seiten, um zu sehen, ob Pakete ankommen und ob Antworten rausgehen.

Phase 2 schnell debuggen: Wenn IKE „up“ ist, aber kein Datentunnel entsteht

Wenn Phase 1 erfolgreich ist, sehen Sie typischerweise eine aktive IKE-SA. Trotzdem kann Phase 2/CHILD_SA scheitern. Die Ursachen sind meist klar eingrenzbar.

1) Proxy-IDs / Traffic Selectors passen nicht

Das ist der häufigste Phase-2-Fehler bei policy-based Tunneln. Ein Gerät erwartet z. B. 10.10.0.0/16 ↔ 10.20.0.0/16, das andere sendet 10.10.0.0/24 ↔ 10.20.0.0/16. Ergebnis: Child SA wird abgelehnt oder nicht aufgebaut.

• Symptom: Log meldet „TS unacceptable“, „no matching traffic selectors“, „proxy identities mismatch“.
• Fix: Selektoren spiegelbildlich und exakt konfigurieren; bei NAT/Overlaps besonders sorgfältig.

2) ESP-Proposal/PFS-Gruppe passt nicht

Phase 2 verhandelt ESP-Parameter (Verschlüsselung/Integrität) und optional PFS. Wenn die PFS-Gruppe oder der Cipher nicht passt, wird die Child SA nicht aufgebaut.

• Symptom: „no proposal chosen“ in Phase 2 oder Child-SA-Setup bricht ab.
• Fix: gemeinsame ESP-Proposals definieren; PFS konsistent (entweder beide aktiv mit gleicher Gruppe oder beide deaktiviert).

3) Lifetime-/Rekey-Konflikte

Unterschiedliche Lifetimes führen selten dazu, dass Phase 2 gar nicht hochkommt, aber sie führen häufig zu „Tunnel flaps“ und sporadischen Ausfällen kurz nach erfolgreichem Aufbau.

• Symptom: Tunnel kommt hoch, bricht nach 5–60 Minuten, kommt wieder hoch.
• Fix: Lifetimes angleichen, Rekey-Strategie konsistent setzen, DPD/Keepalive passend konfigurieren.

4) NAT bricht Selektoren (besonders bei policy-based)

Wenn NAT-Regeln den Quellbereich verändern, passen Selektoren nicht mehr. Das kann sich wie ein Phase-2-Problem anfühlen: IKE ist up, aber Child SA passt nicht.

• Fix: NAT-Exemptions für VPN-Traffic, Regelreihenfolge prüfen, Overlap-Design dokumentieren.

5) Route-based (VTI) ok, aber Routing fehlt

Bei route-based IPsec kann Child SA stehen, aber Traffic fließt nicht, weil keine Route über das Tunnelinterface gesetzt ist. Das wird oft fälschlich als „Phase 2 kaputt“ interpretiert.

• Fix: Routingtabellen prüfen, statische Routen setzen oder dynamisches Routing korrekt anbinden.

Packet Capture: Der Turbo für Handshake-Debugging

Wenn Logs zu vage sind oder Sie eine Provider-/Firewall-Frage klären müssen, ist Packet Capture das schnellste Instrument. Sie müssen nicht „alles“ analysieren, sondern nur wenige Signale erkennen:

• Sehe ich IKE_SA_INIT / IKE_AUTH Pakete? (IKEv2)
• Sehe ich UDP/500 und danach UDP/4500? (NAT-T Wechsel)
• Kommen Antworten zurück? (Hin- und Rückweg ok?)
• Sehe ich ESP oder UDP-encapsulated ESP? (Datenpfad nach Phase 2)

Praktische Filter:

# Wireshark Display Filter (allgemein)
udp.port == 500 || udp.port == 4500 || esp
grobe BPF Filter (tcpdump)
udp port 500 or udp port 4500 or proto 50

Wenn Sie nur auf einer Seite captures können: schon das ist hilfreich. Wenn Sie auf beiden Seiten capturen können, ist es fast immer möglich, den Fehler eindeutig zu lokalisieren (vor dem Gateway, am Gateway, hinter dem Gateway).

Herstellerunabhängige Log-Muster und was sie bedeuten

Auch wenn Geräte unterschiedliche Logtexte haben, sind die Muster sehr ähnlich:

• no proposal chosen: kein gemeinsamer Cipher/Transform (IKE oder ESP)
• peer not responding: Paket kommt nicht zurück (Firewall/Port/Routing/Rate-Limit)
• authentication failed: PSK/Zertifikat/ID/MFA/Backend
• TS unacceptable: Traffic Selectors/Proxy IDs passen nicht
• INVALID_ID_INFORMATION: IDs stimmen nicht (häufig FQDN/IP/ASN.1 DN)

Die 15-Minuten-Checkliste: IKE Phase 1/2 schnell debuggen

• 1) Kommen IKE-Pakete am Gateway an (Logs/Counter/PCAP)?
• 2) Sind UDP/500 und UDP/4500 end-to-end offen (inkl. Cloud/Provider)?
• 3) Wird NAT-T genutzt, wenn NAT im Pfad ist?
• 4) Stimmen lokale/remote IDs (FQDN/IP/DN) exakt?
• 5) PSK korrekt (oder Zertifikatskette/EKU/SAN korrekt)?
• 6) Haben beide Seiten mindestens ein gemeinsames IKE-Proposal?
• 7) Ist Phase 1/IKE_SA wirklich up (Status/SA-Liste)?
• 8) Stimmen Proxy-IDs/Traffic Selectors (bei policy-based) spiegelbildlich?
• 9) Haben beide Seiten ein gemeinsames ESP-Proposal und konsistente PFS-Einstellung?
• 10) Ist Phase 2/CHILD_SA up (ESP-SA vorhanden)?
• 11) Wenn SA up aber kein Traffic: Routing, NAT-Exempt, Policies prüfen.
• 12) MTU/MSS: große Pakete testen, PMTUD nicht blockieren.
• 13) Lifetimes/Rekey: Flaps nach festen Intervallen → Lifetimes angleichen.
• 14) HA/Failover: asymmetrisches Routing oder State-Sync-Themen ausschließen.
• 15) Änderungen versionieren und einzeln testen (nicht mehrere Variablen gleichzeitig).

Typische „Schnellfixes“ – und wann sie sinnvoll sind

Einige Fixes sind in der Praxis sehr effektiv, sollten aber bewusst eingesetzt werden:

• Kompatibilitäts-Proposal temporär: Wenn Interop mit Partner nicht klappt, definieren Sie vorübergehend ein gemeinsames Proposal – aber dokumentieren Sie es und härten Sie später.
• NAT-T erzwingen: In vielen Real-World-Netzen ist UDP/4500 stabiler als „reines ESP“.
• Selektoren vereinfachen: Für Debugging temporär einen kleineren, eindeutigen Selector testen (z. B. /32 Host ↔ /32 Host), um Proxy-ID-Probleme zu isolieren.
• MTU konservativ setzen: Wenn Anwendungen „komisch“ scheitern, kann eine niedrigere MTU sofort Klarheit bringen.

Wichtig: Jeder Quickfix muss in der Doku landen – sonst wird er zur nächsten „unerklärlichen“ Altlast.

Outbound-Links zur Vertiefung

• RFC 7296: IKEv2
• RFC 4301: IPsec Architecture
• RFC 3947: NAT-Traversal Negotiation in IKE
• RFC 3948: UDP Encapsulation of IPsec ESP (NAT-T)
• RFC 5280: X.509 Certificates and CRL Profile
• RFC 6960: OCSP
• RFC 1191: Path MTU Discovery (IPv4)
• RFC 8201: Path MTU Discovery (IPv6)

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.