IPSec tunnel is down

[sean3]

hi all,

trying to create site to site ipsec vpn with the other site on Azure virtual gateway, the tunnel is down and i follow the article https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-IPsec-VPNs-tunnels/ta-p/195955 to troubleshoot, I got the log as below screenshot when doing step Confirm that IKE traffic for port 500 or 4500 is not blocked somewhere along the path. does it mean that it is so good so far to the step? what is UDP 384 there?

[ozkanaltas]

Hello @sean3 ,

As per your screenshot, the Azure side is not responding to your ipsec package. Did you do all the configuration on the Azure side? 

If you say yes, can you run these debug commands for ipsec debugging? After running these commands can you trigger the tunnel by using the bring-up button?

diag debug disable
diag debug reset
diag vpn ike log-filter clear
diag vpn ike log-filter name <IPSEC_NAME>
diag debug application ike -1
diag debug enable

[sean3]

thanks for the help!

since Azure is managed by other team I will check it when they are available.

[sean3]

after re-creation from Azure side, the tunnel was up for a while, but later it went down again. will check further.

[sean3]

(we have 4 sites as spoke connecting to Azure, 3 of which are in West europe, 1 is in China. In this case, we are talking about China site, it is an ipsec to Azure East Asia).

I compared several things across sites, the only different thing is the tun_id displayed by command show vpn ipsec phase1-interface. All other 3 sites are displaying the remote-gateway IP as well as the public IP of virtual gateway in Azure west europe, as their tun_id.

But China site is also displaying the same IP (PIP of vgw from West europe) as the tun_id, though we explicitly configured the public ip of VWG residing in Azure East-Asia as the remote gateway IP for China Firewall.

but it is said tun_id is just an identifier in this article, nothing matters.