Conducting an Internet Speed Test on Sophos Firewall via SSH

A download directly from the Advanced Shell answers a clearly scoped question: What download rate does Sophos Firewall itself achieve over its current WAN path? This helps distinguish a slow internet connection from problems in the client network, Wi-Fi, VPN, or a security policy.

The test is not a complete end-to-end test. Traffic generated by the firewall does not follow the same path as a client behind it. For a controlled measurement between two endpoints, iPerf behind Sophos Firewall is more suitable; the article on Sophos Firewall performance metrics explains data sheet values and the impact of enabled security features.

Before the speed test

The test requires SSH access, working DNS, and a non-critical time window. A 100 MB file is available for a quick check; on fast connections, the 1 GB file usually provides a more stable average. Both downloads can temporarily saturate the connection and should not be started during backups, VoIP peaks, failover tests, or other maintenance work.

SSH is allowed under Administration > Device access through the Local service ACL or more specifically through a Local service ACL exception rule. Access should only be permitted from a trusted administration network and restricted to the necessary minimum after the work is complete. The login procedure is described under Connect to Sophos Firewall via SSH. Sophos Firewall terminates inactive SSH sessions after 15 minutes.

⚠️ Do not start if the active WAN path or operational impact is unclear. If CPU load becomes unexpectedly high, disruptions occur, or the wrong gateway is used, cancel the download with Ctrl+C. The /dev/null output path used below does not store a test file on the firewall.

Check the WAN path with multiple connections

The download is system-generated traffic. An SD-WAN route for clients therefore does not automatically determine its path. In 4 Device Console, this read-only command shows whether matching SD-WAN routes can also apply to system-generated traffic:

show routing sd-wan-policy-route system-generate-traffic

If the option is enabled, a matching SD-WAN route can influence the download path. If it is disabled, the firewall uses its normal routing and WAN decisions. The command does not prove which gateway the individual download actually uses. In addition, check the active gateways under Network > WAN link manager and the status and matching routes under Routing > SD-WAN routes.

A ping with interface or sourceip is also only an indication for that ICMP test; the subsequent HTTPS download can still be routed differently. SD-WAN routing, reply packets, and system traffic explains these relationships. No routing option should be changed solely for the speed test.

Run the internet speed test via SSH

1. Check the shell and download tool

After logging in via SSH as admin, open 5 Device Management > 3 Advanced Shell from the main CLI menu. Sophos documents access to this shell, but not curl as a guaranteed SFOS interface. First check, without downloading anything, whether the installed firmware provides the tool:

curl --version

If the output shows a version and supported protocols, continue. If the shell reports curl: not found or an option error, do not try to fix this by installing packages or changing the firewall filesystem. Use a client test or the linked iPerf procedure instead, and involve Sophos Support if required.

The actual curl request checks DNS and HTTPS. With --fail, an HTTP error produces a non-zero exit status; the progress meter alone is then not a valid measurement.

2. Measure the download without storing a test file

Advanced Shell is a Linux shell with deep system access. The following command downloads the data but discards it through /dev/null. This avoids a large file write influencing the result and removes the need for storage cleanup.

For a quick test, download the 100 MB file:

curl --location --fail --output /dev/null \
  --write-out '\nHTTP %{http_code} | %{size_download} bytes | %{speed_download} bytes/s\n' \
  https://www.avanet.io/100MB.bin

On fast connections, replace only the URL in the same command with https://www.avanet.io/1GB.bin. --location follows redirects, --fail treats HTTP errors as failures, and --output /dev/null prevents a local file. At the time of publication, the endpoints return 104857600 bytes for 100 MB and 1048576000 bytes for 1 GB.

The file is delivered through Avanet and Cloudflare. The test destination, cache state, peering, routing, and CPU load can affect the result. The value is therefore a practical comparative measurement, not a guaranteed provider or firewall performance figure.

3. Check the status and transferred size

Only evaluate a run that finishes without a curl error, reports HTTP 200, and shows a size_download matching the value stated above. A smaller value means the transfer was interrupted; HTTP 000 typically indicates a DNS, connection, or TLS problem. Other HTTP codes mean the test endpoint is not usable at that time. No test file is created in any of these cases. For cleanup, leave Advanced Shell with exit and remove any SSH ACL exception created solely for this test.

Interpret the result correctly

speed_download reports the average download rate in bytes per second. Multiply it by eight and divide by one million to convert it to Mbit/s. The normal progress meter also shows Average Speed; the existing screenshot shows 107M.

The M in this progress display is based on 1024 and represents MiB/s. Internet connections, by contrast, are specified in decimal Mbit/s. For the example:

107 x 1048576 x 8 / 1000000 = 897.6 Mbit/s

107M therefore corresponds to approximately 898 Mbit/s, not 856 Mbit/s. In practice, overhead, TCP behaviour, the remote endpoint, routing, and current utilisation usually prevent an exact match with the subscribed rate.

A single run is not a reliable diagnosis. Multiple measurements should use the same destination, the same WAN path, and comparable conditions whenever possible. The following measurement record is useful for support or internal documentation:

• Time: for example 2026-06-21 10:15
• Firewall and firmware: for example XGS 2100, SFOS 22.0 MR1
• Test file: 100MB.bin or 1GB.bin
• Measured rate: for example 107M, approximately 898 Mbit/s
• Active WAN link: for example WAN1 Fiber
• Notable conditions: parallel backup, failover, high CPU, or active Packet Capture

What the result means

The firewall download helps narrow down the cause; it is not conclusive proof. Combining it with a client test shows where to investigate next:

• Firewall fast, client slow: Check the client, Wi-Fi, switch port, DNS, firewall rule, NAT, IPS, Web Protection, Application Control, and TLS Inspection. Log Viewer, Policy Test, and Packet Capture and, if required, a targeted Packet Capture can help.
• Firewall and client slow: Compare WAN status, link speed, duplex, interface errors and drops, active gateway, provider outage, CPU load, and a second test destination.
• Only individual applications are slow: Compare DNS, Web Protection, Application Control, proxy, TLS Inspection, and the remote endpoint.
• Only VPN is slow: Check the VPN protocol, routing, and MTU and MSS.
• Only upload is slow: This curl procedure measures download only. A controlled iPerf test is more suitable for upload or both directions.
• Values fluctuate over a longer period: Repeat comparable measurements and, if necessary, monitor interface traffic with sFlow Monitoring.

If the cause remains unclear, first check the affected client flow and the rule that actually matched. For deeper analysis, Sophos Firewall troubleshooting: services and logs shows which log file belongs to each service.

FAQ