An enterprise firewall may advertise impressive throughput figures. But what happens when intrusion prevention, application control, malware protection, and encrypted traffic inspection become part of the equation? Using real specifications from Fortinet and Palo Alto Networks, we examine what the numbers actually mean, why benchmark results differ, and how businesses can avoid expensive mistakes when selecting their next-generation firewall.
39 Gbps. An Impressive Number — Until Someone Opens the Next Page.
Imagine a meeting between a company's IT department and a potential network security supplier.
The objective is straightforward: select a next-generation firewall capable of protecting the organisation's infrastructure for the next several years.
The supplier presents a technical datasheet.
One specification immediately attracts attention.
Firewall Throughput: 39 Gbps.
For a company operating an internet connection of just a few gigabits per second, the number seems more than sufficient.
Then the security engineer points to another specification.
Threat Protection Throughput: 2.8 Gbps.
A question follows.
How can the same firewall deliver 39 Gbps in one scenario and only 2.8 Gbps in another?
Is something wrong with the documentation?
Has the manufacturer exaggerated the product's capabilities?
Or is the company looking at two entirely different measurements?
The answer lies in how modern firewalls process traffic.
Both figures appear in Fortinet's official specifications for the FortiGate 120G.
Both describe legitimate performance characteristics.
But they represent different workloads, different security functions, and different testing conditions.
Understanding that distinction can be the difference between a successful infrastructure investment and an expensive sizing mistake.
Because the most important question is not how much traffic a firewall can forward.
It is how much traffic the firewall can inspect and protect under the conditions your business actually requires.
Why Firewall Throughput Is Not the Whole Story
Traditional firewall performance is relatively straightforward to describe.
Network packets enter a device, security policies determine whether they may pass, and permitted traffic continues towards its destination.
In simplified benchmark scenarios, the device may achieve extremely high forwarding rates.
But a modern Next-Generation Firewall (NGFW) does much more than check IP addresses and ports.
Depending on its configuration, it may identify applications, inspect traffic for intrusion attempts, examine files for malware, apply user-based security policies, decrypt selected TLS sessions, and record events for further analysis.
Every additional operation creates processing requirements.
And those requirements change the performance profile.
This is why enterprise firewall datasheets contain several throughput metrics rather than just one.
Firewall Throughput generally describes traffic forwarding performance under specified firewall test conditions.
IPS Throughput measures performance while an Intrusion Prevention System performs the inspection defined by the vendor's test methodology.
NGFW Throughput describes performance with a particular combination of next-generation security functions enabled.
Threat Protection Throughput reflects a broader security workload, whose precise composition depends on the manufacturer's published methodology.
The distinction may sound technical.
But it has direct financial consequences.
A company can purchase hardware based on a headline throughput figure, only to discover during deployment that the selected model has insufficient capacity for its required inspection policies.
The result may be increased latency, constrained application performance, or pressure to disable important security functions.
None of these outcomes is desirable.
And all are reasons to examine the complete technical specification before making a purchasing decision.
One FortiGate. Five Different Performance Figures.
Consider the Fortinet FortiGate 120G.
According to Fortinet's published product specifications, the device has the following performance characteristics:
| Performance Metric | Published Throughput |
|---|---|
| Firewall Throughput — 1518-byte UDP | 39 Gbps |
| Firewall Throughput — 64-byte UDP | 28 Gbps |
| IPS Throughput — Enterprise Mix | 5.3 Gbps |
| NGFW Throughput — Enterprise Mix | 3.1 Gbps |
| Threat Protection — Enterprise Mix | 2.8 Gbps |
| SSL Inspection — IPS, average HTTPS | 3.0 Gbps |
At first glance, the difference between 39 Gbps and 2.8 Gbps is striking.
Mathematically, it represents a ratio of approximately 13.9 to one.
But it would be technically incorrect to conclude that enabling security features automatically makes every network connection nearly fourteen times slower.
The figures are generated under different test profiles.
The 39 Gbps result describes firewall forwarding performance for the specified UDP packet size.
The 2.8 Gbps result describes a more demanding security workload involving multiple protection mechanisms and an enterprise traffic mix.
Fortinet specifies that its NGFW benchmark includes Firewall, IPS, and Application Control, while its Threat Protection benchmark additionally enables Malware Protection. Logging is enabled in the relevant tests.
These workloads are not equivalent.
Nor do the results necessarily establish a universal performance ceiling for every possible deployment.
Actual throughput depends on traffic characteristics, system configuration, software version, inspection policies, and other operational factors.
The SSL Inspection figure also requires careful interpretation.
Its published benchmark is a separate test using an average of HTTPS sessions with different cipher suites.
It should not be added to the Threat Protection figure, nor should it be assumed that all security functions operating simultaneously will automatically deliver the same result.
The mistake is not believing the manufacturer's performance data. The mistake is using the wrong performance data to answer the customer's question.
What About Palo Alto Networks?
Now consider another major enterprise security manufacturer.
The Palo Alto Networks PA-1410, part of the PA-1400 Series, has the following published specifications measured on PAN-OS 12.1:
| Performance Metric | PA-1410 |
|---|---|
| Firewall Throughput — appmix | 8.5 Gbps |
| Threat Prevention Throughput — appmix | 4.5 Gbps |
| IPsec VPN Throughput | 4.1 Gbps |
| Maximum Concurrent Sessions | 945,000 |
| New Sessions per Second | 100,000 |
These figures describe a different platform using a different benchmarking methodology.
For Firewall Throughput, Palo Alto Networks specifies that App-ID and logging are enabled, with application-mix transactions used during testing.
Its Threat Prevention Throughput benchmark includes App-ID, IPS, antivirus, antispyware, WildFire, DNS Security, file blocking, and logging.
At this point, it might seem tempting to compare Fortinet's 2.8 Gbps Threat Protection result directly against Palo Alto Networks' 4.5 Gbps Threat Prevention result.
That comparison would be incomplete.
The benchmark conditions are not identical.
Differences in application traffic, inspection functions, software configurations, and testing procedures make a simple numerical ranking unreliable.
Even two metrics with similar names can describe materially different workloads.
This does not make manufacturer benchmarks useless.
It means they must be interpreted within their published scope.
For a purchasing team evaluating different brands, the appropriate approach is to establish a common set of test conditions.
Which applications will be used?
How much traffic will be encrypted?
Which security features must remain enabled?
What volume of concurrent sessions must be supported?
And how much performance headroom is required?
Only after answering these questions does a meaningful comparison become possible.
The fairest comparison between two NGFWs is not necessarily the one presented in their respective datasheets. It is the one conducted under the same operational requirements.
The Hidden Cost of Inspecting Encrypted Traffic
One of the most demanding aspects of modern firewall operation is TLS inspection.
Today, a significant share of corporate application traffic uses encrypted connections.
Employees access cloud services, financial platforms, collaboration applications, business portals, and APIs through HTTPS.
Encryption protects the confidentiality and integrity of communications.
But it also creates a challenge for security systems attempting to inspect the content of those communications.
If an organisation's security policy requires full inspection of selected encrypted sessions, its firewall may need to decrypt the traffic, inspect the content, and then re-encrypt it before forwarding.
That process is more computationally demanding than applying basic firewall rules to ordinary traffic.
The workload depends on multiple factors.
TLS versions and cryptographic algorithms matter.
The number of new encrypted sessions matters.
The size and duration of transactions matter.
And the security functions applied to the decrypted content matter.
This is particularly important for organisations operating customer-facing applications, high-volume APIs, or complex cloud environments.
A firewall that comfortably handles several gigabits of ordinary traffic may behave differently when a substantial portion of that traffic requires intensive TLS inspection.
There is also an important policy consideration.
Not every encrypted connection should necessarily be decrypted.
Some applications have technical compatibility requirements. Others handle highly sensitive information and may be subject to privacy rules or organisational restrictions.
Consequently, TLS inspection planning must consider both performance and security policy.
The objective is not to decrypt everything indiscriminately.
It is to determine which traffic needs inspection, what protection is required, and whether the chosen hardware can sustain the workload.
Two Networks. The Same Bandwidth. Very Different Workloads.
Suppose two organisations each generate an average of 2 Gbps of traffic through their firewalls.
The first organisation transfers large files between a relatively small number of systems.
Connections are long-lived, and individual transactions involve substantial volumes of data.
The second organisation operates customer-facing APIs that continuously create large numbers of short HTTPS connections.
The total bandwidth is similar.
But the operational demands on the firewall may be dramatically different.
In the second environment, the device may need to process more frequent connection establishment, TLS handshakes, state-table operations, policy evaluations, and logging events.
This is why throughput measured in gigabits per second is only one part of the sizing exercise.
Other metrics matter.
Concurrent Sessions describe how many active sessions the device can maintain under its specified conditions.
New Sessions per Second, often referred to as CPS, describe the rate at which new sessions can be established.
SSL/TLS Inspection CPS measures a more specific workload associated with establishing inspected encrypted connections.
For the FortiGate 120G, Fortinet publishes up to 140,000 new sessions per second in its general session benchmark.
It also publishes an SSL inspection CPS figure of 2,100 under the corresponding test conditions.
These figures should not be treated as interchangeable.
They describe different operations.
A high-volume API environment could approach a connection-processing limit before consuming the firewall's entire advertised bandwidth capacity.
In such a case, replacing the internet connection with a faster one would not solve the underlying problem.
The bottleneck is not necessarily network bandwidth.
It may be the firewall's ability to establish, maintain, and inspect the required number of connections.
And unless the organisation measures these characteristics, the source of the problem may remain misunderstood.
A Practical Sizing Example: How Much Firewall Capacity Does a Business Actually Need?
Let's move from theoretical specifications to a realistic planning exercise.
Consider a company preparing to replace its existing NGFW.
The IT department has measured its current peak inspected traffic at 1.8 Gbps.
Management expects traffic volumes to increase by 30% over the planning horizon.
The engineering team also wants to maintain 25% spare capacity at the projected peak.
How should the requirement be calculated?
Step 1: Account for expected traffic growth.
Current peak: 1.8 Gbps.
Expected increase: 30%.
Projected peak throughput:
1.8 × 1.30 = 2.34 Gbps
This represents the estimated traffic the infrastructure must accommodate after the expected growth.
Step 2: Reserve performance headroom.
If the engineering requirement is to keep 25% of the available capacity unused at the projected peak, planned utilisation should not exceed 75%.
Required capacity:
2.34 ÷ 0.75 = 3.12 Gbps
The preliminary engineering target is therefore 3.12 Gbps of validated throughput in the required security configuration.
The 25% reserve is an illustrative planning requirement, not a universal rule established by Fortinet, Palo Alto Networks, or an industry standard.
Different organisations may require different margins based on workload variability, business criticality, and operational priorities.
Step 3: Compare the requirement with relevant published specifications.
| Planning Parameter | Result |
|---|---|
| Current peak traffic | 1.80 Gbps |
| Projected traffic growth | 30% |
| Expected future peak | 2.34 Gbps |
| Required spare capacity | 25% |
| Calculated capacity target | 3.12 Gbps |
| FortiGate 120G Threat Protection benchmark | 2.80 Gbps |
The FortiGate 120G's published 2.8 Gbps Threat Protection result falls below the 3.12 Gbps preliminary planning target.
Does that automatically disqualify the device?
Not necessarily.
The real application mix and security configuration may differ from Fortinet's benchmark.
The system could perform differently under the customer's actual traffic profile.
But the datasheet alone would not justify promising that the requested workload can be sustained with the specified headroom.
At this point, the responsible response is to conduct further sizing analysis or practical testing.
A different model may be necessary.
Or a test may show that the proposed configuration meets the customer's objectives.
The important thing is to establish that result before deployment rather than discover the limitation afterwards.
A sizing calculation does not replace a benchmark. It tells engineers what the benchmark needs to prove.
Why Two Firewalls Do Not Automatically Mean Twice the Performance
Corporate security projects frequently include two NGFW appliances operating in a High Availability configuration.
This is an established approach to reducing the risk of service disruption when an individual device fails.
But HA introduces another common misunderstanding.
Suppose an organisation purchases two firewalls, each with a published Threat Protection benchmark of 2.8 Gbps.
Does the pair provide 5.6 Gbps?
Not automatically.
In an Active-Passive configuration, the active device generally processes the production traffic while the passive device remains available to take over if the active unit fails.
Adding the second device primarily improves availability.
It does not simply double forwarding capacity.
Active-Active configurations may offer mechanisms for distributing workloads, but their results depend on platform capabilities, network design, session handling, and the relevant security features.
It is therefore incorrect to assume that two devices always provide twice the performance of one.
There is also a more important design consideration.
What happens when one member of the HA pair fails?
If the cluster requires both nodes to maintain acceptable performance under normal load, the remaining node may become a bottleneck during a failure.
For critical infrastructure, the purchasing specification should explicitly define the workload that must remain supported when a node becomes unavailable.
And that requirement should be tested.
High availability should not mean that the service survives a hardware failure only to become unusably slow.
How Professionals Should Test NGFW Performance
In March 2023, the Internet Engineering Task Force published RFC 9411, Benchmarking Methodology for Network Security Device Performance.
The document provides terminology and testing procedures for next-generation network security devices, including NGFWs and intrusion prevention systems.
Its objective is to make performance testing more applicable, reproducible, and transparent.
This is particularly relevant when organisations compare products from different manufacturers.
Modern security appliances operate at multiple layers of the network stack and perform far more complex functions than traditional packet-filtering firewalls.
A useful benchmark must therefore describe the workload being tested.
RFC 9411 addresses topics including application traffic mixes, inspected throughput, session characteristics, security effectiveness, HTTP and HTTPS transactions, and latency measurements.
It also emphasises the importance of validating the enabled security functionality.
After all, high throughput is of limited value if the tested configuration does not provide the protection the organisation actually requires.
For major enterprise deployments, a Proof of Concept should be designed around these principles.
A useful PoC is not simply a demonstration in which the vendor connects a firewall and shows that internet access works.
It should reproduce the conditions that matter to the customer.
For example, a financial institution requiring TLS inspection should include representative encrypted traffic and the cryptographic parameters used in its environment.
A business operating high-volume APIs should test connection establishment rates and application transaction performance.
An organisation requiring IPS, Application Control, malware protection, and extensive logging should verify performance with that combination enabled.
Relevant measurements may include:
-
Sustained inspected throughput.
-
Application transaction rates.
-
Connection establishment rates.
-
Concurrent sessions.
-
Application latency and response times.
-
Packet loss and failed transactions.
-
Resource utilisation under load.
-
Behaviour during HA failover.
These measurements provide a far more useful picture of expected performance than an isolated datasheet number.
They also help distinguish a firewall capacity problem from other issues within the network or application infrastructure.
Seven Questions Every IT Director Should Ask Before Buying an NGFW
A well-designed procurement process should require more than a quotation and a technical datasheet.
Before selecting a device, the customer should obtain clear answers to seven essential questions.
1. What throughput can the device sustain with all required security features enabled simultaneously?
The answer should refer to the intended deployment configuration, not to separate best-case benchmarks.
2. Does the quoted throughput include TLS decryption and inspection?
If not, the encrypted traffic workload must be assessed separately.
3. What traffic profile was used in the performance test?
Packet sizes, application mixes, transaction sizes, session patterns, and encryption levels can materially affect results.
4. What are the connection-processing limits?
Concurrent sessions, new sessions per second, and inspected TLS connection rates should be considered alongside bandwidth.
5. How much growth and peak-load headroom is available?
The firewall should be evaluated against future requirements, not only average traffic observed today.
6. What happens when one HA node fails?
The remaining infrastructure should be able to sustain the service levels defined by the customer.
7. Which software versions, subscriptions, and security policies were used during testing?
Licensing, firmware versions, and enabled inspection features can influence the available functionality and measured performance.
These questions may sound demanding.
But they are far less expensive than discovering a major limitation after purchasing and deploying an enterprise security platform.
The Most Expensive Mistake Is Buying a Number Instead of a Solution
It is understandable that companies compare firewall models by performance, price, and technical capabilities.
Those factors are important.
But the purchasing process becomes unreliable when a single headline specification dominates the decision.
One manufacturer advertises impressive firewall forwarding performance.
Another highlights advanced threat prevention.
A third offers an attractive price.
None of these claims alone determines which product best fits a particular organisation.
The correct choice depends on the company's architecture, applications, traffic patterns, security requirements, growth expectations, and availability objectives.
Sometimes a more powerful and expensive appliance is justified.
Sometimes a smaller model with a carefully designed architecture meets the requirements more efficiently.
And sometimes the apparent need for a new firewall is actually caused by a different network bottleneck or an inefficient configuration.
An experienced engineering team should be prepared to investigate these possibilities before recommending additional hardware.
That is especially important in large infrastructure projects, where a wrong equipment choice can create long-term operational limitations and additional procurement costs.
The value of an NGFW is not measured by the largest number in its datasheet. It is measured by its ability to deliver the protection and performance the business actually needs.
What the 39 Gbps Figure Really Tells Us
Let's return to the figure that started this discussion.
Fortinet publishes 39 Gbps Firewall Throughput for the FortiGate 120G.
It also publishes 2.8 Gbps Threat Protection Throughput.
Both numbers are meaningful.
Both describe legitimate product capabilities under different test conditions.
Neither should be ignored.
But neither should be treated as a universal answer to every customer's performance requirements.
The job of a professional infrastructure provider is not simply to find an attractive specification and recommend the corresponding appliance.
It is to understand the required security controls, examine network traffic, estimate growth, identify potential bottlenecks, and establish measurable acceptance criteria.
That is where responsible firewall selection begins.
Because real network security is not just about moving packets quickly.
It is about inspecting traffic, detecting threats, enforcing policies, and allowing business applications to continue operating reliably.
And before approving the next firewall purchase, every IT director should ask one final question:
“Are we buying the performance advertised in the datasheet — or the performance our business will actually receive?”
The answer could change the entire project.