Correctly Interpreting Sophos Firewall Performance Data

The performance data of a Sophos Firewall is important for sizing but is often misinterpreted. The highest firewall throughput in the datasheet is not automatically the performance that a site achieves with IPS, Web Protection, TLS Inspection, VPN, NAT, Reporting, and many concurrent users.

When selecting a model, you should not just look at a single Gbit/s figure. What matters is which protection functions are active, what traffic flows through the firewall, and what reserves the environment needs in everyday use. The Sophos Firewall Sizing Guide explains model selection; this article explains how to interpret the underlying performance metrics.

Sophos Firewall XGS Series table with performance data — Performance data are comparative values under defined test conditions, not a guarantee for every real environment.

Quick Rule for Sizing

In practice, the pure firewall throughput is usually not the best starting point.

Only routing and simple firewall rules: Consider firewall throughput and IMIX.
Normal corporate network with IPS and Application Control: Give more weight to NGFW or Threat Protection values.
Many HTTPS connections with decryption: Plan for TLS Inspection performance and CPU reserve.
Many VPN connections: Consider IPsec or Remote Access requirements separately.
Virtual firewall: Take hypervisor, CPU, RAM, storage, and virtual network cards as seriously as the Sophos license.

If it is unclear whether hardware or a virtual appliance is better suited, Sophos Firewall - Hardware or Virtual Appliance? can help as a decision aid.

Why Datasheet Values Are Not Enough

Performance values are determined under defined laboratory conditions. This is sensible because it makes models comparable. However, a productive environment behaves differently:

Packet sizes are mixed.
Users generate parallel sessions.
Security profiles inspect traffic at different depths.
HTTPS traffic requires significantly more resources with TLS Inspection.
VPN, SD-WAN, NAT, logging, and reporting run in parallel.
WLAN, switches, clients, servers, and providers influence perceived performance.

A datasheet value is therefore a comparative value, not a promise for every single flow. For solid sizing, you should plan with reserves and not consider the later operational functions only after purchase.

The Most Important Metrics

Metric	What it is useful for	Typical Misinterpretation
Firewall Throughput	Comparison for simple Layer-3/Layer-4 traffic	Often read as real internet throughput with all security functions
Firewall IMIX	More realistic mix of different packet sizes	Ignored, although real networks rarely have only large packets
IPS Throughput	Traffic with Intrusion Prevention	Underestimated when IPS is later active for many rules
NGFW Throughput	Firewall with additional next-generation functions like IPS and Application Control	Confused with pure firewall throughput
Threat Protection	Stronger approximation for activated protection functions	Understood as a fixed minimum value instead of a comparative metric
TLS Inspection	HTTPS decryption and inspection	Forgotten in sizing, although it can be very resource-intensive
IPsec VPN	Site networking and encrypted tunnels	Planned only based on the internet connection, without considering the counterpart, packet sizes, and CPU
Sessions and Connections per second	Many users, web traffic, server publishing, short connections	Rarely checked, but can be relevant with many clients or published services

Firewall Throughput and IMIX

Pure firewall throughput describes a comparatively simple processing of traffic. This value is useful when a firewall mainly routes, performs NAT, and processes classic firewall rules.

IMIX is closer to real network load because different packet sizes are mixed. This is important because small packets load a firewall differently than large downloads. In corporate networks, there is rarely just one clean large data stream. Web accesses, DNS, VoIP, cloud applications, updates, and file transfers create different patterns.

For sites with normal user traffic, IMIX is often more meaningful than the most attractive maximum value.

IPS, NGFW, and Threat Protection

Once IPS, Application Control, Web Protection, or malware scanning are active, the firewall has to do more than just forward packets. The firewall must classify traffic, recognize patterns, apply rules, and inspect content depending on the policy.

The terms are often mixed:

IPS evaluates traffic based on signatures and rules for known attack patterns.
NGFW describes firewall performance with additional functions like IPS and Application Control.
Threat Protection is a stronger approximation for environments where multiple protection functions are active simultaneously.

For a company that actually operates the Sophos Firewall as a security gateway, NGFW and Threat Protection values are usually more relevant than pure firewall throughput.

Realistically Planning TLS Inspection

TLS Inspection is one of the biggest performance factors. The firewall decrypts HTTPS connections, inspects the content, and re-encrypts the connection. This generates CPU load and can be noticeably affected by the cipher suite, target server, client, exceptions, and policy.

TLS Inspection should therefore not be activated casually. A gradual rollout with a pilot group, exceptions, monitoring, and clear troubleshooting is sensible. The article Introducing Sophos Firewall TLS Inspection Correctly describes the operational process.

The CA certificate must also be properly distributed. For clients, Installing the Sophos Firewall CA Certificate for HTTPS Scanning is the appropriate starting point.

Separately Considering VPN Performance

VPN performance depends not only on the firewall model. The counterpart, internet connection, latency, packet sizes, MTU/MSS, encryption parameters, routing, and parallel tunnels are also relevant.

For site-to-site connections, you should realistically estimate the planned data flows: file transfers, backups, ERP, VoIP, RDP, monitoring, and replication behave differently. For remote access, the client device, WLAN, provider, and VPN client are additional factors.

If a VPN link seems slow, you should not only check the datasheet value. A defined link test with iPerf is usually more meaningful than a browser speed test.

What Influences Real Performance

