VPN Gateway: Connection Did Not Resume After Gateway Maintenance — Troubleshooting Connectivity Issues

Question

VPN Gateway: Connection Did Not Resume After Gateway Maintenance — Troubleshooting Connectivity Issues

Marius Geldenhuys 0

Problem description

I am experiencing an issue with my Azure VPN Gateway where the site-to-site VPN connection to my on-premises Fortinet device did not reconnect after scheduled maintenance or failover events on 2026-10-16. Despite the maintenance completing successfully, my VPN tunnel remains disconnected, and I need assistance to resolve this connectivity problem.

Environment

The affected environment includes an Azure VPN Gateway used for a Site-to-Site VPN connection, with an on-premises VPN device running FortiOS 5.6. The region is not specified in the case information.

What I've already tried

Based on the provided case details, I have not attempted any troubleshooting steps yet.

Current status

I am seeking guidance on how to troubleshoot and resolve the VPN tunnel disconnection following the gateway maintenance, including verifying the gateway's health, tunnel configuration, and peer settings.

Marius Geldenhuys 0 Reputation points

2026-10-17T14:20:59.7166667+00:00
We have done troubleshooting and the issue is not the on prem firewall and we did not make changes jsut getting AI SLOP answers from MSFT. Here is what we could confirmed.

No changes to PSK’s were made by my team on the Azure side and the following findings noted as well.

The GMR firewall shows no established tunnel to Azure from 06:15:20 to 12:31:04 CDT. Details are below and in the attached log excerpt.

Facts (all times CDT, UTC-5):

The tunnel was established on Saturday, October 10 at 15:16:12. It ran for 5 days, 14 hours, and 59 minutes with 18 successful rekeys and no failed negotiations or errors.

GMR made no changes to the Nintex tunnel configuration, including phase 1, phase 2, and the pre-shared key, between 15:16:09 on October 10 and 08:48:54 on October 16. The GMR firewall logged no administrator sessions from 23:11 on October 15 to 08:44 on October 16. The failure occurred at 06:15:20. The configuration-change audit is in sections 16 to 18 of the attached excerpt.

Peer-initiated rekeys occurred about every 7 hours 5 minutes. The rekey expected near 22:53 on October 15 did not occur. The next rekey was at 05:41:09 on October 16.

The last successful negotiation with the peer was at 06:12:20. Dead peer detection failed at 06:15:20 and the tunnel dropped.

From 06:15:21 to 12:26:43, the GMR firewall sent 712 negotiation attempts. The peer answered each with NO-PROPOSAL-CHOSEN.

From 06:15:42 to 12:26:30, the GMR firewall received 1,212 negotiation attempts from the peer. It rejected each with "peer SA proposal not match local policy."

An IKE debug capture of an inbound attempt shows the peer offering only DH Group 2 (MODP1024), with AES-256, AES-128, or 3DES and SHA-1 or SHA-256. The GMR gateway required AES-256, SHA-1, and DH Group 14 (MODP2048). This configuration was still in place.

That proposal set is consistent with an Azure default IKEv2 policy, not the custom policy configured on the tunnels. This is GMR's inference. Please confirm or correct it.

At 08:48:54, GMR added DH Group 2 to its accepted groups. Peer attempts then passed proposal selection and failed at authentication with a probable pre-shared key mismatch. GMR removed Group 2 at 08:53:15.

At 12:26:48, GMR added Group 2 again. At 12:30:59, GMR reapplied the pre-shared key used before October 10. The tunnel came up at 12:31:04.

Another IPsec tunnel on the same firewall logged no errors during this period.

Your side shows the tunnels as up and connected on DH14. The GMR firewall shows no established tunnel for the same period, and the tunnel returned only on the pre-October 10 values. These two views need to be reconciled.

The issue was clearly due to the maintenance of the gateway as no other human interaction was done after the fact and there was no need to either so saying its not the maintenance with provided evidence is not accurate.

1 answer

Your answer

Answer 1

Thank you for providing the detailed Fortinet logs, IKE debug captures, configuration audit, and timeline. We sincerely apologize for the inconvenience caused by the prolonged VPN connectivity interruption and for our earlier responses, which did not fully address the evidence you shared.

