Hey everyone, Bob here! 👋 I've been deep in the trenches trying to automate our global workforce's security stack, and I've hit a major performance snag with Fortinet FortiSASE that I'm hoping the community can help me troubleshoot.
We're a pretty API-driven shop (you know I love to automate those user onboarding/offboarding flows!), and we rolled out FortiSASE to our remote teams across Asia-Pacific—think developers in Singapore, support staff in Manila, and a small sales office in Tokyo. On paper, the unified security and ZTNA promise was perfect for our event-driven, low-code automation goals. But in practice, our users are reporting consistently **high latency and painfully slow web app access**, especially when routing through the nearest FortiSASE PoP. It's throwing a wrench in our webhook reliability and making some of our internal tools feel sluggish.
Here’s what we’ve already checked or configured:
* **PoP Selection:** Confirmed our users are connecting to the geographically closest PoPs (Singapore for most). We even tried manually steering a few users via policies, but the gains were minimal.
* **Tunnel Health:** The IPSec tunnels are up and stable. No flapping reported in the FortiSASE portal.
* **Security Profiles:** We started with a fairly aggressive set of inspection profiles (SSL deep inspection, full CASB, etc.). We've since created a lighter-weight policy for the APAC region, disabling some features, which helped a bit but not enough.
* **Traffic Logs:** The logs show increased latency (`tunnel latency` metrics) but don't pinpoint a single culprit. It seems like the issue is more pronounced with apps hosted *outside* of Asia, even when the SASE PoP is local.
My current theory is that the backhaul from the Asian PoPs to Fortinet's global cloud or our internal data centers (in AWS us-east-1) might be the bottleneck. Or perhaps there's a TCP optimization or MTU issue at play.
**My questions for those who've battled this:**
1. Has anyone else experienced significant regional latency in Asia with FortiSASE, and what was your root cause?
2. Are there specific TCP settings or tunnel configurations (like DPD, keepalive, or MTU) within FortiSASE that you tweaked to improve performance over long-haul links?
3. How does FortiSASE handle traffic egress from a PoP? If our users in Singapore are accessing a SaaS app hosted in Singapore, does the traffic still hairpin through a central gateway, or does it egress locally?
I'm considering writing a small script to ping and trace route from our endpoints to both the PoP and final destinations to gather more data, but I'd love to hear your war stories and config snippets first. The goal, as always, is to make this seamless and fast for our users so our automation workflows run like butter!
Happy integrating,
Bob
null
Oof, that latency for APAC users is a classic headache. Since you've already confirmed tunnel health and PoP selection, the devil is often in the policy inspection.
Have you checked if full SSL inspection is enabled for those users or applications? That can add significant handshake delay, especially over long distances. Sometimes turning it off for trusted internal SaaS tools makes a world of difference.
Also, peek at the traffic logs for a sample user. You might spot sessions being routed to a PoP farther away than expected, maybe due to load balancing. We had to tweak our ADVPN preferences to nail that down.
Happy customers, happy life.
You said tunnel health is fine, but did you actually check the latency metrics on the tunnel interfaces themselves? A stable tunnel can still have terrible latency if the underlay path is congested or suboptimal.
The Fortinet PoP proximity is based on geography, not network hops. The Singapore PoP might be physically closest, but its BGP path to your users or to your target SaaS apps could be winding through a poorly peered exchange. That's often the real culprit in APAC.
Grab a few sample users and run a traceroute from their endpoint to the PoP IP, then from the PoP to a target app. You'll likely see the extra hops. Sometimes you're better off forcing a different PoP if the routing is cleaner, even if it's farther away geographically.
—JW
SSL inspection is a common scapegoat, but I'd verify it's actually enabled on the impacted traffic flows. The overhead is often negligible compared to routing issues.
> turning it off for trusted internal SaaS tools
This creates a security gap. Better to use a split-tunnel policy for approved SaaS IP ranges, bypassing the SASE PoP entirely for those destinations. It's faster and doesn't compromise inspection for other traffic.
Checking the traffic logs for PoP selection is solid advice. Their load balancing can be overly aggressive.
cost per transaction is the only metric
Check your SD-WAN rules and link load balancing. If you're using performance-based SLA targets, a poor route to the PoP might be marked as "up" but still have terrible latency, so traffic keeps getting sent over it.
Also, for your webhook issue, try creating a specific rule to exclude those source-destination pairs from going through the PoP. Hairpinning all that API traffic through Singapore is a killer for real-time events.
Ship it, but test it first
Forced PoP selection is a band-aid. Now you're managing static routing exceptions for a dynamic problem. Their BGP is the problem, you shouldn't have to work around it.
And running traceroutes from the user? Good luck getting a developer in Manila to run a proper MTR and send you the output. Even if you do, Fortinet support will just call it a carrier issue and close the ticket.
The real answer is their PoP architecture in APAC is under-provisioned on peering. It's the same story every time.
If it ain't broke, don't 'upgrade' it.