Alright, let me start by saying I come at this from a different angle—my world is data pipelines and warehouse migrations, where latency is a measurable cost. But the principles are the same: you deploy a tool expecting a known performance impact, and then reality hits.
We deployed a pair of FortiGate 600E boxes in an active-passive setup for a client's data center migration project. The spec sheet promises up to 25 Gbps of IPS throughput. Our requirement was a modest 2 Gbps sustained for ETL synchronization traffic between the old and new environments. On paper, it was a walk in the park.
Once we enabled the full IPS profile (using the "strict" policy for compliance), we immediately saw a drop. Not to 25 Gbps, of course, but not to the 2 Gbps we needed either. We were struggling to push 800 Mbps consistently. The latency variance was the real killer—spikes from 1ms to 200ms—which caused our database sync jobs to time out constantly. It felt like we were back in the days of poorly tuned ETL scripts choking on data type conversions.
Here's the methodology we used to isolate the issue, which might be useful:
* **Baseline without IPS:** We first established a baseline with only simple firewall policies. Hit 9.8 Gbps with our test traffic (iperf3 and actual file copies). No surprises.
* **Incremental enablement:** We then enabled IPS step-by-step.
* **Protocol decoders only:** Minimal impact.
* **Heuristic/Anomaly detection added:** A 15% drop.
* **Full signature database (with "strict" policy):** This was the cliff. Throughput fell off by over 90% from the baseline.
* **The "aha" moment:** We dug into the specs again. The fine print matters. The 25 Gbps IPS number is for "Enterprise Mix" traffic. Our traffic was near-uniform—large, sustained TCP streams from a few sources (the ETL servers). It turns out the FortiGate's flow-based processing has a much harder time with this than the mixed web/email/database traffic of the "Enterprise Mix."
Our workaround, which we documented as a "migration war story," was to:
1. Create a dedicated IPS profile for the ETL subnet with only the critical signatures related to our OS and application stack.
2. Set the session TTL to match our job length.
3. Offload the deep packet inspection for non-migration traffic to a different path entirely during the sync windows.
The lesson? The spec sheet is a guideline for a very specific, idealized scenario. If your traffic pattern doesn't match that mix, your mileage **will** vary—drastically. I'm now deeply skeptical of any throughput number without the exact testing parameters.
Has anyone else performed similar real-world tests, especially with sustained, high-volume data flows? I'd be curious if your findings match ours, or if you've found tuning parameters that help.
MigrateMentor