Site icon bintorosoft.com

VPN Handshake Probleme: IKE Phase 1/2 schnell debuggen

Red Snapper

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:

In IKEv2 wird das klarer benannt:

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:

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

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

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

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.

2) PSK falsch oder inkonsistente IDs (Identity mismatch)

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

Fixes:

3) Zertifikatsprobleme (X.509) in Phase 1

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

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.

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.

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

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

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.

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.

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.

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.

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.

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:

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:

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

Typische „Schnellfixes“ – und wann sie sinnvoll sind

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

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

Outbound-Links zur Vertiefung

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:

Lieferumfang:

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.

 

Exit mobile version