Home Resources Firewall sizing Throughput explained
Firewall throughput explained: which number to trust
One datasheet page carries six throughput figures for the same appliance, and the largest is roughly ten times the smallest. All six are honest. They measure different work, under different conditions, and the footnote decides what each one means.
The short answer
Each published throughput figure answers a different question. Firewall throughput describes forwarding. Threat protection throughput describes forwarding plus inspection. Comparing one against the other produces an answer that is wrong by a wide margin.
The label is a vendor convention and the footnote is the specification. Two figures carrying the same name and different footnotes describe different tests, and the footnote is where packet size, traffic mix, enabled services and logging state are stated.
Standard methodologies exist. RFC 9411 is the current one for network security devices. A figure that names a standard methodology carries more information than one that names none.
No deployment reproduces a test. Six specific properties of production traffic consume the difference, and all six are listed below so you can say which ones apply to a given customer.
The figures, and what each measures
Vendors publish multiple throughput figures because the appliance has multiple modes of work with genuinely different costs.
Publishing one number would hide that. Publishing six is more informative and it puts the burden of selecting the right one on the reader. This table is that selection.
| Figure | Typically measured with | Answers the question | Sizing use |
|---|---|---|---|
| Firewall throughput | Large fixed-size packets, no content inspection, minimal policy | How fast can this hardware forward? | Comparing models within one vendor's range |
| Application-aware or NGFW throughput | An application traffic mix with identification enabled, usually with logging | What does policy enforcement cost without content scanning? | Sites enforcing application policy but not scanning content |
| IPS throughput | A stated traffic profile with intrusion prevention enabled and little else | What does signature matching cost? | Sites where intrusion prevention is the only inspection |
| Threat protection throughput | An enterprise traffic mix with several security services running together | What does this appliance do when configured the way most people configure it? | The starting point for most sizing |
| IPsec VPN throughput | Tunnel traffic at a stated packet size and cipher suite | What does the crypto path sustain? | Sites terminating site-to-site or remote-access tunnels |
| TLS or SSL inspection throughput | Its own conditions, where the vendor publishes it at all | What does decryption plus inspection cost? | Any site intending to inspect encrypted traffic |
This describes the categories of figure that current enterprise firewall datasheets publish and the conditions each typically carries, checked 12 August 2026. The category names vary by vendor and the exact service set inside a category varies by datasheet revision. We publish no throughput values, because we run no lab and any number here would be a vendor figure repeated without its context.
Three rules follow from the table, and together they remove most comparison errors.
- Compare a figure only against a figure measured the same way. Setting one vendor's firewall throughput against another vendor's threat protection throughput is the most common error in this category.
- Select the figure that matches the services the customer will enable, rather than the services on the quote. Those two lists differ more often than they match.
- Treat a missing figure as a question rather than as an absence of cost. Where a vendor publishes no decryption number, decryption still costs something. Ask the reseller for the figure in writing.
The footnote is the number
The most informative line on a firewall datasheet is set in the smallest type on the page.
A throughput figure without its test conditions is a number without units. The footnote supplies the units, and five properties in it change the result by more than the difference between two competing appliances.
| Footnote property | What to check |
|---|---|
| Packet size or object size | A fixed large packet size flatters the figure. An HTTP object size of 64 KB or more does the same for application-layer tests. Smaller is closer to production. |
| Traffic mix | Whether the test used a single protocol or a mix intended to resemble enterprise traffic. A single-protocol test is easier to sustain. |
| Services enabled | The named list. Absence of a service from the list means it was off during the test. |
| Logging state | Whether logging was enabled, and to what destination. Logging every session to a remote collector is a real cost and is frequently off in testing. |
| Software version | The release the figure was measured on. Inspection engines change between releases, and figures are not always re-measured. |
The footnote properties listed here are the ones that appear in current Fortinet, Palo Alto Networks, Cisco and Check Point datasheets, checked 12 August 2026. Which properties a given datasheet states varies by vendor. Where a property is absent from the footnote, treat it as unspecified rather than as favorable.
From the operations side
Keep the datasheet revision that a purchase was sized against, filed with the customer record. Vendors revise figures between datasheet versions, and they occasionally revise them downward when a test methodology tightens. Eighteen months later, when the appliance is saturated and somebody asks why it was chosen, the argument is straightforward if the document that was actually read is on file. Without it, the conversation becomes about judgement instead of about evidence.
Where the standards sit
Standard benchmarking methodologies for this equipment exist, and vendor datasheets typically state their own conditions instead.
That is worth understanding rather than complaining about. The standards have a history, and each one solved the problem of its period.
| Document | Scope | Relevance now |
|---|---|---|
| RFC 2544 | Benchmarking methodology for network interconnect devices | The origin of fixed-packet-size forwarding tests. Underlies many headline throughput figures. |
| RFC 3511 | Benchmarking methodology for firewall performance, published 2003 | Predates application identification and routine content inspection. Its session and connection-rate definitions remain useful. |
| RFC 9411 | Benchmarking methodology for network security device performance, published March 2023 | The current reference. Defines terminology and test procedures for modern security devices and addresses TLS inspection explicitly. |
Titles and scope taken from the published documents: RFC 2544, RFC 3511 and RFC 9411, all checked 12 August 2026. RFC 9411 is an Informational document published in March 2023 and includes TLS inspection among the security features in its test scope. The observation that vendor datasheets more often state bespoke conditions than cite one of these is our own reading of current datasheets rather than a vendor statement.
The practical use is short. Where a vendor figure cites a standard methodology or a recognized independent test, it carries information about how it was produced, and two such figures from different vendors are more comparable than two bespoke ones. Where a figure cites nothing, it still tells you what that vendor can achieve under conditions it selected, which is worth having and is not a basis for cross-vendor comparison.
Six things that consume the gap
Production throughput sits below the printed figure for six identifiable reasons.
Naming them individually matters, because they apply unevenly. A customer with a small policy and no decryption sits closer to the printed figure than a customer with neither.
1. Packet size
A test using large packets moves more bytes per decision made. Production traffic contains a large share of small packets, particularly acknowledgements and control traffic, so the same appliance performs more decisions for each byte it carries. This is the single largest reason a forwarding figure overstates forwarding in production.
2. Logging
Writing a log entry per session, and forwarding it to a collector, consumes processing and interface capacity. Many test configurations reduce or disable it. Most production configurations log everything, because the customer has a compliance obligation or the MSP needs the record.
3. Decryption
Most traffic on a modern network is encrypted. Inspecting it requires the appliance to terminate and re-establish sessions and perform cryptographic work in both directions, before performing any of the inspection it would otherwise have done. This is the largest single variable in most sizing models and it has its own page.
4. Policy depth and order
A test policy is short and ordered for the test. A production policy accumulates rules over years, and traffic matching a rule near the bottom has been evaluated against everything above it. Platforms differ in how much this costs, and no platform is entirely free of it.
5. Session establishment rate
Setting up a session costs more than carrying one. A network with many short-lived connections spends a large share of its capacity on establishment, and that cost does not appear in a throughput figure at all.
6. High-availability state synchronization
Members of a high-availability pair exchange session state continuously so that a failover preserves connections. That synchronization consumes capacity on both members, and it scales with session churn rather than with throughput. It is rarely present in a published test configuration.
Throughput's blind spot
Throughput is one limit among four, and it is frequently not the binding one.
An appliance can be well inside its throughput figure and completely out of capacity. The two session limits are separate hard ceilings, and the symptoms when either is reached look nothing like a bandwidth problem.
| Limit | What exhausts it | How it presents |
|---|---|---|
| Throughput | Sustained volume, especially inspected volume | Latency rises across the board, worst during known busy periods |
| Concurrent sessions | Many long-lived connections held at once | New connections fail while existing ones continue working normally |
| New sessions per second | Bursty short-lived connections, scanning, some monitoring tools | Intermittent connection failures with no pattern in the traffic volume |
| Crypto capacity | Tunnel throughput and decryption load together | VPN performance degrades while unencrypted traffic stays fine |
The four limits and their independence are properties of the architecture and are published as separate figures by every major vendor. The presentation column describes what these conditions look like on the estates we run, and is our observation rather than a vendor statement.
Crypto capacity is the limit most often left out of a sizing model, because it is counted in tunnels and concurrent users rather than in bits per second. What each platform publishes for it is covered on the remote access page.
Two networks reach the session-rate limit long before the throughput limit, and both are common in the MSP customer base. Retail estates with point-of-sale terminals generate many short transactions. Environments running thin clients or heavy web applications open and close connections continuously. In both cases the throughput graph looks unremarkable while users report intermittent failures.
Reading a datasheet in four steps
Given a datasheet and a customer requirement, this takes about ten minutes.
- Identify the service set the customer will run. Write it down before looking at any figure, so the figure does not influence the list.
- Find the published figure whose footnote matches that set. Where none matches exactly, take the closest one that includes more services rather than fewer, and note the difference.
- Read the footnote and record packet size, traffic mix, logging state and software version. These belong in the customer file alongside the recommendation.
- Check the other three limits on the same model. Concurrent sessions, new sessions per second, and VPN throughput and tunnel count. A model that clears throughput and fails a session limit is not a candidate.
Then apply the sizing method. The measurements that turn this into a recommendation are on the sizing page, and the vendor-specific reading for two particular datasheets is on the FortiGate and Palo Alto performance page.
The figure you sized against, checked against what it does
A number on a datasheet is a prediction. The estate is the measurement. We monitor throughput, session tables and inspection load across the firewalls we run for MSPs, on eight platforms, under your brand, from $29 per firewall per month. When a customer asks why their firewall is slow, the answer is already in the graph.
Get your rateCommon questions
What engineers ask with two datasheets open. Something missing? Tell us and we will add it.
What does firewall throughput actually mean?
It is the rate at which an appliance forwards traffic under a specific set of test conditions, usually with large fixed-size packets and content inspection switched off. It describes the forwarding path rather than the inspection path. The figure is useful for comparing models within one vendor's range, where the test conditions are consistent. It is a poor basis for sizing a deployment that will enable security services, because those services are the constraint in most production networks.
What is threat protection throughput?
It is throughput measured with several security services running together, typically intrusion prevention, application control, antivirus and logging, against a traffic mix intended to resemble enterprise usage. It is the closest published figure to what most deployments actually do, which makes it the right starting point for sizing. The traffic mix and the exact service set differ between vendors and sometimes between datasheet revisions from the same vendor, so the figure is comparable across models more safely than across brands.
What is the difference between IPS throughput and NGFW throughput?
IPS throughput is measured with intrusion prevention enabled and generally nothing else. NGFW throughput is measured with application identification and intrusion prevention enabled together, and usually with logging on. Neither typically includes decryption or antivirus scanning. The naming is a vendor convention rather than a standard, so two vendors using the same label may be running different service sets. Read the footnote and compare the conditions rather than the labels.
Is there a standard for measuring firewall performance?
Several exist. RFC 2544 defines benchmarking for network interconnect devices and is the source of the fixed-packet-size tests behind many forwarding figures. RFC 3511 defined a firewall-specific methodology in 2003, before application identification and content inspection were standard. RFC 9411, published in March 2023, defines benchmarking terminology and methodology for network security device performance and covers TLS inspection explicitly. Vendor datasheets more commonly state their own test conditions than cite one of these, so a figure that names a standard methodology is worth more than one that does not.
Why is real throughput lower than the datasheet figure?
Production traffic differs from test traffic in six ways that all cost capacity. Real packets are smaller on average, so the appliance makes more decisions per byte carried. Logging is usually on. Most traffic is encrypted, and inspecting it requires decryption. Policies are longer and less ordered than a test policy. Session establishment rates are higher and burstier. And a high-availability pair spends capacity synchronizing state. None of these are faults in the appliance, and together they explain most of the gap.
Which throughput figure should I use for sizing?
The one whose footnote matches the services the customer will actually enable, which for most deployments is the threat protection or NGFW figure with decryption accounted for separately. Then confirm the model also clears the concurrent session count, the new sessions per second rate and the VPN load, because those are separate limits and a model chosen on throughput alone frequently fails one of them. Never compare one vendor's headline figure against another vendor's inspection figure.