FortiGate Azure Rekey: Peer-SA-Vorschlag passt nicht zur lokalen Richtlinie

Der Tunnel kam hoch, der Verkehr floss, und später steht im Protokoll peer SA proposal not match local policy. Die meisten lesen diese Zeile als Beweis dafür, dass die beiden Konfigurationen nie übereingestimmt haben. Meist bedeutet sie etwas Engeres: Sie stimmten für die erste CHILD SA überein und hörten bei der ersten Erneuerung auf übereinzustimmen, weil die erste Assoziation den Austausch, den spätere durchführen, nie gebraucht hat. Genau diese Unterscheidung entscheidet, wo Sie nachsehen.

Die erste CHILD SA erbt, spätere verhandeln

In IKEv2 wird die anfängliche CHILD SA während IKE_AUTH erstellt, und ihre Schlüssel werden aus dem Schlüsselmaterial der IKE SA abgeleitet. Zu diesem Zeitpunkt gibt es keinen separaten Diffie-Hellman-Austausch, sodass eine PFS-Gruppe, die ein Peer nicht akzeptieren kann, schlicht noch nicht geprüft wird. Der Tunnel wirkt gesund, weil die Anforderung, an der Sie später scheitern werden, nie getestet wurde.

Ein CHILD_SA-Rekey ist eine andere Nachrichtenfolge. Wenn PFS konfiguriert ist, führen die Peers einen neuen Schlüsselaustausch durch und müssen sich auf eine Gruppe einigen, die beide Seiten akzeptieren, sowie auf den ESP-Vorschlag für die neue Assoziation. Das ist der Moment, in dem die Abweichung sichtbar wird, und deshalb nennt der Fehler einen Vorschlag statt einer Route.

„Gestern lief es“ sagt Ihnen also nichts über den Vorschlag. Es sagt Ihnen, dass der anfängliche Austausch erfolgreich war, was Sie bereits wussten.

Lesen Sie den fehlgeschlagenen Austausch, nicht den ersten Ping

Sammeln Sie von beiden Seiten die erfolgreiche IKE-Authentifizierung, die anfängliche CHILD SA und den fehlgeschlagenen Ersatz, bevor Sie etwas ändern. Benennen Sie dann den Vorgang genau: IKE-SA-Rekey, IKE-Reauthentifizierung und CHILD-SA-Rekey sind drei verschiedene Ereignisse, und „Phase 2“ deckt sie im Alltag alle ab.

Vergleichen Sie die folgenden Felder für die Verbindung, die fehlgeschlagen ist, nicht für den Tunnel im Allgemeinen.

Öffnen Sie auf dem FortiGate den Phase-2-Vorschlag, die PFS-Einstellung und die akzeptierten DH-Gruppen für diesen Tunnel. Lesen Sie die geladenen Werte, statt sie aus einer früher aufgebauten Verbindung abzuleiten. Ein Screenshot der GUI-Seite ist schwächere Evidenz als die laufende Konfiguration, weil beide nach einem Upgrade auseinandergehen können. Exportieren Sie den geänderten Abschnitt und bewahren Sie ihn mit dem Ticket auf.

Azures Standardrichtlinie ist immer noch eine Richtlinie

Keine an die Verbindung angehängte benutzerdefinierte Richtlinie bedeutet nicht, dass Azure keine anwendet. Die Verbindung fällt auf den Standardvorschlagssatz des Gateways zurück, der breiter oder enger sein kann als das, was Ihr FortiGate anbietet. Wenn sich die beiden Sätze für IKE, aber nicht für ESP mit PFS überschneiden, erhalten Sie genau dieses Fehlermuster.

Diese schreibgeschützte Ansicht zeigt die tatsächlich angehängte Richtlinie, ohne Geheimnisse auszugeben:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

Verwenden Sie Ihre echten Ressourcennamen. Wenn eine explizite Richtlinie nötig ist, legen Sie sie auf der Verbindungsressource fest. Sie ist kein gatewayweiter Schalter und gilt nicht stillschweigend für andere Tunnel am selben Gateway.

Im Portal ist die Seite Configuration dieser Verbindung der Ort, an dem eine benutzerdefinierte IPsec/IKE-Richtlinie hingehört. Microsofts Leitfaden für benutzerdefinierte Richtlinien listet die unterstützten Parameter und SKU-Anforderungen. Azure nimmt eine vollständige Kombination pro Verbindung, daher geben Sie die IKE-Felder und die IPsec-Felder zusammen an, nicht einzeln.

PFS ist eine Anforderung, kein Schalter zum Umlegen

Wenn Ihre Sicherheitsgrundlinie PFS verlangt, ist die Lösung eine Gruppe, die beide Peers auf beiden Seiten akzeptieren, ausgedrückt durch eine passende Richtlinie. PFS abzuschalten, damit der Fehler verschwindet, ändert die Sicherheitseigenschaft, die Sie erhalten wollten, und sie taucht später meist als andere Abweichung wieder auf.

Eine Azure-spezifische Falle: Wenn Sie GCM für ESP wählen, müssen die Verschlüsselungs- und Integritätsauswahl denselben GCM-Algorithmus und dieselbe Schlüssellänge nennen. Ein GCM-Chiffre mit einem separaten Integritätsalgorithmus zu mischen, erzeugt eine Kombination, die der Dienst ablehnt, und das sieht wie eine Peer-Abweichung aus, bis Sie die Richtlinie genau lesen.

Wählen Sie die stärkste Kombination, die beide Enden unterstützen und Ihre Anforderung zulässt, und schreiben Sie sie dann in den Änderungsdatensatz. Die nächste Person wird mit diesem Datensatz vergleichen, nicht mit der Erinnerung an einen funktionierenden Tunnel. Tragen Sie die PFS-Gruppe und den ESP-Vorschlag ein, nicht nur den Richtliniennamen. Wenn später jemand fragt, warum ein Audit fehlgeschlagen ist oder warum ein Rekey langsam ist, beantwortet diese Zeile beide Fragen.

Überprüfen Sie den fehlgeschlagenen Austausch

Planen Sie die Änderung mit einem Rückweg, denn das Bearbeiten der Richtlinie kann den Tunnel unterbrechen, den Sie reparieren wollen. Warten Sie nach der Rückkehr des Verkehrs auf eine CHILD_SA-Erneuerung oder lösen Sie sie aus, und bestätigen Sie, dass die neue Assoziation mit der vorgesehenen PFS-Gruppe aufgebaut wird. Bestätigen Sie dann, dass Anwendungsverkehr weiter darüber läuft.

Zwei Irrwege verdienen es, benannt zu werden. SA-Lebensdauern sind lokale Festlegungen, ungleiche Werte sind also normal, und sie zu ändern verschiebt nur, wann das Problem auftritt. DPD erkennt, ob ein Peer lebt; eine höhere Zeitgrenze bringt ESP- oder PFS-Auswahl nicht in Einklang.

Halten Sie das ausgehandelte Ergebnis und das nächste Ereignis nach der Änderung fest. Wenn die Verbindung jetzt scheitert, bevor die IKE-Authentifizierung abgeschlossen ist, sehen Sie auf die IKE-Einstellungen, die Sie gerade bearbeitet haben, nicht auf den ursprünglichen CHILD-Erneuerungsfehler.