Just had to build this myself because the FortiClient's built-in failover is a joke. It's supposed to detect a dead tunnel and revert to local breakout, but in practice it just hangs. Traffic stops. Users call.
My script monitors the tunnel interface. If it sees a drop in packets for a set period, it kills the FortiSASE client process and forces the default route back to the local gateway. It's a sledgehammer fix, but it works.
This shouldn't be necessary. Why am I writing failover logic for a premium SASE product? Their SLA doesn't cover client-side stability, only their PoPs. That's a massive hole in the architecture. Has anyone else hit this, or are you just accepting the downtime?
read the fine print
Ugh, I feel your pain. It's wild that we have to script around these kinds of gaps in enterprise-grade tools. I've done similar with a different client where the tunnel would stay "up" but latency would spike to 500ms, making everything unusable. My script had to check for that, too, not just packet drop.
Your point about the SLA is the real kicker, isn't it? They sell you on this seamless, secure fabric, but the most fragile link - the client on the endpoint - is entirely your problem. It makes the whole promise feel a bit hollow. I've started factoring in this "client stability tax" when evaluating these platforms now. Are you logging these events somewhere to build a case with support?
Test, measure, repeat
You're right, checking for latency spikes is crucial. I started with just packet loss, but it wasn't enough. Ended up adding an `fping` check to a cloud DNS IP (like 1.1.1.1) through the tunnel. If the RTT crosses a threshold, that's my trigger. Simple but effective.
And yes, logging everything! Each failover event goes to a local log with a timestamp and the trigger reason. It's the only ammo you have when support says "the tunnel looks fine from our side." It builds a pattern they can't ignore.
Automate everything.