In practice, several factors act simultaneously:

Active security profiles per firewall rule
TLS Inspection and exceptions
IPS policy and signature scope
Web Protection, Application Control, and malware scanning
NAT, DNAT, server publishing, and WAF
IPsec, SSL VPN, Sophos Connect, and site-to-site tunnels
Logging, reporting, Central Reporting, and Syslog
Many small sessions instead of fewer large downloads
Firewall Acceleration, FastPath, IPsec Acceleration, and traffic that cannot be offloaded
HA operation, firmware status, and hotfixes
Virtual resources for software or cloud appliances

Therefore, performance should always be checked in the context of the specific policy. A firewall rule without security profiles behaves differently than a rule with IPS, web filter, application control, and TLS Inspection.

Correctly Interpreting FastPath and Offloading

Modern Sophos Firewalls do not process every data stream the same way. Depending on the appliance, firmware, rule, security profile, and type of traffic, traffic can be accelerated or inspected in a slower processing path. Important terms for this are FastPath, Firewall acceleration, PKI acceleration, and IPsec acceleration.

For sizing, this is important because a quick test does not prove that every productive data stream uses the same path. Certain functions or types of traffic can limit or prevent offloading, for example:

SSL VPN
WAF and proxy traffic
QoS and DoS
Wireless, RED, LAG, and PPPoE
Fragmented IP traffic
Certain bridge, HA, or virtualization scenarios

Troubleshooting can also influence measurement values. When Packet Capture or iftop is running, traffic may be processed differently than in normal operation. Therefore, performance measurements and packet capture results should always be documented with time, test method, firmware status, interface type, and active policy.

IPsec Acceleration is a special case. Changes to it can restart tunnels and require a maintenance window. In a production environment, such settings should not be switched as a quick attempt but first checked with Log Viewer, Packet Capture, IPsec Troubleshooting, and a clear test case to see if the suspicion really fits.

Checking Performance in Operation

Datasheet values help before purchase. In operation, you need other tools:

Check Control Center: Monitor CPU, RAM, interface utilization, and warnings.
Open Log Viewer: Does the expected firewall rule apply and is logging enabled?
Check policy and security profiles: Which functions affect the traffic in question?
Use Packet Capture: Can you see packets, response packets, NAT, and drops?
Conduct a link test: Use iPerf or a defined download to check which path is really slow.
Note offloading context: Interface type, HA mode, VPN type, PPPoE, WAF, SSL VPN, or Packet Capture can influence the measurement.
Note the time: Load peaks, backups, updates, or reports can distort results.

For a quick delineation of the WAN line, Conducting a Sophos Firewall Internet Speed Test via SSH helps. For end-to-end tests between two systems, Testing Sophos Firewall Performance with iPerf is more suitable. If a rule does not apply as expected, Testing Sophos Firewall Rules Specifically is appropriate.

Typical Sizing Mistakes

Only the highest firewall throughput is compared.
TLS Inspection is planned but not included in the performance reserve.
VPN and Remote Access are evaluated based on the number of users rather than actual usage.
The internet connection is considered, but internal east-west traffic is not.
Virtual firewalls are operated on overloaded hosts.
Reporting, logging, and Central connection are only considered afterwards.
Growth, new locations, additional VLANs, or server publishing are missing in the planning.
No distinction is made between laboratory value, real value, and user experience.

Practical Sizing Checklist

Before choosing a model, these points should be clarified:

Current and planned internet bandwidth for the coming years.
Number of users, devices, servers, and locations.
Proportion of web traffic, cloud applications, VoIP, backups, and file transfers.
Planned security functions per traffic group.
Scope of TLS Inspection and necessary exceptions.
Number and use of IPsec, SSL VPN, and Sophos Connect connections.
Need for WAF, Mail Protection, RED, WLAN, or Central Reporting.
Expected reserves for updates, growth, and load peaks.
Operating model: XGS hardware, virtual appliance, cloud, or HA cluster.

FAQ

Which Sophos Firewall performance value is most important for model selection?

This depends on the application. For simple firewall rules, firewall throughput is relevant. For typical corporate environments with IPS, Web Protection, and Application Control, NGFW or Threat Protection values are usually more meaningful.

Why doesn't a firewall achieve the highest datasheet value?

The highest value is achieved under defined test conditions. In reality, packet sizes, security profiles, TLS Inspection, VPN, NAT, logging, parallel sessions, clients, and counterparts influence the result.

Must TLS Inspection always be included in sizing?

Yes, if TLS Inspection is to be used productively today or later. HTTPS decryption is resource-intensive and should be planned with reserve, pilot group, and a clean rollout.

How do you check if the firewall or the client is slow?

You compare multiple tests: download directly on the firewall, test from a wired client, iPerf between defined endpoints, Log Viewer, Packet Capture, and interface utilization. A single measurement is rarely sufficient.

Are virtual Sophos Firewalls slower than hardware appliances?

Not automatically. Virtual firewalls can perform very well if CPU, RAM, storage, and network are properly planned. However, performance depends more on the virtualization platform than with a dedicated XGS hardware appliance.

Why can Packet Capture influence a performance measurement?

Packet Capture is an analysis tool, not a neutral speed test. Depending on traffic and offloading path, processing during a capture can behave differently than in normal operation. Therefore, capture results should be documented with test time, filter, interface, and policy.