Sophos Firewall Sizing Guide: Properly Dimensioning an XGS Appliance

Sophos Firewall sizing is not just about the number of users. A firewall can be under very different loads with the same number of users: due to internet bandwidth, TLS Inspection, IPS, VPN, Web Protection, WAF, reporting, HA, many VLANs, or many simultaneous connections.

Good sizing ensures that the Sophos Firewall not only works on the first day but also has reserves with activated protection functions, realistic growth, and clean operation. For the decision between hardware and virtual appliance, see Sophos Firewall - Hardware or Virtual Appliance?.

Sizing Objective

The goal is not to find the smallest model that is just sufficient under ideal lab conditions. In practice, the firewall should remain stable even when several things happen simultaneously:

• many users work in parallel,
• TLS Inspection or IPS is active,
• site-to-site or remote-access VPNs are running,
• reporting and logging generate additional load,
• backups, updates, or support diagnostics run in the background,
• a site grows or gains more bandwidth.

Therefore, always plan with reserves. A tightly dimensioned firewall later generates support effort: slow internet connections, high CPU load, packet loss, sluggish WebAdmin, unstable VPN connections, or lack of reserves for new security functions.

Key Sizing Factors

Internet Bandwidth and Traffic Profile

The booked internet line is a good starting point, but not the whole truth. It is important how much of it is actually used simultaneously and what traffic runs through the firewall.

Check:

• symmetrical or asymmetrical line,
• peak traffic during business hours,
• many small web sessions or few large downloads,
• cloud backups, Microsoft 365, VoIP, online meetings,
• site networking via VPN or SD-WAN,
• internal traffic between VLANs that is also routed through the firewall.

If the firewall also acts as an internal routing and segmentation device, you must plan not only WAN throughput but also east-west traffic. The basics of zones, VLANs, and interface design are in Configure Sophos Firewall Zones and Interfaces.

Protection Functions

The more security modules are active, the more robust the appliance must be. Particularly relevant are:

• IPS,
• Web Protection,
• Application Control,
• SSL/TLS Inspection,
• Zero-Day Protection,
• WAF,
• Mail Protection,
• Threat Feeds,
• Reporting and Log Viewer.

Data sheet values are only comparable if it is clear which function was measured. Firewall throughput without security inspection is not the same as threat protection or TLS inspection throughput. For productive environments, you should not only look at the highest marketing value but at the metric that fits your own use.

With TLS Inspection, it is also important whether the organisation can technically and organisationally manage the rollout cleanly. The practical procedure is described in Roll Out Sophos Firewall TLS Inspection Cleanly.

Users, Devices, and Sessions

The number of users remains important but is not sufficient. An office with 50 users, few cloud services, and no TLS Inspection loads the firewall differently than a site with 50 users, terminal servers, many SaaS applications, VoIP, guest network, IoT, remote access, and multiple server zones.

Additionally, consider:

• number of devices per user,
• guest and IoT networks,
• servers, printers, cameras, and special devices,
• simultaneous sessions,
• many small DNS or web requests,
• remote access users,
• automated systems like backup, monitoring, or EDR.

In mixed environments with many VLANs, you should plan more according to traffic flows than just headcount.

VPN, SD-WAN, and Site Networking

VPN can heavily load a firewall, especially when many tunnels, high bandwidth, or many remote access users come together.

Plan for:

• site-to-site IPsec,
• route-based VPN with XFRM interfaces,
• remote access via Sophos Connect or SSL VPN,
• SD-WAN policy routes,
• multiple WAN lines,
• failover scenarios,
• MTU/MSS issues on VPN routes.

For VPN performance, you should not only consider the tunnel status. What matters is whether the productive traffic runs stably with activated rules, NAT, routing, and security inspection. For routing and VPN paths, IPsec Route on Sophos Firewall and SD-WAN Routing for Reply Packets and System Traffic are suitable deep dives.

Logging, Reporting, and Storage

Logging helps in operation but also generates load and storage requirements. Those who use many firewall rules with logging, web filter, IPS, application control, and Central Firewall Reporting should clarify reporting requirements early.

Check:

• Which rules should have logging active?
• How long must logs be available?
• Is Central Firewall Reporting in Sophos Fusion (formerly Sophos Central) used?
• Is there Syslog or SIEM?
• Must reports be created regularly?
• Are log data needed for troubleshooting or compliance?

For longer evaluations, the firewall alone is often not the right place. Then you should plan for Central Firewall Reporting or a Syslog/SIEM export.

Hardware, Virtual, or Cloud?

XGS Appliance

An XGS Appliance is usually the most predictable option for traditional sites. Hardware, ports, support, lifecycle, and performance are defined as a complete package.

Advantages:

• dedicated firewall hardware,
• clear port and expansion options,
• simple support and RMA handling,
• predictable performance,
• less dependency on a hypervisor.

Hardware is particularly useful when the firewall is the central security and routing point at the site.

Virtual Sophos Firewall

