Site to Site tunnel connects and then disconnects

Roger Parker 0 Reputation points
2024-04-22T23:00:29.3566667+00:00

Hi. Can anyone help with the error below displayed whilst trying to open a support ticket. I have issues with site to site connections dropping on a regular basis. Thanks.

Resolve site-to-site connectivity issues

Microsoft Azure identified a VPN re-connection for the tunnel xxx.xxx.xxx.xxx at 4/22/2024 12:40:52 PM UTC .

The reason of the reconnection was RemoteCrashTriggered.

In this scenario, the Azure VPN Gateway received a new SA_INIT request from the VPN peer, so a new Main Mode is established, and a new tunnel ID assigned. Then, the old Main Mode was deleted.

Recommended actions

If you're troubleshooting VPN issues at 4/22/2024 12:40:52 PM UTC, the issue may be on the remote side. Inspect the peer VPN device to understand why it originally asked for a new Main Mode without deleting the old one.

Azure VPN Gateway
Azure VPN Gateway
An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.
1,393 questions

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. GitaraniSharma-MSFT 47,591 Reputation points Microsoft Employee
    2024-04-23T17:48:05.7266667+00:00

    Hello @Roger Parker ,

    Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

    I understand that you are facing intermittent connection issue with Azure S2S VPN, where the vpn connections are dropping on a regular basis with the following error on Azure end: "RemoteCrashTriggered disconnection",

    Below is the explanation for "RemoteCrashTriggered" error -

    • Sometimes the on-premises device may decide to re-connect the VPN tunnel. In such cases, it may not be the case that the on-premises device would delete the active tunnel first but would just send a new request trying to establish a new Main Mode.
    • The assumption is that for some reason the VPN peer device crashed or completely lost its connection state. So, they can't honor anymore the already established Main Mode (and have no means to delete it).
    • This is a legitimate behavior. When Azure VPN Gateway receives a new request from a VPN peer, it will honor it. The new Main Mode will be established, and a new tunnel ID will be assigned. Then, the old Main Mode will be deleted.
    • When such a behavior happens, we (Azure) define it as RemoteCrashTriggered in our logs.
    • The above behavior is NOT an issue and is allowed by RFC. This only becomes an issue when, after creating the new Main Mode and deleting the old one, the on-premises device doesn't use the new Main Mode to send traffic.
    • Either way, in any scenario of failure post RemoteCrashTriggered, the issue is on the On-prem side, and the on-premises VPN device needs to be inspected to understand why it originally asked for a new Main Mode without deleting the old one.

    You have mentioned that the issue happens at a regular interval, I believe you can predict the next time this issue will happen and can enable some debug log on the on-premises side to find out if this is happening after the Main Mode is established and if the on-premises device has some failure in performing a Quick Mode rekey, which fails on on-premises side and triggers the On-prem device to resend a Main Mode rekey.

    Kindly let us know if the above helps or you need further assistance on this issue.

    Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

    0 comments