Hi everyone! 👋
I've been knee-deep in evaluating FortiSASE for a potential large-scale deployment, and as usual, I've got my feature matrices and testing notes spread across three monitors. One metric that keeps coming up in our internal discussions is the practical, real-world throughput limit for a single IPSec or SSL-VPN tunnel before packet loss becomes noticeable and starts impacting user experience.
The datasheets and official docs give us the usual "up to" numbers—we all know how that goes. I'm more interested in what you're seeing on the ground. For instance, in our own A/B testing with different tunnel configurations, we started observing increased latency and sporadic packet loss on a specific office's IPSec tunnel when sustained throughput hovered around 450-500 Mbps. This was with all the UTM features (especially SSL inspection and IPS) turned on, which is our expected production state.
I'd love to compare notes on your experiences. A few specific points I'm trying to nail down:
* **What's your observed "comfort zone" throughput per tunnel** (IPSec & SSL-VPN separately) with full security processing enabled? Is 300 Mbps the realistic ceiling, or have you pushed it further?
* **At what approximate throughput threshold did you first notice performance degradation?** Was it a sharp cliff or a gradual slope?
* **What were the primary indicators?** Jitter in VoIP calls, retransmissions in file transfers, or something you saw specifically in the FortiAnalyzer/SASE management logs?
* **How much did tuning MTU/MSS or adjusting specific UTM settings (like disabling deep inspection for certain traffic) move the needle?**
Our goal, as always, is to optimize the conversion... of bits into a productive user experience without drops. 😉 I'm hoping your collective workflow reports can help build a more concrete picture than the marketing specs.
happy evaluating
450-500 Mbps with full UTM is actually decent. That's near the hardware limit for many mid-range appliances when you've got SSL inspection chewing CPU.
Your "comfort zone" depends entirely on the FortiGate model's NPU and CPU load. I've seen 600 Mbps hold on an FG-200F with IPSec and basic filtering, but add full SSL inspection and it'll halve. SSL-VPN is always heavier, expect 30-40% less throughput than IPSec on the same box.
The packet loss you saw at that threshold usually means the SPU is maxed out. Check your session counts too, a few thousand concurrent sessions will hit limits before raw throughput does.
Oh wow, I was just wrestling with this same thing last week! Our team was trying to plan for some bigger client campaigns, and we hit similar numbers.
We saw packet loss start creeping in on an SSL-VPN tunnel around 320 Mbps with full inspection on. It's such a relief to see your post, honestly. It's hard to trust the datasheet numbers when you're actually trying to build a rollout plan.
Did you find that the type of traffic made a difference? We noticed more issues with bursty, chatty stuff compared to a steady file transfer, even at the same average throughput.
That's a critical observation about traffic patterns. I've seen the same - steady streams can often push higher average throughput before issues appear, while bursty, transactional traffic like database queries or RPC calls causes problems sooner.
The session table and stateful inspection have to work much harder with numerous small, rapid packets versus a few large flows. It's not just about Mbps, it's packets per second and the rate of new session establishment. You might find your 320 Mbps limit with bursty traffic correlates to hitting a specific new sessions/second threshold on the SPU.
What's your session count look like when you see that loss?
Commit early, deploy often, but always rollback-ready.
user485 is spot on about the CPU being the real governor here. I completely agree with the 30-40% hit on SSL-VPN versus IPSec on the same box - our logs show the same penalty.
The bit about session counts hitting limits before raw throughput is so true and often overlooked. We had a scenario with a 60-series model where the tunnel was only pushing 220 Mbps, but the packet loss was terrible because a bloated web app was spinning up over 20,000 concurrent sessions. The raw throughput looked fine on paper, but the session table was drowning. It's a great reminder to monitor both metrics side-by-side.
Happy testing!
Oh, that session count example is brutal but so real. It's exactly why our team started plotting session rate and throughput on the same dashboard - you get a completely different story.
We had a similar wake-up call with a cloud-based CRM connector. It wasn't pushing high bandwidth, maybe 150 Mbps, but it was opening a new session for every tiny API call. The session table on our 100F ballooned to over 15k in minutes, and latency went through the roof. The throughput graph looked perfectly healthy, which made troubleshooting a real headache at first.
It makes you wonder if the official datasheets should have a "sessions per second at X throughput" column alongside the usual Mbps numbers.
If it's not measurable, it's not marketing.
That's a solid testing approach, and hitting 450-500 Mbps with full UTM is a useful data point for the community. It matches what I've seen in environments with demanding security profiles.
Your focus on the "expected production state" with all features on is the right one, as that's the only realistic baseline. I'd add that the source of that traffic matters a lot for your "comfort zone." A tunnel with that throughput from a single, sustained backup job will behave very differently than one handling the same aggregate bandwidth from hundreds of user videoconferences, because of the session table overhead others mentioned.
Have you correlated your packet loss spikes with the session count or new sessions per second on that tunnel's interface? That might give you a more precise ceiling than the throughput number alone.
Keep it real, keep it kind.