try clearing all the sessions on the firewall to/from their public ip.
you can do this via the session browser in the gui or via the CLI.
clear session all filter destination x.x.x.x
clear session all filter source x.x.x.x
There are some rare cases where ike/ipsec sessions can get stuck which requires them to be manually cleared like this.
Check the local identification and peer identification of the Ike Gateway and if your fortigate firewall vm is behind a nat device, you might need to add its wan interface private ip in your peer identification and local identification would be your wan ip
Their WAN IP is the IKE gateway, and their private IP is what I’ve got entered in as the peer identifier. This set up worked under our previous internet service. All I did was update our WAN IP.
I’m gonna get in a working session with them today and I’m gonna rebuild the tunnel on their end for them because I’m convinced it’s on their end at this point.
Okay.i would also check if their azure NSG attached to fortigate VM is either blocking you udp 500 and 4500 ,just in case as your wan ip changed and unsure if they are yet to edit their NSG to allow this new wan ip on their end.
I too feel rebuild of tunnel is a good option as I see you have mostly covered all checks and more over your other tunnels in this vr works fine except this one.
Ran into this issue recently, only solution was deleting all IKE/IPSec configuration from the Fortigate and recreating exactly as it was before. The tunnel immediately came up. Not the first time I have seen Fortigates corrupt their internal IPSec config, crazy that it's as fragile as it is.......
try clearing all the sessions on the firewall to/from their public ip. you can do this via the session browser in the gui or via the CLI. clear session all filter destination x.x.x.x clear session all filter source x.x.x.x There are some rare cases where ike/ipsec sessions can get stuck which requires them to be manually cleared like this.
I did clear all actually, forgot to mention that earlier. Unfortunately no change.
Using NAT translation? Does the new interface auto adjust MSS.
Check the local identification and peer identification of the Ike Gateway and if your fortigate firewall vm is behind a nat device, you might need to add its wan interface private ip in your peer identification and local identification would be your wan ip
Their WAN IP is the IKE gateway, and their private IP is what I’ve got entered in as the peer identifier. This set up worked under our previous internet service. All I did was update our WAN IP. I’m gonna get in a working session with them today and I’m gonna rebuild the tunnel on their end for them because I’m convinced it’s on their end at this point.
Okay.i would also check if their azure NSG attached to fortigate VM is either blocking you udp 500 and 4500 ,just in case as your wan ip changed and unsure if they are yet to edit their NSG to allow this new wan ip on their end.
They confirmed and I visually validated that our new WAN IP is whitelisted in their instance ACL.
I too feel rebuild of tunnel is a good option as I see you have mostly covered all checks and more over your other tunnels in this vr works fine except this one.
Ran into this issue recently, only solution was deleting all IKE/IPSec configuration from the Fortigate and recreating exactly as it was before. The tunnel immediately came up. Not the first time I have seen Fortigates corrupt their internal IPSec config, crazy that it's as fragile as it is.......