A virtual firewall fits well in data centres, cloud environments, or virtualised network segments. Performance then strongly depends on CPU, RAM, storage, hypervisor, virtual network cards, and host load.

Important:

• CPU resources must not be permanently overbooked.
• Virtual NICs and port groups must be cleanly separated.
• Storage latency can affect logging and reporting.
• Backup and restore must fit the virtualisation platform.
• HA and failover design must be planned in advance.

Licensing and the decision between hardware and virtual appliance should be checked separately. For this, see Sophos Firewall - Hardware or Virtual Appliance?.

From Requirements to the Right Model

A fixed mapping such as “50 users = model X” would be misleading. The technical limits and throughput figures for each appliance do not provide a universally valid user limit. Two sites with the same headcount may need completely different models because of TLS inspection, packet sizes, sessions, and east-west traffic.

Check Hard Exclusion Criteria First

Before comparing throughput figures, the non-negotiable requirements must fit:

• form factor, noise, power supply, and operating environment,
• number, type, and speed of fixed and modular ports,
• local storage and reporting requirements,
• required features, subscriptions, and support options,
• documented maximums for sessions, new connections, and VPN tunnels,
• redundancy of power supplies, interfaces, and the HA node.

A model is excluded as soon as one of these criteria is not met, even if its nominal firewall throughput is high enough. The model matrix and detailed specifications change with the product generation, so always use the current official Sophos data sheet before ordering.

Treat Appliance Classes as Form Factors

Desktop appliances often suit small sites and branches. 1U models typically offer more port density, expandability, and performance headroom for central or distributed sites. 2U models target very high bandwidth, session load, redundancy, and enterprise environments. These classes do not define a reliable user range.

Feature scope also matters at the entry level: according to the Sophos XGS Appliance data sheet, the XGS 88 and XGS 88w do not support certain features, including on-box reporting, dual AV scanning, WAF AV scanning, and email MTA functionality; Sophos recommends the XGS 108 or XGS 108w when these features are required. This is a hard selection criterion that additional throughput headroom cannot compensate for.

Check Candidates with the Sizing Tool

After excluding unsuitable models, compare the remaining candidates using the current data sheet and the Sophos Firewall Sizing Tool. The tool is available to partners through the Sophos Partner Portal, and Sophos also offers sizing assistance. Supply the documented traffic profile, all protection functions, VPN, internal flows, HA, and growth—not just user count and WAN bandwidth. The result is a reasoned shortlist, not a guarantee of production performance.

Reserve, HA, and Growth

A firewall should not run close to its limit permanently. Reserves are important for:

• growth of the internet line,
• new sites or VLANs,
• later activation of TLS Inspection or IPS,
• more remote access users,
• additional logging and reporting requirements,
• firmware updates with new functions,
• disruption situations and failover.

With HA, you must plan particularly carefully. In an active-passive design, a single node must be able to handle the productive load alone. Active-active is not a free pass for tight sizing because not every load is distributed linearly. The most important architectural points are in Understanding Sophos Firewall HA Cluster Variants.

As a rule of thumb, you should not plan on a firewall in new projects that already shows very high CPU, RAM, or session utilisation in normal operation. The article Correctly Interpreting Sophos Firewall Performance Metrics helps with later operational checks.

Practical Sizing Process

1. Capture the Initial Situation

First, describe the environment:

• sites and WAN lines,
• users and devices,
• VLANs and internal zones,
• server and DMZ services,
• VPN and remote access requirements,
• actively planned security modules,
• reporting and log requirements,
• HA or cloud requirements.

For a replacement or migration, supplement this inventory with measurements from the existing firewall. During representative peak periods, open Control center > System, expand the system view, and check CPU & Memory and Network, especially CPU, memory, bandwidth, sessions, Decryption capacity, and Decrypt sessions. A single quiet snapshot is not a reliable baseline; take several measurements on typical working days and during known load peaks.

2. Mark Critical Load Drivers

Then mark the points that can drive the model upwards:

• widespread use of TLS Inspection,
• many IPS-protected connections,
• high VPN throughput,
• many simultaneous sessions,
• many firewall rules with logging,
• WAF or Mail Protection,
• strong segmentation with internal traffic through the firewall,
• growth over the next three to five years.

3. Check Hard Requirements Against the Model Matrix

Now exclude unsuitable models. Check port count and speed, expansion modules, form factor, power and redundancy requirements, local storage, all required features, and documented maximums. The license must also cover the planned protection functions. Do this before comparing performance: missing ports, an unsupported feature, or an insufficient session limit cannot be offset by a good throughput figure.

4. Read Data Sheet Values Correctly

Data sheet values are maximum throughput figures measured by Sophos under ideal test conditions with Keysight-Ixia BreakingPoint; they do not guarantee production performance. Firewall Throughput uses HTTP traffic with a 512 KB response size. Firewall IMIX uses UDP packets of 66, 570, and 1518 bytes. The IPS test uses HTTP traffic, the default IPS ruleset, and a 512 KB object size. TLS Inspection is measured with IPS enabled, HTTPS sessions, and different cipher suites. Threat Protection combines firewall, IPS, Application Control, and Malware Prevention using Enterprise Traffic Mix. Real performance depends on the traffic profile, rules, encryption, packet sizes, and services running at the same time.

