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.

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

• 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.

Initial classification still takes place in SlowPath: the kernel and, where applicable, the DPI engine inspect the connection. After the TCP handshake completes or one packet passes in each direction, SFOS can place an eligible flow in the FastPath connection cache. FastPath is therefore not an uninspected bypass; it only processes the state programmed by the kernel. Ineligible protocols such as IP-in-IP remain in SlowPath.

For sizing, this is important because a quick test does not prove that every production flow uses the same path. Sophos lists Firewall and IPsec Acceleration for all XGS appliances. Dedicated PKI Acceleration for certificate processing of inspected TLS flows is documented only for XGS 4300, 4500, 5500, 6500, 7500, and 8500. The Gen. 2 desktop models XGS 88/88w, 108/108w, 118/118w, and 128/128w use Virtual FastPath in the x86 kernel instead of a dedicated Xstream Flow Processor.

The limits are narrower for virtual and software appliances. According to the SFOS 22 help, Virtual FastPath is supported only with VMware ESXi and the NIC drivers igc, e1000, e1000e, and vmxnet3. VFP is automatically turned off on other hypervisors, in cloud deployments, or with unsupported drivers. The firewall continues to work, but without this FastPath enhancement. For e1000 and e1000e, Sophos specifies a maximum MTU of 3500 bytes, and for the other supported drivers a maximum of 9000 bytes. These are platform limits, not a reason to turn on jumbo frames without an end-to-end test.

PKI Acceleration does not accelerate all TLS processing. For TLS 1.2 and TLS 1.3 flows inspected by the DPI engine, it only offloads the re-signing of X.509 server certificates with RSA authentication up to 4096 bits. Symmetric encryption, web proxy traffic, and SSL VPN connections terminating on the firewall do not benefit from it.

Certain functions or traffic types can restrict 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

For IPsec, the XFRM stack offloads ESP encapsulation, encryption, decapsulation, and decryption based on the phase 2 SA. SAs using 3DES, BlowFish, or MD5, SAs on virtual interfaces such as VLANs, and IPsec traffic over VLAN or wireless interfaces aren’t offloaded. The tunnel can still work, but it then consumes more host CPU.

Security policies don’t categorically prevent offloading. A rule without IPS, web filtering, antivirus, or application control can switch after the handshake or initial packets; with application control, Sophos states that the decision occurs after about eight packets. For STARTTLS with Don’t decrypt, it occurs after about 15 packets. The first packets can therefore still appear in SlowPath even though the later flow is accelerated.

Practical rule: Offloading isn’t a security objective. Don’t remove protection profiles or inspection just to reach FastPath. The required protection and reproducible measurements for throughput, CPU, and the application are what matter.

For HA, look especially closely. Active-active HA does not support Firewall Acceleration. In active-passive HA, Firewall and IPsec Acceleration are used only by the primary node. HA sizing should therefore not simply extrapolate standalone lab values to both nodes.

Troubleshooting can also affect measurements. With Packet Capture or iftop, SFOS sends traffic through SlowPath temporarily by default. If offloading remains active during the capture, a standard Packet Capture cannot record FastPath traffic. A missing packet therefore does not prove that the firewall did not process the flow; Sophos directs FastPath capture requirements to Support. Always document performance measurements and capture results with the time, test method, firmware version, interface type, and active policy.

Acceleration is turned on by default on supported platforms. Turning Firewall or PKI Acceleration on or off restarts IPS or the DPI engine, while changing IPsec Acceleration restarts all IPsec tunnels. Such changes belong in a maintenance window, not an improvised performance test. First use Log Viewer, Packet Capture, IPsec Troubleshooting, and a clear test case to confirm that the suspicion fits.

Read and control PKI acceleration correctly

The configured state and the effective state aren’t the same. Read the setting with:

show ips-settings

PKI acceleration is enabled by default on supported XGS models. enabled is effective only while firewall acceleration is also running. If PKI acceleration is enabled but firewall acceleration is off, SFOS reports enabled (inactive). On unsupported SFOS versions or models, it appears as disabled; changing the CLI setting can’t provide missing hardware or platform support.

Change the global setting through the IPS command tree:

set ips pki-acceleration disable
set ips pki-acceleration enable

Switching it restarts IPS or the DPI engine, so it belongs in a maintenance window. Record the current value and firewall acceleration status first. Then check show ips-settings, IPS and DPI status, and a real TLS flow decrypted by the DPI engine. This is the only meaningful way to confirm that certificate re-signing, latency, CPU, and the application still behave as expected. If the expected effect doesn’t occur, restore the previously recorded value.

Check IPsec acceleration in a controlled way

Read the global state first:

system ipsec-acceleration show

IPsec acceleration is enabled by default and offloads eligible phase 2 SAs from SlowPath. An enabled global state does not prove that a specific SA is offloaded. 3DES, BlowFish, and MD5 are excluded, and the interface and platform boundaries described above still apply.

A change applies to the whole firewall and restarts all IPsec tunnels. disable is therefore not a test for one tunnel. If a clear fault justifies an A/B test, first document tunnel state, SAs, CPU, throughput, and test traffic. These two opposite changes are available in the maintenance window:

system ipsec-acceleration disable
system ipsec-acceleration enable

After each change that is actually performed, verify show, tunnel establishment, phase 2 SAs, routing, firewall rules, and real traffic in both directions again. Restore the original value if there is no reproducible improvement. Do not retain an obsolete cryptographic profile merely to make a performance comparison possible.

Switch firewall acceleration only in a maintenance window

First read the current state in the Device Console:

system firewall-acceleration show

On supported platforms, firewall acceleration is enable by default. According to Sophos, every change causes an outage and restarts IPS or the DPI engine. disable is therefore not a casual A/B test during production. The firewall continues to process traffic fully, but without the FastPath performance benefits.

These two commands are available for a planned change. Don’t run them immediately one after the other as a test block, because each transition can interrupt traffic again:

system firewall-acceleration disable
system firewall-acceleration enable

After each required transition, check show again, IPS and DPI status, new sessions, published services, VPN, throughput, CPU, and Log Viewer. Don’t blindly overwrite a displayed disabled with enable: DoS, active-active HA, FastPath failing to load, or an unsupported VM, hypervisor, or NIC driver combination can also prevent acceleration. enable can’t force a working FastPath on a technically unsupported platform.

Checking Performance in Operation

Datasheet values help before purchase. In operation, you need other tools. It is important to separate the terms: the Control Center does not show datasheet performance, but current operating indicators. The Performance tile is based on load average across CPU cores. Values above the number of available cores mean that more work is pending than the system can process at that moment.

The tile color follows fixed Sophos thresholds: Normal for a load average below 2, Warning from 2 to 5, and Alert above 5 CPU cores. This traffic light is a quick indicator, but it is not identical to the appliance’s individual overload threshold. Therefore, interpret the tile status together with the actual core count and the timeline.

CPU, memory, bandwidth, sessions, Decryption Capacity, and Decrypt Sessions are also relevant. Decryption Capacity is especially useful with TLS Inspection because it shows how strongly current SSL/TLS decryption uses the available decryption performance. Decryption details are not updated as second-by-second live metrics, but typically every five minutes. These values should always be read together with policy, rule, security profile, time, and traffic type.

Use System Graphs as a timeline

Under Diagnostics > System graphs, CPU Usage, Memory Usage, Load Average, Disk Usage, Live Users, Data Transfer Speed through WAN Zone, and individual interfaces can be compared across different time periods. First select the period of the incident and then only the graphs that match the affected function.

A peak is a correlation, not yet a cause. CPU, memory, or load average should therefore be compared with interface traffic, user count, logs, policy, and the exact test time. The timeline is particularly useful for distinguishing a brief outlier from recurring or sustained high load; by itself, it proves neither that the appliance is undersized nor that a specific service is faulty.

Read units and aggregation correctly

The CPU graph separates usage by user processes, system components, and remaining idle time. Memory shows Used, Free, and Total in MB. Load average, however, is not a percentage: Its three curves represent averages over one, five, and fifteen minutes. It must therefore be read together with the number of available CPU cores.

Disk Usage shows the percentage used by signatures, configuration files, reports, and temporary data. This is a functional breakdown in the graph and not the same view as the partitions shown by df -kh or the report watermark. Live Users counts users who were connected to the internet during the selected period and also shows the minimum, maximum, and average. It is not a count of configured user accounts.

For the WAN zone, separate graphs show upload and download, the combined total rate, and the rate per gateway. Depending on the view, current, minimum, maximum, and average values are shown. Sophos documents an important labeling error: WebAdmin displays KBps, but the values are actually in kbit/s. Reading the display as kilobytes per second introduces a factor-of-eight error.

Important for VLANs: Separate interface graphs are available for physical interfaces, wireless LAN, WAN interfaces, and VLAN interfaces in the WAN zone. VLANs in other zones are combined with their physical parent interface in the graph. A peak on the parent port therefore cannot be assigned to a single internal VLAN without another measurement.

The interface graphs show received and transmitted bits as well as drops, errors, and collisions. Resolution is aggregated for longer periods: Today and yesterday use five-minute averages, the week uses 15 minutes, the month uses six hours, and the year uses one day. Short peaks can therefore disappear in a monthly or yearly view; start with the narrowest suitable period for an incident.

Practical workflow:

1. Check Control Center: Monitor CPU, RAM, interface utilization, and warnings.
2. Open Log Viewer: Does the expected firewall rule apply and is logging enabled?
3. Check policy and security profiles: Which functions affect the traffic in question?
4. Use Packet Capture: Can you see packets, response packets, NAT, and drops?
5. Conduct a link test: Use iPerf or a defined download to check which path is really slow.
6. Note offloading context: Interface type, HA mode, VPN type, PPPoE, WAF, SSL VPN, or Packet Capture can influence the measurement.
7. 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.

The daily Sophos Firewall admin checklist shows how the Control Center, System graphs, reports, and admin events are combined in a short recurring workflow.

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:

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

FAQ