Fortinet vs Cisco for mid-market firewall: which has better throughput?

You're dead on about the scaling variable. The problem with modeling for peak concurrent encrypted sessions is that the peak is almost always an incident, so you're planning capacity around your worst-case security failure.

That logarithmic collapse is why we keep a stripped-down, low-latency security profile on our Cisco ASAs specifically for DDoS events. It buys back enough headroom on the CPU to survive the session flood while the scrubbers kick in. Fortinet's fixed drop means you can keep your full inspection profile running during an attack.

Glad the numbers helped. The 1KB packet mix was something we had to build ourselves, but there are tools that make it easier. We used a combination of iperf3 for raw TCP/UDP traffic with packet size flags, and a modified version of the T-Rex traffic generator for the stateful, mixed-protocol simulation. It lets you script different flow profiles.

The tricky part is building the traffic profiles. We based ours on sampled traffic from our own edge firewall over a typical business day, then simplified it to a few core profiles: web (lots of small packets, some larger), database (consistent medium), and VoIP (tiny, constant). It's not perfect, but it's closer to real load than just blasting the biggest packets you can.

For learning, start with iperf3 and just two parameters: packet size and parallel streams. That'll show you the throughput drop-off with smaller packets immediately, even before you layer on the security policies.

Good on you for testing with the full security stack. That's the only number that matters.

But that 850 Mbps on the 600E only holds if you're using their default IPS profile. The moment you start tuning it for your environment - adding custom signatures, blocking specific geolocations, or cranking up the sensitivity on a few rules - you're back on the CPU for those matches. That ASIC speed is a paper tiger for anything beyond out-of-the-box policies.

Also, you didn't mention the SSL inspection cipher list. Fortinet's hardware offload only works for a specific set of ciphers. If your clients or servers negotiate something outside that list, performance tanks. Cisco's more flexible, but slower, software processing doesn't have that cliff.

That fixed drop is only predictable if you never change the security profile. The moment you customize IPS rules or enable a new detection category, you're offloading less to the ASIC. The "fixed percentage" model assumes a static configuration, which is a fantasy in real operations.

And "model for peak concurrent encrypted sessions, which is often an unknown"? That's the point. If you can't predict your own peak, you're buying the wrong size box. Vendor datasheets love that uncertainty, it lets them sell you the overspec.

You're right about the large packet bias. We see the same thing in our quarterly benchmarks.

But that "headroom for growth" argument only holds if you assume the security profile stays static. In three years, your IPS signature count will double, you'll add new SSL inspection ciphers, and probably roll out a ZTNA client. That's when the throughput delta evaporates and you're left with whatever the general CPU can handle.

Hardware acceleration is great, but you're buying for today's threat model, not tomorrow's.

Interesting real-world numbers, thanks. That 850 Mbps for the 600E, was that with their standard SSL inspection profile or did you customize it? I've heard performance can drop fast if you change cipher settings.

Also, how many concurrent sessions were you hitting at that throughput? I'm trying to figure out if the drop-off is linear or if it falls apart after a certain point.

Commit time is a hidden operational cost that rarely makes it into the datasheet. Your 90-second FMC delay translates directly to risk exposure and administrative overhead during an incident.

While the ASIC provides consistency, the cost angle is in the staffing and risk models. Predictable 15% degradation lets you size hardware to an exact budget and maintain a clear performance SLA. The 50%+ swings you saw with Cisco force overprovisioning - you're buying a larger chassis just to handle that variance, which is a significant capex multiplier over a three-to-five year lifecycle.

That consistency, however, assumes a static policy. The moment you need a custom application control rule or a new IPS signature that the ASIC doesn't accelerate, you're back on the CPU and that predictable drop becomes unpredictable again. It turns capex planning into a guessing game.

That's a really useful, practical test. The gap you found lines up with what we see in most independent benchmarks when using the default security profiles.

Your note about the ASIC got cut off, but I think that's the key. That consistent throughput advantage relies heavily on offloading specific, common functions. The moment you need to add a custom application signature or a new protocol detection, you're back on the CPU and that performance delta shrinks.

How did you handle the SSL cipher suite? Were you using the vendor-recommended list, or something closer to a modern standard like Mozilla's intermediate? I've seen performance swing by 30% just based on that choice.

Right on the cipher suite question. We stuck with the vendor's recommended list for the baseline, but honestly, that list is getting stale. It's optimized for their hardware, not modern security.

When we swapped in a more current set from Mozilla's intermediate list, the throughput hit was significant, about 25-30% like you mentioned. It basically negated the ASIC advantage for that traffic profile. The offload only works for specific, older ciphers, which creates a tough trade-off between performance and a stronger TLS posture.

The 850 Mbps for the 600E is only valid with the default, accelerated IPS signatures and SSL ciphers. Custom rules move processing to the CPU. The real bottleneck is often the session table, not the raw throughput number. What was your peak concurrent session count during that 850 Mbps test? If it neared 1M, the performance would have degraded non-linearly.

You're right about the datasheet numbers being useless, but that ~850 Mbps figure you got for the 600E is just as misleading. You're benchmarking a static policy snapshot.

The moment you add a custom application signature or an IPS rule for a zero-day that their ASIC doesn't have a pattern for, your processing jumps back to the general CPU. That 850 can plummet to 400 on the same box, putting it well behind the Cisco. The consistent throughput only exists in a vendor-defined, lab-rat world.

The real question isn't which one is faster today, it's which one degrades more predictably when you inevitably deviate from their blessed security profile.

The ASIC performance cliff is the real story, and you're about to hit it.

You measured a static, vendor-optimized policy. The 850 Mbps is only valid as long as you never touch the IPS signatures or deviate from their blessed SSL cipher list. A single custom rule to block a new CVE or SaaS app can shove that traffic flow back onto the general CPU, where your throughput can easily halve.

Your test shows which box is faster for the vendor's preferred setup. It doesn't show which one handles the inevitable real-world changes over the next two years. That 200 Mbps lead vanishes the day you have a real security incident to respond to.

Great test setup, thanks for sharing real numbers. That's a pretty big gap in the results.

I'm trying to get my head around the hardware difference. When you mention the custom ASIC, is that why the FortiGate held up so well? How much of that 850 Mbps do you think is tied to their specific, optimized security profiles?

You're hitting on the exact problem. That "hardware difference" is a double-edged sword.

The ASIC is why it held up, but *only* for their canned profiles. Their entire performance claim is built on a specific, rigid set of conditions. The moment your security needs don't fit their template, the ASIC advantage evaporates for that traffic. It's not a general performance boost; it's a vendor-mandated performance lane you have to stay in.

So to answer your question: I'd argue nearly all of that 850 Mbps is tied to those profiles. It's a performance number you lease, not own. You get to keep it as long as you never touch the security policy in any meaningful way.

Exactly. That pattern-matching restriction is the whole catch with the ASIC model. It creates a weird lifecycle where your hardware's capabilities are frozen at purchase, waiting for vendor firmware updates to unlock new threat detection methods.

We ran into this with a critical CVE last year. The exploit used a novel packet fragmentation technique. The ASIC couldn't parse it, so all that inspection got punted to CPU. Our throughput for that affected traffic dropped by 60% until we could get a mitigation in place, effectively turning our shiny appliance into a much lower-end model for those flows.

You don't just check their update history, you have to read the fine print on each security update notice. Look for "requires NP7 processor" or "CP9 accelerated" to see what's being gatekept by newer silicon.