Therefore, use the metric that most closely matches the planned operation:

Important metrics:

• Firewall Throughput: only rough guidance for simple packet throughput without the full security mix.
• IPS Throughput: relevant for environments with active Intrusion Prevention.
• Threat Protection: often more realistic when several protection functions are active at the same time.
• TLS Inspection: important for environments with decrypted HTTPS traffic.
• IPsec VPN Throughput: relevant for site-to-site connectivity and VPN load.
• Concurrent Connections: important with many clients, web sessions, and services.

If several of these points are relevant at the same time, you should not only consider a single metric.

5. Determine Reserve

Before selecting the final model, do not simply add an arbitrary reserve percentage. Compare three scenarios instead:

• Normal peak: the highest realistic load with all planned protection functions.
• Failover peak: the same load on a single HA node and during a WAN-link failure.
• Future peak: expected bandwidth, sessions, and additional protection functions over the next three to five years.

A model is suitable only when its relevant data sheet metrics, ports, and licensed functions cover all three scenarios with a defensible reserve. That reserve can be smaller for a simple standalone site than for a central firewall, HA cluster, or rapidly growing environment.

6. Validate in Control Center

Sizing does not end with the order. After commissioning, open Control center > System during representative peak periods, expand the system view, and compare the available counters under CPU & Memory and Network with the assumptions:

• CPU and memory utilisation,
• WAN bandwidth and session numbers,
• Decryption capacity and Decrypt sessions when using TLS Inspection,

Use suitable measurements and observations to check the following as well:

• VPN throughput,
• WebAdmin response time,
• Log Viewer and reporting,
• packet loss or retransmits,
• performance after activating additional protection functions.

A single spike is less important than recurring or sustained saturation. In the expanded system view, the load average graph shows the previous week. If the load average exceeds the number of processor cores, the system had more work than it could process during that period. This is a concrete signal to review the sizing, enabled functions, or unusual traffic.

For reproducible measurements, Use iPerf Speedtest on Sophos Firewall for Troubleshooting can help. For simple WAN speed tests, Properly Evaluate Sophos Firewall Internet Speedtest is the right starting point.

7. Prepare an Acceptance Test and Backout Path

Before go-live, record the sizing assumptions and success criteria. Run the acceptance test with the complete production rule set and planned protection functions. Test normal peak load, VPN and inter-VLAN paths, and, for HA, the load on one node. Evaluate CPU, load average, memory, sessions, decryption capacity, packet loss, and the response time of important applications together; a single internet speed test is not enough.

For a hardware replacement, keep a current verified backup and a documented path back to the previous cabling until the test passes. If the new system misses the criteria, do not disable protection functions indiscriminately. First check the rule and routing path actually used, link negotiation, active inspection, and, for virtual firewalls, host resources. If the cause cannot be resolved safely within the maintenance window, return to the prepared old path and work with Sophos or the partner to determine whether the configuration, platform, or model must change.

Troubleshooting After Go-Live

• Throughput is below target: Check link speed and duplex, the firewall rule path that actually matches, and active IPS, web, and TLS inspection. Then compare the measurement with the corresponding data-sheet metric, not the raw firewall maximum.
• Load average repeatedly exceeds the CPU core count: Narrow down the time and traffic flow using Control Center, logs, and Current activities. A brief peak alone does not prove incorrect sizing; recurring saturation together with packet loss or sluggish applications requires investigation.
• Decryption capacity is exhausted or decrypt sessions approach the documented model limit: Check which rules decrypt traffic and whether the real HTTPS profile differs from the assumption. Save the observations and reassess the model or inspection scope with Sophos or the partner rather than switching off the control without review.
• Only the virtual firewall is slow: Also check CPU and RAM allocation, reservations, host overcommitment, storage latency, and virtual NICs.

Common Sizing Mistakes

• Dimensioning only by the number of users.
• Confusing data sheet values for firewall throughput with threat protection load.
• Activating TLS Inspection later without planning for reserve.
• Planning HA but not checking if one node alone has enough performance.
• Ignoring inter-VLAN traffic.
• Underestimating reporting and logging.
• Operating virtual firewalls on overbooked hosts.
• Not considering the growth of the internet line.
• Planning remote access and site-to-site VPN only by the number of tunnels instead of throughput.

Checklist

• Internet bandwidth and actual peak usage known.
• Users, devices, VLANs, and server zones recorded.
• Planned security modules documented.
• Ports, feature scope, subscriptions, and platform limits checked.
• TLS Inspection, IPS, VPN, WAF, Mail Protection, and reporting evaluated separately.
• Internal traffic through the firewall considered.
• HA design and failover load checked.
• Hardware or virtual appliance consciously decided.
• Growth reserve planned for several years.
• Performance metrics checked after commissioning.
• Acceptance criteria, backup, and backout path documented.

FAQ