FortiGate Azure rekey: a proposta peer SA não corresponde à política local
Um túnel IKEv2 funcional ainda pode rejeitar a CHILD SA de substituição. Compare a proposta que a renovação realmente negocia, não a que o primeiro ping usou.
O túnel subiu, o tráfego fluiu e mais tarde o log diz peer SA proposal not match local policy. A maioria das pessoas lê essa linha como prova de que as duas configurações nunca coincidiram. Normalmente significa algo mais estreito: coincidiram para a primeira CHILD SA e deixaram de coincidir na primeira renovação, porque a primeira associação nunca precisou da troca que as seguintes fazem. É essa distinção que decide onde olhar.
A primeira CHILD SA herda, as seguintes negociam
No IKEv2, a CHILD SA inicial é criada durante o IKE_AUTH e suas chaves são derivadas do material de chaves do IKE SA. Nesse momento não há uma troca Diffie-Hellman separada, então um grupo PFS que um dos peers não consegue aceitar simplesmente ainda não é testado. O túnel parece saudável porque o requisito em que você falhará depois nunca foi testado.
Um rekey de CHILD_SA é outra sequência de mensagens. Quando o PFS está configurado, os peers executam uma nova troca de chaves e precisam concordar com um grupo aceito pelos dois lados, além da proposta ESP para a nova associação. É o momento em que a divergência se torna visível, e por isso o erro nomeia uma proposta e não uma rota.
Então “ontem funcionava” não diz nada sobre a proposta. Diz que a troca inicial foi bem-sucedida, o que você já sabia.
Leia a troca que falhou, não o primeiro ping
Reúna a autenticação IKE bem-sucedida, a CHILD SA inicial e a substituição que falhou dos dois lados antes de mudar qualquer coisa. Depois nomeie a operação com precisão: o rekey do IKE SA, a reautenticação IKE e o rekey da CHILD SA são três eventos diferentes, e “fase 2” cobre todos eles na conversa comum.
Compare os campos abaixo para a conexão que falhou, não para o túnel em geral.
| Camada | Valores a comparar |
|---|---|
| IKE | Versão, criptografia e integridade ou disposição PRF, grupo DH |
| IPsec / CHILD | Criptografia e integridade ESP, grupo PFS ou de troca de chaves pretendido |
| Tráfego protegido | Seletores locais e remotos, além de qualquer ajuste de seletor baseado em política |
No FortiGate, abra a proposta de fase-2, o ajuste de PFS e os grupos DH aceitos para esse túnel. Leia os valores carregados em vez de inferi-los de uma conexão estabelecida antes. Uma captura da página da GUI é evidência mais fraca que a configuração em execução, porque as duas podem divergir após uma atualização. Exporte a seção que você alterou e guarde-a com o ticket.
A política padrão do Azure continua sendo uma política
Não haver uma política personalizada anexada à conexão não significa que o Azure não aplique nenhuma. A conexão recorre ao conjunto de propostas padrão do gateway, que pode ser mais amplo ou mais estreito do que o que seu FortiGate oferece. Se os dois conjuntos se sobrepõem para IKE mas não para ESP com PFS, você obtém exatamente este padrão de falha.
Esta visão somente leitura mostra a política realmente anexada, sem revelar segredos:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesUse os nomes reais dos seus recursos. Quando uma política explícita for necessária, defina-a no recurso da conexão. Não é um interruptor de todo o gateway e não se aplica silenciosamente a outros túneis no mesmo gateway.
No portal, a página Configuration dessa conexão é onde vai uma política IPsec/IKE personalizada. O guia da Microsoft sobre políticas personalizadas lista os parâmetros suportados e os requisitos de SKU. O Azure considera uma combinação completa por conexão, então você especifica os campos IKE e os campos IPsec juntos, não um de cada vez.
PFS é um requisito, não um interruptor para virar
Se sua linha de base de segurança exige PFS, a solução é um grupo que ambos os peers aceitam dos dois lados, expresso por uma política correspondente. Desligar o PFS para fazer o erro desaparecer muda a propriedade de segurança que você tentava manter, e ela normalmente reaparece mais tarde como outra divergência.
Uma armadilha específica do Azure: ao escolher GCM para ESP, as seleções de criptografia e integridade precisam nomear o mesmo algoritmo GCM e o mesmo comprimento de chave. Misturar uma cifra GCM com um algoritmo de integridade separado produz uma combinação que o serviço rejeita, e isso parece uma divergência entre peers até você ler a política com atenção.
Escolha a combinação mais forte que ambos os lados suportam e que seu requisito permite, depois registre-a no registro de mudanças. A próxima pessoa vai comparar com esse registro, não com a memória de um túnel que funcionava. Inclua o grupo PFS e a proposta ESP, não apenas o nome da política. Quando alguém perguntar mais tarde por que uma auditoria falhou ou por que um rekey está lento, essa linha responde às duas perguntas.
Verifique a troca que falhou
Planeje a mudança com um caminho de recuperação, porque editar a política pode interromper o túnel que você está tentando consertar. Depois que o tráfego voltar, aguarde ou dispare uma renovação de CHILD_SA e confirme que a nova associação é estabelecida com o grupo PFS pretendido. Em seguida, confirme que o tráfego de aplicações continua passando por ela.
Dois indícios falsos merecem ser nomeados. As durações das SA são especificações locais, então valores desiguais são normais e alterá-los apenas desloca quando o problema aparece. O DPD detecta se um peer está vivo; aumentar o tempo limite não alinha as escolhas de ESP nem de PFS.
Registre o resultado negociado e o próximo evento após a mudança. Se a conexão agora falha antes de a autenticação IKE ser concluída, você está olhando as configurações de IKE que acabou de editar, não a falha original de renovação da CHILD.