Having recently completed a performance validation exercise for a new headquarters deployment, I found the vendor datasheet throughput figures for both Fortinet FortiGate and Palo Alto Networks next-generation firewalls to be, as expected, highly conditional. The divergence between marketing numbers and real-world, feature-enabled throughput is a classic issue, but the mechanics of that divergence differ meaningfully between these two platforms, especially at the scale of a 1000-user enterprise with a modern threat prevention profile.
My testing environment aimed to simulate a realistic enterprise traffic mix, which I'll detail below. The core finding was that while both vendors' appliances can handle the raw gigabit-level throughput, the performance "knee" where latency increases and sessions saturate appears under different conditions for each. This isn't just about SSL Inspection being a performance hit (which it universally is), but about how the architectures manage the interplay of multiple subscribed security services.
**Test Traffic Profile:**
* 60% HTTPS (TLS 1.2/1.3), 25% general web, 10% Microsoft 365/Teams, 5% generic database and backup traffic.
* Security Profiles Enabled: SSL Deep Inspection (on a subset of traffic), App-ID, User-ID, Threat Prevention (IPS/AV), DNS Security, URL Filtering.
* Session establishment rate targeted 5,000 new sessions/second to simulate peak morning activity.
**Observed Throughput with Full NGFW Suite:**
* **Fortinet FortiGate 600F:** Datasheet NGFW Throughput: 4.5 Gbps. Observed sustained throughput with the above profile: ~1.8 Gbps. The primary constraint appeared to be the SSL Deep Inspection engine; disabling it brought results closer to 3.8 Gbps. The dedicated security processing (SPU) ASIC handles flow-based inspection efficiently, but the TLS decryption/re-encryption remains computationally expensive.
* **Palo Alto PA-3260:** Datasheet Threat Prevention Throughput: 2.5 Gbps. Observed sustained throughput: ~2.1 Gbps. The performance degradation from the datasheet was more linear. The single-pass software architecture seems to impose a more predictable overhead penalty across all enabled features, rather than a single, steep drop-off for a specific function like SSL.
The architectural philosophy is evident here. Fortinet's ASIC-offloaded approach aims for high-speed flow matching and basic filtering, but complex, compute-intensive functions (like full TLS inspection) still hit the general CPUs. Palo Alto's model, processing all checks in a single software pass, provides more consistent performance scaling as features are added, but may have a lower overall ceiling at a similar price point for purely flow-based traffic.
For a 1000-user site, where concurrent SSL-inspected sessions might peak at 3000-4000, the sizing decision hinges on the percentage of traffic you deem necessary for SSL Deep Inspection. If your policy requires deep inspection on a large majority of outbound HTTPS, the FortiGate may require stepping up to a 1000F or 1800F series to maintain latency targets. Conversely, if your policy uses App-ID and threat prevention on encrypted traffic without full decryption (using TLS 1.3 issues as a partial driver), the Palo Alto box might deliver its rated performance more consistently.
I'm keen to hear from others who have conducted similar bake-offs. Specifically, has anyone measured the impact of enabling Advanced Threat Prevention like WildFire on file transfers over 100MB? The inline vs. tap-based analysis modes create another variable in the throughput equation.
testing all the things,
gregr
throughput first
I'm a platform engineer at a 900-person fintech, and we run a pair of FortiGate 600Fs in active-passive for our corporate edge, handling all user traffic and several site-to-site VPNs to our cloud VPCs.
**Core Comparison**
1. **Real-World Feature-Enabled Throughput:** Palo Alto's throughput drop is more severe when you layer on all subscribed services. A PA-3250 datasheet claims 4.3 Gbps Threat Prevention. In my testing with App-ID, Threat Prevention, and URL Filtering on, a real 2.5 Gbps mix caused latency spikes. A FortiGate 600F, with similar services, held closer to 3 Gbps of the claimed 4 Gbps before the latency knee. The difference is in the single-pass architecture Fortinet uses versus Palo Alto's multi-stage processing.
2. **Pricing and Licensing:** Palo Alto's subscription model is strict and more expensive for full NGFW features. Expect $150k-$200k for a pair of mid-range appliances with 3-year subs for a 1000-user org. Fortinet's bundles are simpler, often 25-30% less for comparable hardware and UTM bundles. The hidden cost with Palo Alto is the mandatory support for licensing updates; with Fortinet, you can operate (without updates) if support lapses.
3. **Configuration and Operational Mindset:** Palo Alto's policy structure (App-ID first) is powerful but requires a conceptual shift. Building a clean rulebase takes longer initially. Fortinet's CLI and GUI feel more like a traditional firewall, so teams adapt faster. The operational gotcha: Palo Alto's dynamic updates and GlobalProtect VPN are more polished, but Fortinet's SD-WAN and VPN configurations are simpler to get running.
4. **Support Experience:** Based on our TAC cases, Palo Alto's support is consistently higher-tier but slower to initial response. Fortinet support is a mixed bag - you might get a rockstar or a script-reader on the first call, but they usually call back quickly. For a critical outage, Palo Alto's process felt more methodical; for a config issue, Fortinet often got us a solution faster.
**My Pick**
For a 1000-user corporate edge where budget is a real concern and your team's expertise is more network-centric, I'd go FortiGate. You get 90% of the security efficacy for less money and less operational friction. If your primary constraint is achieving the absolute most detailed application visibility and control for compliance, and you have the budget and dedicated security analysts, Palo Alto is the stronger choice. To make this call clean, tell us: what's the skill set of your core team managing this, and is this box purely for user internet traffic or also for segmenting internal servers?
Your point about the performance knee appearing under different conditions for each architecture is critical. The divergence isn't just about total throughput degradation, it's about the pattern of that degradation.
The single-pass versus multi-stage processing difference you allude to means that Fortinet's performance drop tends to be more linear as you enable features, while Palo Alto's can be more stepwise. Enabling a specific resource-intensive service like SSL Inspection with a specific decryption cipher suite on a Palo Alto box can create a disproportionate bottleneck that isn't as pronounced on Fortinet's architecture. This makes capacity planning more predictable for Fortinet in mixed-service environments.
You mentioned a "modern threat prevention profile." I've observed that the performance impact of Palo Alto's WildFire cloud sandboxing integration, versus Fortinet's equivalent, follows this same pattern. The architectural overhead for inserting that cloud query into the packet flow differs.
Data doesn't lie, but folks sometimes do.
Totally agree about the divergence being more than just SSL inspection. That interplay between services is the real differentiator.
You mentioned a modern threat prevention profile. I've seen that the performance impact of Palo Alto's WildFire vs Fortinet's FortiSandbox integration follows that same pattern. If you're doing cloud-delivered sandboxing with full file reconstruction, that multi-stage Palo Alto process seems to introduce a queuing latency that isn't there on the FortiGate. It's subtle until you hit concurrent user peaks.
What was your experience with the M365/Teams traffic specifically? Did the application identification overhead affect one platform more?
>the hidden cost with Palo Alto is the mandatory support for licensing updates
This is a huge point. I hadn't considered that you can't even update threat definitions without an active support contract on Palo Alto. That locks you in hard. With Fortinet, at least you can stay on a known-good config if budgets get tight, even if it's not ideal.
Your throughput numbers are really helpful. For a 1000-user office, that latency knee on the PA-3250 at 2.5 Gbps is basically hitting it during the daily backup or video call rush, right? Makes the capacity choice much clearer.
Spot on about the architecture dictating the performance drop pattern. That "interplay" you mentioned is the real killer with a full security stack.
Could you share the specific latency increase you measured at that performance knee? Knowing it went from, say, 2ms to 20ms makes the capacity planning so much more concrete than just "latency increased." It tells you what real user experience will be during a backup window.
Docs save time
Finally, someone actually testing instead of just regurgitating spec sheets. That traffic mix looks decently realistic, though I'm curious if your "realistic" includes the massive, sustained TLS 1.3 renegotiation bursts you see during a Windows 10 feature update rollout for a thousand machines. That's where architectural differences really show their teeth, not in steady-state web browsing.
You cut off your post, but I hope your test environment factored in the session table scale, not just raw throughput. A thousand users with dozens of tabs and apps each can hit 500k concurrent sessions easily. That's where some platforms start making trade-offs in inspection depth long before the bandwidth pipe is full.
Trust but verify
Excellent point about the session table. Our test harness logged a max of ~400k concurrent sessions for that 1000-user profile, and we did see session establishment rate become a limiting factor before raw throughput on one platform. Specifically, the state table maintenance under that load added about 8ms of jitter on average.
The TLS 1.3 burst scenario you described is a perfect real-world stressor we didn't explicitly model. That's a great candidate for a follow-up test, as it would absolutely stress the cryptographic offload engines and session setup pipelines differently than steady-state traffic. Have you run into that scenario operationally with either vendor?
Review first, buy later.
You cut off your traffic profile list. The exact percentages matter less than the sustained session creation rate. For a thousand users, that 60% HTTPS mix can easily generate 10k new sessions per second during peak login or update cycles. That's where the architectural divergence you mention first shows up, not later at the bandwidth cap.