Conducting an Internet Speed Test on Sophos Firewall via SSH

An internet speed test in the browser does not always reflect the true capability of the internet connection. Browser, client, WLAN, proxy, IPS, web filter, TLS Inspection, VPN, NAT, and firewall rules can influence the result. Therefore, sometimes a test directly on the Sophos Firewall is helpful to distinguish the firewall’s WAN connection from client or rule issues.

This article describes a simple download test via SSH on the Sophos Firewall, the correct interpretation of the result, and the limitations compared to iPerf, Log Viewer, or Packet Capture. It is particularly important to differentiate when there are multiple WAN connections: the test measures firewall’s own download traffic, not necessarily the same path as a client behind the firewall.

Which Performance Test is Suitable?

A download directly on the firewall is just one tool. Depending on the question, another test might be more informative:

This separation prevents misinterpretations. A fast firewall download does not prove that a client path, a VPN route, or a TLS Inspection rule must also be fast.

What a Speed Test on the Firewall Proves

A speed test directly on the firewall answers a specific question: Can the firewall itself download a file from the internet at the expected speed over its current routing path?

This is helpful if you want to know:

• whether the WAN line is generally fast enough
• whether the provider connection delivers approximately the expected download rate
• whether an issue lies more in front of or behind the firewall
• whether client, WLAN, switch, web filter, TLS Inspection, or VPN need to be included in the analysis

However, the test does not automatically prove that clients behind the firewall must achieve the same speed. Client traffic passes through firewall rules, NAT, security policies, and depending on the configuration, through IPS, Web Protection, Application Control, or TLS Inspection. The local download on the firewall bypasses parts of this processing and is therefore suitable as a distinction, not as a complete end-to-end test.

For understanding datasheet values, security features, and real performance, see Understanding Sophos Firewall performance metrics.

Consider Multiple WAN Connections and SD-WAN

For firewalls with multiple WAN links, you should clarify before the test which path the firewall itself uses to access the internet. The download is generated by the Sophos Firewall. It is therefore system-owned traffic and does not necessarily follow the same decision as a client flow processed by a firewall rule, NAT rule, or SD-WAN route.

Typical misconceptions:

In such setups, you should always document the result with the time, active WAN link, and observed gateway. If system-owned traffic, response packets, or SD-WAN decisions are unclear, see Understanding Sophos Firewall SD-WAN Routing, Reply Packet, and System Traffic.

Prerequisites

Before the test, these points should be fulfilled:

• SSH or Advanced Shell access is consciously allowed.
• The firewall has internet access and DNS is functioning.
• There is a maintenance window or at least a non-critical time.
• It is clear which WAN interface the firewall uses for the download.
• Sufficient free space for the test file is available.
• The test file is deleted after the test.

For secure SSH access, see Connect to Sophos Firewall via SSH. SSH should only be allowed from trusted networks and restricted to the necessary minimum after troubleshooting tasks.

⚠️ A download test generates real traffic and can temporarily saturate the line. On production firewalls, such tests should not be performed during critical working hours or parallel to backup, VoIP, or maintenance windows.

Conducting a Speed Test via SSH

Log in to the Sophos Firewall via SSH and open the Advanced Shell. Then load the test file into a temporary directory to prevent it from accidentally remaining in an inappropriate working directory.

cd /tmp
curl -L -o 1GB.bin https://www.avanet.io/1GB.bin

The test server is located in Switzerland and is intended for a rough line measurement. For smaller tests, 100MB.bin can be used instead of 1GB.bin:

cd /tmp
curl -L -o 100MB.bin https://www.avanet.io/100MB.bin

If DNS does not work, the test will fail at the name resolution stage. In that case, the line speed should not be analysed, but DNS, routing, and WAN availability should be checked first.

For firewalls with multiple WAN links, the test should not be viewed in isolation. In parallel, check in WebAdmin which WAN link is active and whether there is currently a failover, an SD-WAN change, or a provider disruption.

