Phase 2 not connecting after adding NAT rules to Connection

Hi Guilherme Alcântara Dias

Olá Guilherme Alcântara Dias,

Bem-vindo à plataforma Microsoft Q&A.

Estou traduzindo o conteúdo do inglês para o português. Por favor, desconsidere quaisquer erros gramaticais.

Com base no comportamento descrito, parece que a conexão da Fase 2 começou a falhar após a adição da regra dinâmica de Egress SNAT. Isso normalmente acontece quando o Azure e a VPN local (on-premises) estão esperando intervalos de tráfego diferentes durante a negociação do túnel, o que resulta no erro “error 87 (The parameter is incorrect)”.

Você definiu:

• InternalMapping = 172.x.x.8/27
• ExternalMapping = 172.x.x.XXX/32

Esse intervalo externo /32 não corresponde mais ao que sua VPN local estava esperando (foi configurado para permitir 172.x.x.0/23). Quando o Azure aplica a regra NAT, ele anuncia um seletor /32 para a sub-rede do lado do Azure, enquanto o dispositivo remoto ainda espera o intervalo completo /23, fazendo com que a Fase 2 não seja estabelecida.

Verifique a configuração abaixo para corrigir essa incompatibilidade:

Validar o tipo de mapeamento NAT

As regras de NAT dinâmico são indicadas para cenários em que você possui um conjunto interno menor e um conjunto externo maior (permitindo que o Azure utilize qualquer IP disponível). Mapear um /27 para um único /32 quebra esse modelo.

Se você realmente precisa apenas de um IP traduzido, utilize uma regra SNAT estática 1:1 e mantenha o mesmo tamanho de prefixo (/32 → /32).

Alinhar os seletores de tráfego em ambos os lados

Opção A: Altere o ExternalMapping na regra NAT para cobrir o mesmo intervalo /23 permitido pelo firewall local (por exemplo: 172.x.x.0/23).

Opção B: Atualize o Local Network Gateway local (ou dispositivo remoto) para aceitar o host /32 como sub-rede do lado do Azure. Reassociar e validar a regra

Após corrigir a regra NAT:

Remova a regra existente.

Recrie ou atualize a regra no gateway (certifique-se de usar um SKU compatível: VpnGw2–5 ou VpnGw2AZ–5AZ).

Associe a regra NAT à conexão VPN conforme abaixo:

$natrule = New-AzVpnGatewayNatRule -ResourceGroupName RG -ParentResourceName MyVNetGW `
-Name MyEgressSNAT `
-InternalMapping 172.x.x.0/23 `
-ExternalMapping 172.x.x.0/23 `
-Type Static `
-Mode EgressSnat

$conn = Get-AzVpnConnection `
-Name MyConnection `
-ResourceGroupName RG `
-ParentResourceName MyVNetGW

$conn.VpnLinkConnections[0].EgressNatRules = $natrule

Update-AzVpnConnection `
-Name MyConnection `
-ResourceGroupName RG `
-ParentResourceName MyVNetGW `
-VpnSiteLinkConnection $conn.VpnLinkConnections

Confirme no portal em Virtual Network Gateway → NAT Rules que a regra está vinculada à conexão e, em seguida, verifique em Connections até que o status seja exibido como Connected.

Verifique novamente o modo do gateway

Você mencionou ResponderOnly — isso é suportado, porém significa que o lado local precisa propor seletores que correspondam exatamente ao que o Azure está anunciando após o NAT. Qualquer diferença fará com que a Fase 2 falhe.

Por favor, deixe um upvote se esta informação ajudou. Isso ajuda tanto a nós quanto outros membros da comunidade.

Hello Vallepu Venkateswarlu, thanks for answering

For some reason this forum is blocking the IP ranges even though they are private network ranges. From your suggestion I tried asking my client to add all /32 IP's to the liberation instead of 172.24.0.0/23 and it still not worked. I tried returning to Default mode instead of ResponderOnly but nothing changed. Then I tried doing an static egress NAT rule map for network 172.24.1.0/27 and asked the client to add that to his liberations and just the same that did not work. I also confirmed with him there were no policy based traffic selectors on his side

Before talking to the client I also tried creating an static Egress NAT Rule for /23 range to match the exact ranges and it did not work.

Lastly I didn't understand your suggestion about adding my own IP's to the Local Network Gateway since that part should be only the client networks

For the record since you mentioned it my SKU is VpnGW2AZ and my client is using a Fortigate but I don't know the exact version

Hi @ Guilherme Alcântara Dias,

Thanks for sharing the update.

Could you please enable the diagnostic logs and use them to troubleshoot the Azure VPN Gateway issue? You can also try resetting the VPN Gateway to see if the tunnel re-establishes correctly after the reset.

Once completed, please share any relevant log entries or error messages related to the Phase 2 negotiation failure so we can investigate further.

Once the logs are enabled, please share the relevant log in private message related to the Phase 2 negotiation failure so we can analyze the issue further.
Ref: Troubleshoot an Azure site-to-site VPN connection that can't connect and stops working**

Hello again,

I tried resetting both the connection and the whole VPN. It was no use and my alloted time ended so we had to do a different resolution.

We created a normal subnet with the 172.24.1.0/24 and are currently migrating every app services to it across different enviroments. The next S2S we create is going to be the internal network address since NAT rules did not work at all and we are returning the VPN to VpnGwAZ1. I didn't mentioned that before but that maybe related, since we originally had an VpnGw1 VPN and upgraded it to VpnGwAZ2 to use the rules but that is perhaps the mysterious reason it didn't work at all

Anyways, thanks for the time and answer, best regards