VPN Gateway Connection is Unknown

Handian Sudianto 7,471 Reputation points
2026-09-18T00:00:45.2666667+00:00

I try to add another site to site using azure vpn gateway and my fortigate. But in this new vpn gateway the connection always in state 'unknown' and from my fortigate i can see timeout.

I do packet sniffer to the new vpn gateway and found there is no return traffic from azure to my fotigate and if i compare to the existing working vpn gateway then i can see the return traffic.

How i can investigate this from azure side?

User's image

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.

0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Handian Sudianto 7,471 Reputation points
    2026-09-18T11:41:19.56+00:00

    hi @SHOUMIK CHAKRAVARTY i found the issue, my peer ip is overlap wioth the gateway subnet on azure. Change the peer ip on my onprem then the vpn is working.

    Was this answer helpful?

    1 person found this answer helpful.
  2. SHOUMIK CHAKRAVARTY 660 Reputation points
    2026-09-18T02:31:22.3766667+00:00

    The Azure side of this lives in IKEDiagnosticLog. Turn on diagnostic settings for the gateway pointed at a Log Analytics workspace, then run the query from Troubleshoot Azure VPN Gateway using diagnostic logs:

    
AzureDiagnostics 

| where Category == "IKEDiagnosticLog" 

| extend Message1=Message

| parse Message with * "Remote " RemoteIP ":" * "500: Local " LocalIP ":" * "500: " Message2

| extend Event = iif(Message has "SESSION_ID",Message2,Message1)

| project TimeGenerated, RemoteIP, LocalIP, Event, Level 

| sort by TimeGenerated asc

    Filter RemoteIP to your FortiGate’s public address. In the IKEDiagnosticLog, every event is prefixed by who acted: [RECEIVED] means Azure got a packet from your on‑premises device, and [SEND] means Azure sent one.

    That’s the part your packet capture can’t tell you. If you see [RECEIVED] entries for that IP, Azure is getting your SA_INIT, so the issue is in the negotiation. Look for the entry where rCookie = 0 which marks the start of each attempt. If you see nothing at all for that IP, Azure never received the packets. In that case, the shared key and IPsec policy don’t matter yet; the question becomes whether Azure has the same peer address you see as the source in your capture.

    You also don’t need to time the capture. Azure retries every few seconds while a tunnel is failing, so there’s always a fresh negotiation in the logs.

    One thing to check first: policy‑based gateways only produce GatewayDiagnosticLog and RouteDiagnosticLog. If this gateway is policy‑based, IKEDiagnosticLog won’t appear.

    For what it’s worth, your capture already rules out a couple of common causes. A shared‑key mismatch gets you a reply followed by an auth failure, and a proposal mismatch gets you a reply or a notify. Silence usually means the packets aren’t being matched to a known peer at all.

    Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-09-18T00:01:07.5166667+00:00

    From the Azure side, use this investigation path:

    1. Verify the VPN peer IPs.
      • In Azure, open the Local Network Gateway and confirm its IP matches the public IP of the FortiGate.
      • On the FortiGate, confirm the configured Azure peer IP matches the Azure VPN gateway public IP.
      • A mismatch here can leave the connection in Unknown or prevent IKE responses.
    2. Verify the shared key.
      • In Azure portal, go to VPN Gateway > Connections > open the affected connection.
      • Check Authentication Type and confirm the shared key matches the FortiGate configuration.
      • If needed, update and save the shared key.
      • PowerShell option: 
             Get-AzVirtualNetworkGatewayConnectionSharedKey -Name <Connection name> -ResourceGroupName <Resource group name>
    3. Check the gateway subnet for UDRs or NSGs.
      • Review the GatewaySubnet and remove any user-defined routes (UDR) or network security groups (NSGs) applied there, then test again.
      • An NSG or UDR on the gateway subnet can block or restrict VPN traffic and make the gateway appear unhealthy or unresponsive.
    4. Test the Azure gateway health probe.
      • Browse to: https://<YourVirtualNetworkGatewayIP>:8081/healthprobe
      • For active/active gateways, also test: https://<YourVirtualNetworkGatewayIP2>:8083/healthprobe
      • Click through the certificate warning.
      • If a response is returned, the Azure VPN gateway is considered healthy.
      • If no response is returned, the gateway might not be healthy, or an NSG on the gateway subnet might be causing the problem.
      • Note: Basic SKU VPN gateways do not reply to the health probe.
    5. Check whether the FortiGate public IP was added incorrectly to Azure address definitions.
      • If the FortiGate internet-facing IP is included in the Local network gateway address space definition in Azure, intermittent disconnections can occur.
    6. If this is a policy-based configuration, verify policy-specific settings.
      • Make sure Azure and FortiGate subnet definitions match exactly.
      • Verify Security Association settings match.
      • Ensure the device is configured for one VPN tunnel per subnet pair.
      • Keep total subnet Security Association pairs under the Azure limit of 200.
    7. Check Perfect Forward Secrecy on the FortiGate.
      • If Perfect Forward Secrecy is enabled on the on-premises device, disable it and then update the VPN gateway IPsec policy.
    8. Reset the tunnel.
      • First reset the Azure VPN gateway and reset the tunnel from the FortiGate side.
      • This is the documented first action when a site-to-site connection cannot connect or suddenly stops working.

    Given the packet capture shows FortiGate sending UDP 500/4500 with no return traffic from Azure, the highest-value Azure-side checks are:

    • peer IP mismatch
    • shared key mismatch
    • NSG/UDR on GatewaySubnet
    • failed Azure health probe

    If the Azure health probe succeeds and the gateway subnet has no NSG/UDR, focus next on FortiGate peer IP, shared key, and IPsec/IKE policy alignment.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.