Test Sophos Firewall performance with iPerf

iPerf is a good tool if you want to measure the performance of a specific network path. For a Sophos Firewall, this includes tests between two internal networks, over a site-to-site VPN connection, over Remote Access VPN, or between a client behind the firewall and a server on the Internet.

A iPerf test does not replace a normal application test or a pure WAN speed test directly on the firewall. It answers another question: How much TCP or UDP throughput does this one route achieve between two defined endpoints under the selected test conditions?

Area of application and measurement model

iPerf is useful if you want to measure a specific distance reproducibly. Before executing commands, it should be clear what is being measured and what the test is deliberately not answering.

When iPerf makes sense

iPerf is particularly helpful when a performance statement must be reproducible:

• after a firewall migration or a model change
• before and after changes to firewall rules, IPS, TLS Inspection or traffic shaping
• for slow connections between VLANs or locations
• for VPN performance issues via IPsec, SSL VPN or Sophos Connect
• for UDP topics such as voice, conference streams or certain industry applications
• to differentiate between firewall, WAN, WLAN, client, server and application

For a pure Internet test from a firewall perspective, the article Internet Speedtest via the Sophos Firewall CLI is more suitable. Sophos Firewall Check performance metrics is also suitable for classifying the firewall utilization.

What iPerf measures

iPerf establishes a test connection between a server and a client. The measured value therefore applies to exactly this path, this direction, this port, this protocol and these endpoints.

The correct interpretation is important:

• TCP shows achievable throughput with congestion control, retransmits and window sizes.
• UDP shows packet loss and jitter, but requires a defined target bandwidth.
• A single test run is not a reliable statement of capacity.
• WiFi, client CPU, virtual machines, USB network adapters and power saving functions may limit the measurement.
• Security functions on the Sophos Firewall only affect the result if the test connection runs through a suitable rule and policy.

Plan test setup

Before the first command, it should be clear which route is being checked:

1. Where is the iPerf server located?
2. Where is the iPerf client?
3. In which direction should the test be carried out?
4. Which firewall rule applies to this connection?
5. Is there NAT, VPN, Traffic Shaping, IPS or TLS Inspection on the path?
6. Does the test run via cable or WLAN?
7. Should you check TCP throughput, UDP loss, or both?

For tests behind a Sophos Firewall, a clean structure is usually more important than the individual maximum value. A client on WiFi, an overloaded hypervisor, or a slow Public-iPerf server can mimic a false firewall problem.

Install iPerf

iPerf is available for Windows, macOS, Linux, Android and iOS. A well-known download source is iPerf.fr.

Run iPerf

If the test setup is clear, you first start the server and then carry out targeted client tests. TCP, UDP, opposite direction and parallel streams answer different questions and should therefore not be mixed.

Start iPerf server

On the target system, iPerf is started in server mode:

iperf3 -s

By default, iPerf3 listens on TCP port 5201. If a different port is to be used, it is specified the same on the server and client:

iperf3 -s -p 5200

Caution: On Windows, macOS or Linux, the local host firewall may block the iPerf port. If the client cannot reach the server, the local firewall on the iPerf server should be checked first.

Start TCP test

On the client, the server is addressed with its IP address:

iperf3 -c 10.10.10.50

For more stable results, a longer test makes sense:

iperf3 -c 10.10.10.50 -t 30

Check direction specifically

Performance problems often only occur in one direction. iPerf3 can reverse the data flow without swapping server and client:

iperf3 -c 10.10.10.50 -t 30 -R

This is particularly useful for VPN routes, asymmetric routing, upload problems or WAN lines with different downstream and upstream bandwidth.

Perform UDP test

UDP must always be tested with a reasonable target bandwidth. Without a suitable target bandwidth, the test does not measure the actual expected load.

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

For a 1 Gbit route, a higher target value may make sense:

iperf3 -c 10.10.10.50 -u -b 1G -t 30

These values are particularly important for UDP:

• Lost/Total Datagrams: Packet loss
• Jitter: Variation in packet transit time
• Bitrate: effective bandwidth sent or received

A UDP test with too high a target bandwidth intentionally creates overload. This can be useful for boundary testing, but should not be misconstrued as a normal line test.

Use multiple streams

