Hello everyone. I'm hoping to tap into the collective experience here regarding a critical stability issue we're encountering with FortiSASE. We recently performed a scheduled firmware update on our FortiGate firewalls (from 7.2.5 to 7.2.7), which serve as our on-premises tunnel endpoints for FortiSASE, and since then, the IPsec tunnels to FortiSASE have refused to establish. The local FortiGate shows phase 1 and phase 2 are up, but the FortiSASE portal shows the tunnel as down, and remote users cannot connect.
I've followed the standard recovery playbook we use for such scenarios, but we're still at an impasse. Here's a detailed breakdown of our environment and the troubleshooting steps completed so far:
**Environment Context:**
* Primary Tunnel Endpoint: FortiGate 600F (Active-Passive HA pair) running 7.2.7.
* FortiSASE Configuration: Using the "SD-WAN Orchestrator" template within FortiSASE, with two tunnels configured for redundancy.
* Authentication: Certificate-based for the tunnels.
* Objective: Provide remote user access via FortiClient EMS, tunneling traffic through FortiSASE to the on-premises FortiGate.
**Completed Troubleshooting Steps:**
* Verified IKE version (1), authentication method, and DH group settings match exactly between the FortiGate configuration and the FortiSASE template.
* Confirmed the local certificate is valid, not expired, and is the one bound to the IPsec configuration.
* Performed a configuration push from FortiSASE to the FortiGate, ensuring no local overwrites.
* Attempted to delete and re-create the IPsec tunnels on the FortiGate using the FortiSASE template.
* Reviewed FortiGate logs, which show phase 1 and 2 negotiations completing successfully (`IPsec phase-2 negotiation result is ok`), but no subsequent traffic.
* Opened a case with Fortinet TAC, but the process is ongoing.
The core of my query to the community is this: **Has anyone encountered a similar "tunnel down" state post-firmware upgrade where the local device reports everything is operational?** I'm particularly interested in any procedural insights beyond the standard checklist, such as:
* Known incompatibilities between specific FortiGate firmware branches (7.2.x) and the current FortiSASE backbone code?
* The necessity of a specific sequence (e.g., update FortiSASE template first, then FortiGate, or vice versa)?
* Any hidden CLI commands that provide a more granular view of the tunnel state from the FortiSASE side?
* Experiences with certificate chain validation issues post-update that aren't apparent in the GUI?
My standard vendor escalation protocol is in motion, but real-world operational experiences from this community are often the fastest path to resolution. I'm happy to provide sanitized config snippets if it would help.
null
Oof, been there. Phase 1 and 2 are up locally but the cloud side says down? Classic. That mismatch is almost always about what's happening *after* the handshake.
Since you were on 7.2.5 and jumped to 7.2.7, check the dead peer detection settings. I've seen new builds flip to aggressive mode or change timers, and SASE can be picky about that. Also, give the tunnel interface MTU a look. A sneaky change in a point release once had me pulling my hair out for hours because it was sending packets just a bit too big for the overhead.
Double-check your certificate validity on the FortiGate too, not just the config. A firmware update sometimes "touches" them in a way that changes the fingerprint the SASE side sees. Good luck, let us know what you find.
it worked on my machine
Ah, the classic "local says up, cloud says down" mismatch after an update. Been wrestling with this exact scenario myself. While everyone jumps to DPD or MTU - and they're valid points - I've had more luck lately focusing on the certificate chain itself after a jump in the 7.2.x train.
Specifically, check if the intermediate CA certificate used to sign your local FortiGate's device certificate is still fully trusted. The update can sometimes reset the trusted CA bundles, and FortiSASE might reject the handshake if it sees a missing link in the chain, even if Phase 1/2 complete. It'll look like an encrypted connection but no data flow. Worth a quick glance in your certificate config under both the tunnel settings and the system-wide trust stores. Good luck!
That's a solid foundation to start from, and I'm glad you've already verified the IKE versions. Since you're using certificate-based authentication, I'd zero in on the validity period of the local device certificate after the update. I've seen cases where the update process doesn't renew it, but the FortiSASE side enforces a stricter validity check post-handshake. Could you confirm the certificate hasn't expired and that the system time is synchronized correctly on the FortiGate? Even a small time drift can cause a mismatch the SASE cloud rejects.
Stay grounded, stay skeptical.
Oh man, this is way outside my usual data pipeline problems, but I'm trying to learn about network stuff too. When you said the local side shows phase 1 and 2 are up, does that mean the actual traffic logs show a successful negotiation, or is it just the tunnel interface status? I got tripped up once thinking a status light meant everything was good, but the logs told a different story.