After reviewing the information, I would like to summarize our current findings.

The evidence indicates that the Site-to-Site VPN tunnel was functioning normally before the Azure VPN Gateway maintenance/failover event. It had remained established for more than five days and completed 18 rekeys without negotiation failures. We also understand that no Phase 1, Phase 2, or pre-shared key configuration changes were made on the GMR Fortinet firewall before the incident, and that no administrator activity coincided with the failure.

The last successful negotiation occurred at approximately 06:12:20 CDT on October 16. This was followed by a Dead Peer Detection failure at 06:15:20 CDT, after which the tunnel went down.

From approximately 06:15 to 12:31 CDT, the following behavior was observed:

The GMR firewall sent 712 outgoing negotiation attempts, all of which received NO-PROPOSAL-CHOSEN responses.
The GMR firewall received approximately 1,212 negotiation attempts from the Azure peer; these were rejected because the peer SA proposal did not match the local policy.
The IKE debug capture showed the peer proposing DH Group 2 (MODP1024) with AES-256/AES-128/3DES and SHA-1/SHA-256.
Before the incident, the GMR configuration had successfully operated with AES-256, SHA-1, and DH Group 14 (MODP2048).
The customer-side configuration had not changed before the VPN failure. The negotiation mismatch therefore occurred after the tunnel had already been operating successfully with the existing configuration.

Microsoft documentation confirms that the default Azure VPN Gateway IKEv2 policy includes DH Group 2, while a custom IPsec/IKE policy can specify DH Group 14. The DH Group 2 proposal captured from the peer is therefore consistent with Azure default-policy behavior. However, further Microsoft-side investigation is needed before we can determine why DH Group 2 was proposed when the connection was expected to use the custom DH Group 14 policy.

We also observed that DH Group 2 was temporarily permitted on the GMR side at 08:48:54 CDT. Negotiation then progressed beyond proposal selection but encountered an authentication issue consistent with a possible PSK mismatch. DH Group 2 was permitted again at 12:26:48 CDT, and the previously used PSK was reapplied at 12:30:59 CDT. The tunnel subsequently became established at approximately 12:31:04 CDT.

These customer-side changes were troubleshooting actions taken after the original tunnel failure. They therefore do not explain why the previously functioning tunnel initially failed.

Based on the evidence currently available, we do not have sufficient information to attribute the original incident to an independent Fortinet configuration change. Instead, the timeline shows a clear relationship between the Azure VPN Gateway maintenance/failover activity and the subsequent inability of the tunnel to renegotiate using its previously working configuration.

Our current assessment is that the Azure VPN Gateway maintenance/failover was the triggering event. The precise reason the Azure peer subsequently exhibited different IKE negotiation behavior, however, still requires Microsoft-side validation.

Specifically, we need to reconcile the following points:

Why the peer proposed DH Group 2 even though the connection was expected to use the configured DH Group 14 custom policy.
Whether the custom IPsec/IKE policy was correctly loaded and synchronized across the VPN Gateway instances after the maintenance/failover.
Whether both gateway instances had the same effective connection and PSK state.
Why the Azure side showed the tunnel as connected/DH14 while the Fortinet logs showed no established tunnel between 06:15:20 and 12:31:04 CDT.
Why the tunnel recovered only after DH Group 2 was permitted and the previously used PSK was reapplied.

Microsoft documentation also confirms that, when a custom IPsec/IKE policy is configured, the complete policy combination is applied to the connection and incompatible policies prevent the S2S VPN connection from establishing.

Accordingly, rather than repeating on-premises configuration troubleshooting that has already been completed, the next appropriate step is to continue the Microsoft-side gateway-instance and configuration-state investigation to determine why post-maintenance negotiation behavior differed from the previously working state.Thank you for providing the detailed Fortinet logs, IKE debug captures, configuration audit, and timeline. We sincerely apologize for the inconvenience caused by the prolonged VPN connectivity interruption and for our earlier responses, which did not fully address the evidence you shared.