A single TCP stream may be limited by latency, TCP window size, or client performance. You can use multiple parallel streams for capacity testing:

iperf3 -c 10.10.10.50 -t 30 -P 4

The result shows more of the total usable capacity of the route. For a single application, a single-stream test is often more meaningful.

Use public-iPerf server

A public iPerf server can be used for rough Internet comparisons. However, public servers cannot be controlled: utilization, limitations, accessibility and distance can fluctuate greatly. A well-maintained overview can be found, for example, in the list of iPerf Public Servers on GitHub.

When it comes to the question of whether the local firewall, the VPN or a specific policy is slowing it down, a separate iPerf server on the other side is usually much more reliable.

Comparative measurement and evaluation

A single iPerf value is rare enough. The test only becomes meaningful when the direction, parameters, firewall rule and measurement time are documented and later repeated under the same conditions.

Plan baseline and comparison measurements

iPerf is particularly valuable when comparable measurements are made before and after a change. A single test after a complaint only shows the current condition. It does not yet say whether the route was already slow beforehand or whether a new firewall rule, an IPS profile, TLS Inspection, traffic shaping, a VPN parameter or a provider problem triggered the change.

For reliable comparisons, these test conditions should be recorded:

• Date and time: Backups, updates, reports or provider load can distort results.
• Source and Destination: Other clients, servers or VLANs result in other paths.
• Direction: Download, Upload and -R can show very different values.
• Protocol and parameters: TCP, UDP, streams, duration and target bandwidth must remain comparable.
• Applicable firewall rule: Security profiles, logging, NAT and traffic shaping depend on the policy.
• VPN or WAN path: SD-WAN, Route Precedence, Gateway status and tunnel type affect the route.
• Environment: Cable, WLAN, hypervisor, CPU load and parallel traffic must be classified.

If changes are planned, a simple process makes sense:

1. Perform a reference test before making changes.
2. Document firewall rule, policy, VPN path and measurement parameters.
3. Make exactly one change.
4. Run the same test again.
5. If there are deviations, check Log Viewer, Packet Capture, interface error and system load.
6. Only then test the next change.

Especially with VPN and location tests, this procedure prevents multiple causes from being mixed up. If MTU, IPS, SD-WAN, firewall rules and client profiles are adjusted at the same time, it is difficult to assign a better iPerf value later.

Evaluate results

When evaluating, attention should not only be paid to the highest Mbit/s number.

Typical observations:

• Low TCP throughput with many retransmits: This points to packet loss, a duplex/link problem, WAN quality or an MTU/MSS issue.
• Good download, bad upload: Asymmetrical line, routing, provider shaping or VPN direction are possible.
• UDP packet loss even under moderate load: Common causes are overload, poor WAN quality, incorrect shaping or WLAN.
• Highly fluctuating values: Check parallel load, WLAN, CPU limit or virtual environment.
• Only public servers slow: Then the external server or peering is affected, not automatically the local firewall.

During the test, RAM, interface load, IPS load and affected rules should be checked on the Sophos Firewall CPU. The values ​​can be better classified using the performance metrics and live logs.

Errors and checklist

Many false conclusions arise because the test path is not clearly defined or public servers, WLAN, local host firewalls and VPN direction are not taken into account.

Common errors

• The iPerf port is blocked on the server by the local host firewall.
• The wrong direction is tested.
• A WLAN client is used for a firewall performance statement.
• UDP is tested without a suitable target bandwidth or with an unrealistically high target bandwidth.
• A public iPerf server is used as the sole proof of one’s Internet performance.
• TCP single stream and multiple parallel TCP streams are mixed.
• The applicable Sophos Firewall rule is not checked.
• VPN tests are evaluated without looking at MTU, MSS, CPU and the remote side.

Short checklist

1. Define test route and direction.
2. Start iPerf server on an appropriate endpoint.
3. Check local host firewall on the iPerf server.
4. Identify appropriate Sophos Firewall rule.
5. Run TCP test for at least 30 seconds.
6. If necessary, test in the opposite direction with -R.
7. Test UDP only with realistic target bandwidth.
8. Check firewall metrics, logs and Packet Capture in parallel.
9. Repeat the test after changes and document the results.
10. Use the same parameters, direction and path when making comparison measurements.

FAQ