Test Sophos Firewall performance correctly with iPerf3

iPerf3 measures TCP or UDP throughput between two defined endpoints. It can help determine whether a path between VLANs, through a Sophos Firewall, or across a VPN tunnel is slower than expected. However, a single high or low result does not prove that the firewall is the problem.

A reliable test first needs a baseline that excludes the suspected path. The same measurement is then repeated through the firewall. Direction, duration, protocol, streams, firewall rule, and security profiles must remain documented; otherwise, the results being compared are not technically comparable.

⚠️ Schedule load tests: iPerf3 can fully saturate a connection. Run tests in production during a maintenance window or deliberately below the available bandwidth. Never leave the server unnecessarily accessible from the internet.

What iPerf3 measures

iPerf3 consists of a server and a client. By default, the client sends the test data to the server. -R reverses the direction. The measurement always applies only to these exact endpoints, this path, and these parameters.

The three most important test types answer different questions:

iPerf3 does not measure application performance. SMB, RDP, VoIP, or a web application can be slow despite good iPerf results. Conversely, a single TCP stream on a high-latency path can remain below the available connection capacity even when the firewall and WAN are working correctly.

For an internet test directly from the appliance’s perspective, Sophos Firewall internet speed test via SSH is the more appropriate article. iPerf3 is more useful when two controlled endpoints and the path between them need to be investigated.

Plan the test path and baseline

Before running the first command, define the client, server, and path to be tested. A sensible series of measurements has three stages:

1. Endpoint baseline: Test the client and server on the same local network or through a known fast switch. If this result is already poor, investigate the client, server, NIC, host firewall, hypervisor, or Wi-Fi first.
2. Firewall path: Test the same endpoints through the intended VLANs or zones and the actual Sophos Firewall rule.
3. WAN or VPN path: Only then repeat the test through the provider, SD-WAN, Site-to-Site VPN, or Remote Access.

Wired endpoints are better than Wi-Fi clients when assessing firewall performance. Power-saving functions, CPU utilisation, virtual NICs, and concurrent traffic should be known on both systems. The server and client should use the same iPerf3 major version where possible; iPerf2 and iPerf3 are not compatible.

Prepare the firewall rule

iPerf3 uses port 5201 by default. A TCP test requires TCP 5201. For a UDP test, the test data uses UDP 5201, but the control connection remains TCP. A Sophos service group for UDP tests must therefore include both TCP and UDP 5201.

The temporary rule under Rules and policies > Firewall rules should allow only the specific source IP address, destination IP address, and iPerf service. Enable Log firewall traffic and note the Rule ID. Do not create a broad Any rule or expose the service to the internet merely to start the test more quickly.

After saving, check in Log viewer that this exact rule is matching. If rule assignment is unclear, see Test Sophos Firewall rules systematically.

Install iPerf3 and secure the server

The official project documentation and source packages are available from ESnet iPerf3. ESnet lists Ubuntu Linux, FreeBSD, and macOS as officially supported platforms. In practice, Windows binaries often come from third parties; iPerf.fr provides a well-known overview.

Start the server on the destination system as follows:

iperf3 -s

It is safer to bind the process to the test IP address and have it exit automatically after one client connection:

iperf3 -s -B 10.10.10.50 -1

-B binds iPerf3 to the specified address. -1 accepts no more than one client connection and then stops the server. The command must be started again for each subsequent single test. If a different port is used, it must be specified identically on both sides:

iperf3 -s -B 10.10.10.50 -p 5200 -1

The local host firewall on the server can also block the port. Restrict this allowance to the test source and the required duration as well.

Test TCP in both directions

The first test uses a single TCP stream and runs for 30 seconds:

iperf3 -c 10.10.10.50 -t 30

By default, the client sends data to the server. Then test the opposite direction with the same endpoints:

iperf3 -c 10.10.10.50 -t 30 -R

If the two directions differ significantly, asymmetric WAN bandwidth, routing, SD-WAN, interface errors, VPN parameters, or an endpoint are more likely than a general throughput limit.

Only after the single-stream test should you compare it with four parallel streams if required:

iperf3 -c 10.10.10.50 -t 30 -P 4

