FortiGate Azure rekey: la proposta peer SA non corrisponde alla policy locale

Il tunnel è salito, il traffico è passato e più tardi il registro dice peer SA proposal not match local policy. La maggior parte delle persone legge quella riga come prova che le due configurazioni non sono mai corrisposte. Di solito significa qualcosa di più stretto: corrispondevano per la prima CHILD SA e hanno smesso di corrispondere al primo rinnovo, perché la prima associazione non ha mai avuto bisogno dello scambio che fanno le successive. È quella distinzione a decidere dove guardare.

La prima CHILD SA eredita, le successive negoziano

In IKEv2 la CHILD SA iniziale viene creata durante IKE_AUTH e le sue chiavi sono derivate dal materiale di chiave dell’IKE SA. In quel momento non c’è uno scambio Diffie-Hellman separato, quindi un gruppo PFS che un peer non può accettare semplicemente non viene ancora provato. Il tunnel sembra sano perché il requisito su cui fallirete più avanti non è mai stato testato.

Un rekey di CHILD_SA è una sequenza di messaggi diversa. Quando PFS è configurato, i peer eseguono un nuovo scambio di chiavi e devono accordarsi su un gruppo accettato da entrambi i lati, oltre che sulla proposta ESP per la nuova associazione. È il momento in cui la discrepanza diventa visibile, ed è per questo che l’errore nomina una proposta e non una rotta.

Quindi «ieri funzionava» non vi dice nulla sulla proposta. Vi dice che lo scambio iniziale è riuscito, cosa che già sapevate.

Leggete lo scambio fallito, non il primo ping

Raccogliete l’autenticazione IKE riuscita, la CHILD SA iniziale e la sostituzione fallita da entrambi i lati prima di cambiare qualcosa. Poi nominate l’operazione con precisione: il rekey dell’IKE SA, la riautenticazione IKE e il rekey della CHILD SA sono tre eventi diversi, e «fase 2» li copre tutti nella conversazione quotidiana.

Confrontate i campi seguenti per la connessione che ha fallito, non per il tunnel in generale.

Su FortiGate, aprite la proposta di fase-2, l’impostazione PFS e i gruppi DH accettati per quel tunnel. Leggete i valori caricati invece di dedurli da una connessione stabilita in precedenza. Uno screenshot della pagina GUI è una prova più debole della configurazione in esecuzione, perché i due possono divergere dopo un aggiornamento. Esportate la sezione che avete modificato e conservatela con il ticket.

La policy predefinita di Azure resta una policy

L’assenza di una policy personalizzata collegata alla connessione non significa che Azure non ne applichi nessuna. La connessione ricade sull’insieme di proposte predefinite del gateway, che può essere più ampio o più ristretto di ciò che offre il vostro FortiGate. Se i due insiemi si sovrappongono per IKE ma non per ESP con PFS, ottenete esattamente questo schema di errore.

Questa vista di sola lettura mostra la policy realmente collegata, senza esporre segreti:

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

Usate i nomi reali delle vostre risorse. Quando serve una policy esplicita, impostatala sulla risorsa di connessione. Non è un interruttore a livello di gateway e non si applica silenziosamente agli altri tunnel dello stesso gateway.

Nel portale, la pagina Configuration di quella connessione è il punto in cui va una policy IPsec/IKE personalizzata. La guida di Microsoft sulle policy personalizzate elenca i parametri supportati e i requisiti SKU. Azure prende una combinazione completa per connessione, quindi specificate insieme i campi IKE e i campi IPsec, non uno alla volta.

PFS è un requisito, non un interruttore da girare

Se la vostra baseline di sicurezza richiede PFS, la soluzione è un gruppo che entrambi i peer accettano su entrambi i lati, espresso tramite una policy corrispondente. Disattivare PFS per far sparire l’errore cambia la proprietà di sicurezza che cercavate di mantenere, e di solito ricompare più tardi come un’altra discrepanza.

Una trappola specifica di Azure: quando scegliete GCM per ESP, le selezioni di cifratura e integrità devono indicare lo stesso algoritmo GCM e la stessa lunghezza di chiave. Mescolare un cifrario GCM con un algoritmo di integrità separato produce una combinazione che il servizio rifiuta, e sembra una discrepanza tra peer finché non leggete la policy con attenzione.

Scegliete la combinazione più forte che entrambe le estremità supportano e che il vostro requisito consente, poi scrivetela nel registro delle modifiche. La persona successiva confronterà con quel registro, non con il ricordo di un tunnel funzionante. Inserite il gruppo PFS e la proposta ESP, non solo il nome della policy. Quando qualcuno chiederà più tardi perché un audit è fallito o perché un rekey è lento, quella riga risponde a entrambe le domande.

Verificate lo scambio fallito

Pianificate la modifica con un percorso di ripristino, perché modificare la policy può interrompere il tunnel che state cercando di riparare. Quando il traffico torna, aspettate o provocate un rinnovo di CHILD_SA e confermate che la nuova associazione è stabilita con il gruppo PFS previsto. Poi confermate che il traffico applicativo continua attraverso di essa.

Due piste false meritano di essere nominate. Le durate delle SA sono specifiche locali, quindi valori disuguali sono normali e cambiarli sposta solo quando il problema compare. DPD rileva se un peer è vivo; alzare il suo timeout non allinea le scelte ESP o PFS.

Registrate il risultato negoziato e l’evento successivo dopo la modifica. Se ora la connessione fallisce prima che l’autenticazione IKE sia completata, state guardando le impostazioni IKE appena modificate, non il guasto originale di rinnovo della CHILD.