Intermittierendes Flapping der Tunnelgruppe des sicheren Zugriffs mit dem Azure VPN-Gateway während IKE-Rekey-Ereignissen

Problem

Bei einer neu konfigurierten Netzwerk-Tunnelgruppe zwischen Cisco Secure Access und Azure VPN Gateway treten bei IKE-Schlüsselereignissen etwa alle vier Stunden unterbrochene Tunnelflapping-Ereignisse auf.

Diese spezifischen Fehlermeldungen und Symptome wurden beobachtet:

• BGP-Peer-Down, Hold-Timer abgelaufen

• Warnung: Fehlgeschlagener IKE-Schlüssel

• IKE-Tunnel getrennt

Das Flapping des Tunnels führt zu regelmäßigen Unterbrechungen, IKE-Schlüsselfehlern, Integritätsprüfungsfehlern, Tunneltrennungen und BGP-Peering-Drops, was sich auf die stabile Verbindung mit Azure-Ressourcen auswirkt. Authentifizierungsfehler werden während der Schlüsselverhandlung festgestellt.

Umwelt

• Cisco Secure Access (CSA) Network Tunnel Group für Azure VPN-Gateway konfiguriert

• IPsec-Site-to-Site-VPN-Tunnel mit IKEv2

• Azure VPN-Gateway mit AES-GCM-256-Verschlüsselung, konfiguriert in Richtlinien für den Hauptmodus (MM)

• NAT-T (NAT Traversal) auf beiden Seiten über Port 4500 aktiviert

• Konfiguration von BGP-Peering zwischen Endpunkten

• IKE SA-Standardlebensdauer von 4 Stunden (28800 Sekunden)

• Erstkonfiguration der IPsec-SA-Lebensdauer, später auf 10800 Sekunden geändert

• PFS (Perfect Forward Secrecy) auf Azure-Seite nicht aktiviert

Auflösung

Das Problem wurde durch eine Konfigurationsänderung behoben, um AES-GCM-Verschlüsselungen in Richtlinien für den Hauptmodus zu vermeiden, die auf der Identifizierung eines Fehlers im Azure VPN-Gateway basieren.

Schritt 1: Azure VPN-Gateway-Fehleranalyse

IKE-Debugging-Vorgänge wurden auf der Seite des Azure VPN-Gateways gesammelt, um dieses Verhalten bei erneuten Schlüsselversuchen aufzudecken:

SESSION_ID :{} Remote x.x.x.x:500: Local x.x.x.x:500: [SEND]Sending IPSec policy Payload for tunnel Id Policy1:Integrity=AES-GCM-256 Cipher=AES-GCM-256
SESSION_ID :{} Remote x.x.x.x:4500: Local x.x.x.x:4500: [SEND][CHILD_SA MM_REKEY] Sending IKE rekey response packet with tunnelId , iCookie  and rCookie 
SESSION_ID :{} Remote x.x.x.x:4500: Local x.x.x.x:4500: [LOCAL_MSG] IKE Tunnel closed for tunnelId x3 with status IKE authentication credentials are unacceptable

Phase 2: Ursachenidentifizierung

Die Azure-Unterstützung hat die erneuten Schlüsselfehler untersucht. Die Azure-Analyse hat festgestellt, dass das rekey-Paket fehlerhaft ist, wenn Azure einen MM-REKEY mit AES-GCM-256 initiiert. Das Gerät am Standort antwortet nicht auf die fehlerhafte Schlüsselanforderung, was zur Trennung des Tunnels führt.

Schritt 3: Implementierung von Configuration Workaround

Auf der Grundlage der Empfehlungen von Azure wurde diese Eindämmung implementiert:

• Entfernen Sie AES-GCM-Verschlüsselungen aus den MM-Richtlinien (Main Mode) in der Konfiguration der Netzwerk-Tunnelgruppe.

• Konfigurieren Sie alternative Verschlüsselungsmethoden, die den GCM-Modus nicht verwenden.

Weitere Informationen finden Sie unter Schritt 17 in https://securitydocs.cisco.com/docs/csa/olh/121327.dita.

Schritt 4: Optionen zur alternativen Risikominimierung

Azure bot außerdem weitere Strategien zur Risikominimierung an, die in Betracht gezogen werden können:

• Konfigurieren Sie die standortbasierte MM-Lebensdauer auf mehr als 28800 Sekunden, damit Azure immer den Schlüssel erneut initiiert.

• Legen Sie für das Azure VPN-Gateway den Antwortmodus fest, wobei die standortbasierte SA-Lebensdauer kürzer ist als die Lebensdauer von Azure.

Ursache

Die Ursache liegt in einem Fehler im Azure VPN Gateway, der sich auf die AES-GCM-Schlüsselvorgänge auswirkt. Wenn Azure einen MM-REKEY mit AES-GCM-256 initiiert, ist das rekey-Paket fehlerhaft, sodass das Cisco Secure Access-Gerät vor Ort nicht auf die fehlerhaft geformte rekey-Anforderung antwortet. Dies führt zu IKE-Neuschlüsselfehlern, Authentifizierungsfehlern und nachfolgenden Tunneltrennungen.

Azure hat dies als bestehenden Fehler bestätigt und einen geplanten Fix in einer zukünftigen Gateway-Version dokumentiert, die für Mitte 2026 geplant ist.

Verwandte Inhalte

• Technischer Support und Downloads von Cisco

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	18-Aug-2026	Erstveröffentlichung