If -P 4 is significantly faster, a single TCP flow may be limited by latency, the TCP window, or endpoint performance. The result is not automatically the speed that a single application will achieve. --bidir loads both directions simultaneously and is better suited to a deliberate stress test than to a clean comparison of directions.

Test UDP in a controlled way

A UDP test always requires a realistic target bandwidth. Without -b, iPerf3 uses only 1 Mbit/s by default; this cannot be used to assess a 100 Mbit/s or Gigabit path.

Example with 100 Mbit/s:

iperf3 -c 10.10.10.50 -u -b 100M -t 30

Do not begin immediately with the theoretical line rate. Start by testing, for example, 60 to 80 per cent of the expected usable bandwidth, then increase the target gradually. For a VPN, protocol and encryption overhead must also be taken into account.

Three values are critical for UDP:

• Bitrate: The data rate actually achieved.
• Jitter: Variation in packet transit time.
• Lost/Total Datagrams: Packet loss detected by the receiver.

A deliberately excessive target bandwidth creates packet loss by itself. This is a limit test, not proof of a faulty firewall. Test the opposite direction separately with -R for UDP as well.

Monitor Sophos Firewall during the test

An iPerf result only becomes meaningful when it is correlated with the firewall over time. The following should be visible during the 30-second test:

• In Log viewer, confirm that the Firewall Rule ID, source, destination, service, and allowed connection are correct.
• In Control center, use CPU, Memory, Bandwidth, and Sessions to determine whether the appliance reaches a limit during the test.
• Under Diagnostics > System graphs, check Bits, Drops, Errors, and Collisions in the Interface graphs for the interfaces involved.
• Under Diagnostics > Packet capture, a narrow filter for the client, server, and port 5201 can show whether packets are being dropped or processed by unexpected modules.

Packet Capture shows, among other things, the firewall rule number and the Web, Application, and IPS policy numbers. Keep the capture brief, filter it narrowly, and stop it again after the test. Packet Capture on Sophos Firewall explains the analysis in more detail.

Isolate security profiles

If the endpoint baseline is good and only the firewall path is slow, do not disable everything at once. First document the rule that is actually matching and its security profiles. Then change exactly one variable during a maintenance window and repeat the same test.

A diagnostic rule without additional inspection must be restricted narrowly to the test source, test destination, and iPerf service. Disable or remove it immediately after the comparison measurement. This makes it possible to determine whether IPS, Application Control, Traffic Shaping, or another policy is involved without leaving the remaining traffic unprotected.

Interpret the results correctly

For TCP, the summaries for sender and receiver, as well as retransmits, are important. Many retransmits indicate loss or a disrupted path, not necessarily insufficient firewall CPU. A good local baseline and a poor result through the firewall narrow the investigation, but they do not yet identify the cause.

Typical patterns:

• Slow even on the same LAN: Check endpoints, NIC drivers, the virtual platform, host firewall, or Wi-Fi.
• Slow only through the firewall: Investigate the rule, security profiles, Traffic Shaping, interface errors, and system load.
• Slow only through VPN: Check WAN quality, latency, the encryption profile, tunnel route, and MTU and MSS.
• Slow in one direction only: Compare the reverse test, interface counters, asymmetric routing, and the provider upstream.
• Single stream slow, multiple streams fast: Assess latency, the TCP window, and endpoint performance before assuming a firewall limit.
• Only one public server is slow: Utilisation, distance, or peering at the remote server may limit the result.

Public iPerf servers are suitable only for a rough internet comparison. For firewall, VPN, or site diagnostics, a controlled server of your own at the remote end provides more reliable evidence.

Document the measurement and remove temporary changes

To keep a before-and-after comparison traceable, record at least the date, client, server, direction, command, Rule ID, security profiles, VPN or WAN path, and the sender/receiver result. During troubleshooting, change only one variable between two runs.

After completing the test:

1. Stop the iPerf3 server.
2. Remove the allowance from the host firewall.
3. Disable or delete the temporary Sophos Firewall rule and test service if they are no longer required.
4. Restore changed security profiles to their intended state.
5. Check Log viewer and the interface counters once more for drops or errors.

FAQ