FortiGate Azure-rekey: peer SA-voorstel past niet bij het lokale beleid

De tunnel kwam op, het verkeer liep, en later staat er in het log peer SA proposal not match local policy. De meeste mensen lezen die regel als bewijs dat de twee configuraties nooit overeenkwamen. Meestal betekent hij iets smallers: ze kwamen overeen voor de eerste CHILD SA en stopten met overeenkomen bij de eerste vernieuwing, omdat de eerste associatie nooit de uitwisseling nodig had die latere wel doen. Dat onderscheid bepaalt waar je moet kijken.

De eerste CHILD SA erft, latere onderhandelen

In IKEv2 wordt de eerste CHILD SA aangemaakt tijdens IKE_AUTH en de sleutels worden afgeleid van het sleutelmateriaal van de IKE SA. Op dat moment is er geen aparte Diffie-Hellman-uitwisseling, dus een PFS-groep die de ene peer niet kan accepteren wordt simpelweg nog niet getest. De tunnel lijkt gezond omdat de eis waarop je later zult falen nooit is getest.

Een CHILD_SA-rekey is een andere berichtensequentie. Als PFS is geconfigureerd, voeren de peers een nieuwe sleuteluitwisseling uit en moeten ze het eens worden over een groep die beide kanten accepteren, plus het ESP-voorstel voor de nieuwe associatie. Dat is het moment waarop de afwijking zichtbaar wordt, en daarom noemt de fout een voorstel in plaats van een route.

Dus “het werkte gisteren” zegt je niets over het voorstel. Het zegt dat de eerste uitwisseling slaagde, wat je al wist.

Lees de mislukte uitwisseling, niet de eerste ping

Verzamel van beide kanten de geslaagde IKE-authenticatie, de eerste CHILD SA en de mislukte vervanging voordat je iets wijzigt. Benoem daarna de bewerking precies: IKE SA-rekey, IKE-herauthenticatie en CHILD SA-rekey zijn drie verschillende gebeurtenissen, en “fase 2” dekt ze allemaal in gewone gesprekken.

Vergelijk de velden hieronder voor de verbinding die mislukte, niet voor de tunnel in het algemeen.

Open op de FortiGate het fase-2-voorstel, de PFS-instelling en de geaccepteerde DH-groepen voor die tunnel. Lees de geladen waarden in plaats van ze af te leiden uit een verbinding die eerder tot stand kwam. Een schermafbeelding van de GUI-pagina is zwakker bewijs dan de draaiende configuratie, omdat beide na een upgrade kunnen verschillen. Exporteer de sectie die je hebt gewijzigd en bewaar die bij het ticket.

Het standaardbeleid van Azure is nog steeds beleid

Geen aangepast beleid dat aan de verbinding is gekoppeld betekent niet dat Azure er geen toepast. De verbinding valt terug op de standaardset voorstellen van de gateway, die breder of smaller kan zijn dan wat je FortiGate biedt. Als de twee sets overlappen voor IKE maar niet voor ESP met PFS, krijg je precies dit faalpatroon.

Deze alleen-lezen-weergave toont het beleid dat werkelijk is gekoppeld, zonder geheimen prijs te geven:

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

Gebruik je echte resourcenamen. Als een expliciet beleid nodig is, stel het dan in op de verbindingsresource. Het is geen schakelaar voor de hele gateway en het geldt niet stilzwijgend voor andere tunnels op dezelfde gateway.

In de portal is de pagina Configuration van die verbinding de plek waar een aangepast IPsec/IKE-beleid hoort. Microsofts handleiding voor aangepast beleid somt de ondersteunde parameters en SKU-vereisten op. Azure neemt één volledige combinatie per verbinding, dus je geeft de IKE-velden en de IPsec-velden samen op, niet één voor één.

PFS is een vereiste, geen schakelaar om om te zetten

Als je beveiligingsbasislijn PFS vereist, is de oplossing een groep die beide peers aan beide kanten accepteren, uitgedrukt via een overeenkomend beleid. PFS uitzetten om de fout te laten verdwijnen verandert de beveiligingseigenschap die je probeerde te behouden, en die komt later meestal terug als een andere afwijking.

Eén Azure-specifieke valkuil: als je GCM voor ESP kiest, moeten de versleutelings- en integriteitskeuzes hetzelfde GCM-algoritme en dezelfde sleutellengte noemen. Een GCM-cijfer met een apart integriteitsalgoritme mengen levert een combinatie op die de dienst weigert, en dat lijkt op een afwijking tussen peers tot je het beleid aandachtig leest.

Kies de sterkste combinatie die beide uiteinden ondersteunen en je vereiste toestaat, en schrijf die dan op in het wijzigingsrecord. De volgende persoon vergelijkt met dat record, niet met de herinnering aan een werkende tunnel. Zet de PFS-groep en het ESP-voorstel erin, niet alleen de naam van het beleid. Als iemand later vraagt waarom een audit mislukte of waarom een rekey traag is, beantwoordt die regel beide vragen.

Controleer de uitwisseling die mislukte

Plan de wijziging met een herstelpad, want het bewerken van het beleid kan de tunnel onderbreken die je probeert te repareren. Wacht nadat het verkeer terugkeert op een CHILD_SA-vernieuwing of lok die uit, en bevestig dat de nieuwe associatie met de beoogde PFS-groep tot stand komt. Bevestig daarna dat applicatieverkeer er dwars doorheen blijft lopen.

Twee dwaalsporen zijn het noemen waard. SA-levensduren zijn lokale specificaties, dus ongelijke waarden zijn normaal en ze wijzigen verschuift alleen wanneer het probleem optreedt. DPD detecteert of een peer leeft; het verhogen van de time-out brengt ESP- of PFS-keuzes niet op één lijn.

Leg het onderhandelde resultaat en de volgende gebeurtenis na de wijziging vast. Als de verbinding nu mislukt voordat de IKE-authenticatie is voltooid, kijk je naar de IKE-instellingen die je zojuist hebt bewerkt, niet naar de oorspronkelijke CHILD-vernieuwingsfout.