How to Perform a Speed Test with Fortinet

To run a speed test on a FortiGate, use Network > Interfaces, edit the WAN interface, and click Speed Test in the GUI, or run execute speed-test <interface> from the CLI. That built-in test measures the raw internet link speed at the interface. It does not tell you how much traffic the firewall can actually inspect and forward, which is the number that matters when performance feels slow. This guide covers both: how to run the tests correctly, and how to read the results so you know whether the problem is your ISP, your configuration, or a FortiGate that your business has simply outgrown.

How do you run a speed test on a FortiGate?

You can test link speed two ways: the GUI speed test on an interface, or the execute speed-test command in the CLI. Both use Fortinet’s speed test servers and require the SD-WAN monitor capability to be licensed and reachable. The GUI is fastest for a one-off check; the CLI gives you repeatable, scriptable results and finer control over TCP streams and latency thresholds.

GUI method

CLI method

Optionally tune the test first. latency-threshold caps the acceptable RTT in milliseconds, and multiple-tcp-stream sets how many parallel TCP streams the test opens (more streams usually fill a fast link more completely):

config system speed-test-setting
    set latency-threshold 60
    set multiple-tcp-stream 4
end

Then run the test against an interface. You can let the FortiGate pick a server or name one explicitly, and choose Auto, TCP, or UDP:

execute speed-test <interface>

# Or, equivalently, via netlink with an explicit server and protocol:
diagnose netlink interface speed-test <interface> <server> {Auto | TCP | UDP}

The results print transfer rate and latency in the terminal. The speed test server list expires after 24 hours, and the tool is built on an iPerf3-compatible engine (iPerf 3.6 with SSL support), which matters for the more accurate through-the-firewall test below.

Why is my FortiGate throughput lower than the datasheet?

Because the datasheet’s headline number is measured under ideal lab conditions that your network never sees. Fortinet’s top “firewall throughput” figure is tested with large 1518-byte UDP packets and no security inspection enabled. The moment you turn on IPS, application control, antivirus, or SSL inspection, and your traffic becomes a realistic mix of small and large packets, the usable number drops, often by a large margin. That is not a fault; it is the difference between marketing-max and real-world throughput.

Fortinet publishes several throughput numbers precisely because they differ so much. Read the right one for how you actually run the box:

For sizing, the Threat Protection and SSL Inspection rows are the ones that matter. SSL inspection is the heaviest workload on the box, and since the vast majority of business traffic is HTTPS, the SSL inspection number is frequently the true ceiling for a modern deployment. If you sized your firewall against the firewall-throughput figure, you almost certainly over-estimated its real capacity. See our breakdown of the key differences between FortiGate models for how these numbers scale across the lineup.

How do you test throughput through the firewall with iPerf3?

Put an iPerf3 server on one side of the FortiGate and an iPerf3 client on the other, then push traffic across a real firewall policy so the FortiGate has to inspect it. This is the only test that measures what your users experience, because it forces traffic through your actual rules, IPS profiles, and SSL inspection rather than testing a single interface in isolation.

What CLI diagnostics show FortiGate performance?

Use the CLI to see whether the FortiGate itself is the bottleneck. Three commands cover most cases: get system performance status for a rolling summary of CPU, memory, and session rates; diagnose sys top to see which processes are burning CPU; and the session table to confirm whether traffic is being hardware-accelerated. If CPU is pinned while throughput is low, you are CPU-bound, not link-bound.

• get system performance status: CPU and memory usage, session count, and average network throughput over the last minutes.
• diagnose sys top: live process list; watch for ipsengine (IPS/flow inspection) or wad (proxy/SSL inspection) dominating the CPU.
• diagnose sys session stat: total and per-second session counts, useful when a session flood, not bandwidth, is the real problem.

Why hardware acceleration changes the picture

FortiGate models with Fortinet’s network processors (the NP7 on current mid-range and high-end units, or the NP6 family on older ones) can offload much of the packet forwarding from the CPU. Offloaded sessions run fast and barely touch the main processor. The catch: proxy-based inspection and some flow features cannot be fully offloaded and must be handled by the CPU. That is why a box can forward tens of gigabits of plain traffic yet fall over under heavy SSL inspection. Check whether a given session is offloaded in the session table (the NPU/offload state is listed per session) before you blame the hardware; often the fix is tuning inspection, not buying a bigger unit.

What mistakes produce misleading speed test results?

Most “my FortiGate is slow” tickets come from test setups that measure the wrong thing. The single interface speed test is fine for checking the ISP link, but it tells you nothing about inspection capacity. Watch for these:

• Testing only the WAN interface and assuming that number is your usable throughput. It is the link speed, not the firewall’s inspection ceiling.
• Benchmarking with security off, then running production with SSL inspection and IPS on. You measured a different firewall than the one you deployed.
• Using a single TCP stream. One flow rarely saturates a fast link; use parallel streams (-P in iPerf3) to approximate real load.
• Underpowered test endpoints. A laptop with a slow disk or NIC, or a busy VM, caps the result below the firewall’s real capacity.
• Ignoring where the bottleneck is. If diagnose sys top shows the CPU pinned, the firewall is the limit; if CPU is idle and throughput is still low, look upstream at the ISP or cabling.

When does low throughput mean you have outgrown your FortiGate?

You have outgrown the box when the CPU is consistently high under your real, inspected traffic and tuning no longer helps. If diagnose sys top shows ipsengine or wad saturating the CPU during normal business hours, and your through-the-firewall iPerf3 test with SSL inspection on lands well below your internet plan, the firewall (not the link) is the ceiling. That is a sizing problem, not a configuration one.

If you are replacing an aging unit, price the current G-series (30G, 50G, 70G, 90G) built on Fortinet’s FortiSP5 security processor. It succeeds the F-series (40F, 60F, 80F) and delivers roughly 2 to 3 times the threat-protection throughput, which is exactly the number that limits an inspected deployment. The F-series is still sold and supported with no end-of-life announced, but any new multi-year purchase should be sized on G-series numbers. A rough successor map: 40F maps to 30G or 50G, 60F to 70G, and 80F to 90G. For a full sizing walkthrough, read our guide on the 5 critical factors when selecting your next FortiGate.

Not sure whether your slow-down is the ISP, your inspection settings, or an undersized firewall? Our team runs this analysis every week. Explore our managed firewall services and Fortinet solutions, and we will size and tune the right FortiGate for your traffic.

Sources

• Fortinet Document Library, “CLI speed test” (FortiOS 7.6.4 Administration Guide): execute speed-test, diagnose netlink interface speed-test syntax and SD-WAN monitor requirement.
• Fortinet Document Library, “config system speed-test-setting” (FortiOS 7.6.2 CLI Reference): latency-threshold and multiple-tcp-stream options.
• Fortinet Document Library, “Network processors (NP7, NP6, and family)” (FortiOS 7.6.6 Hardware Acceleration): what NP7/NP6 offload and what stays on the CPU.
• Fortinet, “Next-Generation Firewall Ordering Guide”: firewall, threat protection, and SSL inspection throughput figures and their test conditions.