Delete the Test File

After the test, the file should be removed:

rm /tmp/1GB.bin

For a test with the smaller file:

rm /tmp/100MB.bin

If the test was aborted, still check if a partially downloaded file is present:

ls -lh /tmp/*GB.bin

Large test files should not remain on the firewall. Especially on small appliances or already filled partitions, unnecessary memory consumption can later lead to difficult-to-trace issues.

Evaluating the Speed Test

During and after the download, curl shows, among other things, the average download rate. In the example, the value is around 107 MB/s.

The unit is important:

• MB/s means megabytes per second.
• Mbit/s or Mbps means megabits per second.
• 1 byte equals 8 bits.

As a rough conversion:

MB/s x 8 = Mbit/s

So 107 MB/s is approximately 856 Mbit/s. Overhead, TCP behaviour, counterpart, routing, and load can influence the value. Therefore, a single measurement should not be used as definitive proof.

Multiple tests at different times of the day are advisable. If the values fluctuate significantly, check the provider, WAN link, SD-WAN routing, interface errors, and load.

For support or internal documentation, do not just note the number. A short measurement dataset helps significantly later:

When comparing multiple measurements, test file, target, time, and WAN path should remain as consistent as possible. Otherwise, you quickly compare time of day, provider path, or counterpart instead of the actual firewall performance.

Comparing with Client Tests

The next step is to compare with a client behind the firewall. This helps to narrow down where performance is lost.

For targeted path tests, iPerf is often better than a public download. With iPerf, you can define where the server and client are, whether TCP or UDP is tested, and what bandwidth is expected.

Typical Misinterpretations

Firewall Speed Test is Fast, Users Still Report Slow Internet

Then the WAN line is not automatically innocent, but the focus shifts. You should check client network, WLAN, switch port, DNS, firewall rule, NAT, IPS, Web Protection, Application Control, and TLS Inspection. Especially TLS Inspection or aggressive security profiles can treat client traffic significantly differently than a download directly on the firewall.

Browser Speed Test is Slow, Firewall Speed Test is Fast

This often indicates a problem behind the firewall or in the client path. However, you should test multiple browsers, a wired client, and a second target before assuming a fixed cause.

Firewall Speed Test is Slow

Then first check WAN status, link speed, duplex, SD-WAN routing, DNS, provider disruption, and load. With multiple WAN connections, it should be clear which gateway the download is running over.

Only Upload is Slow

The curl download described here primarily tests the download direction. For upload or bidirectional tests, iPerf or another defined test setup is better suited.

Troubleshooting After the Test

If the problem remains unclear after the speed test, you should proceed systematically:

1. Check Log Viewer: Which firewall rule does the client traffic hit?
2. Use Policy Test: Check expected source, destination, service, and user.
3. Start Packet Capture: Can you see packets, response packets, and NAT?
4. Check Interface Status: Evaluate link speed, errors, drops, and load.
5. Check Security Features: IPS, web filter, TLS Inspection, Application Control.
6. Conduct a Countercheck with iPerf: Test path, TCP/UDP, and direction specifically.

For rule and packet flow analyses, see Testing firewall rules with Log Viewer, Policy Test, and Packet Capture. For deeper log files, see Sophos Firewall Troubleshooting: Services and Logs.

Checklist

Before the Test

• SSH or Advanced Shell access consciously allowed.
• Test time chosen.
• WAN path known.
• Sufficient storage space available.
• Measurement goal defined: WAN test, client comparison, or VPN distinction.

During the Test

• Download test file to /tmp.
• Note download rate and unit.
• Do not confuse DNS, routing, or reachability errors with speed.
• Do not make large parallel changes to firewall rules or SD-WAN.

After the Test

• Delete test file.
• Convert result to Mbit/s.
• Compare with client or iPerf test.
• Use Log Viewer, Policy Test, and Packet Capture for discrepancies.
• Document result with time, WAN link, and test target.

FAQ