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.
FortiGate speed test vs. throughput
A speed test measures the bandwidth of the link on a single interface (for example, your WAN to the internet). Throughput is how much traffic the FortiGate can actually process and forward with your security features running. A 60F can show a 1 Gbps speed test on its WAN and still bottleneck well below that once SSL inspection and IPS are enabled, because throughput, not link speed, is the real ceiling.
Struggling To Choose The Right Fortigate?
Take our quick quiz to get a personalized suggestion for your business.
Start Quiz
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
Log in: Open a browser, enter your FortiGate management IP, and sign in with an admin account.
Open interfaces: Go to Network > Interfaces and select the WAN interface you want to test.
Run the test: Edit the interface (pencil icon) and click Speed Test. The FortiGate picks the nearest server and measures upload and download.
Apply results (optional): Click Apply results to write the measured values into the interface’s estimated bandwidth fields, which SD-WAN rules can then use for path selection.
Confirm FortiGuard reachability: Under System > FortiGuard, verify the SD-WAN network monitor license is valid and the device can reach the test servers, or results will fail or read as zero.
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
endThen 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.
The built-in speed test measures the link on one interface, typically WAN to internet. It does not push traffic through your firewall policies, so it will not reveal an inspection bottleneck. To measure that, run the iPerf3 test through the FortiGate described 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:
| Throughput figure | What is enabled | How close to real life |
|---|---|---|
| Firewall (IPv4) | Stateful firewall only, 1518-byte UDP, no inspection | Best case; you rarely see it in production |
| IPS | Intrusion prevention on an enterprise traffic mix | Closer, if IPS is your only inspection |
| Threat Protection | IPS + application control + malware protection, logging on | The most honest “UTM on” number for most SMBs |
| SSL Inspection | Deep inspection of HTTPS traffic | Often the lowest figure, and most of your traffic is HTTPS |
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.
Place the endpoints on different segments: Run the iPerf3 server on a host in one zone (for example the LAN) and the client in another (for example a DMZ or WAN-side test host), so traffic must traverse a firewall policy.
Start the server: On the server host run iperf3 -s.
Run the client with parallel streams: On the client run iperf3 -c <server_ip> -P 8 -t 30. Multiple streams (-P) fill the pipe more completely than a single flow and better approximate many users at once.
Test twice, security off then on: Run once through a plain policy, then again through a policy with your production IPS, application control, and SSL inspection profiles applied. The gap between the two runs is exactly the cost of your security posture.
Test with the traffic profile you actually run. If 80% of your traffic is HTTPS and you inspect it, benchmark HTTPS through a full SSL inspection policy, not plaintext iPerf3. A clean-traffic number that ignores SSL inspection will flatter the box and mislead your sizing.
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 foripsengine(IPS/flow inspection) orwad(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 (
-Pin 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 topshows the CPU pinned, the firewall is the limit; if CPU is idle and throughput is still low, look upstream at the ISP or cabling.
If your testing or migration plan still leans on SSL VPN, note that Fortinet is removing SSL VPN tunnel mode from FortiOS (7.6 and later, and 8.0) and steering customers to IPsec VPN and ZTNA for application access. Factor IPsec throughput, not SSL VPN, into new sizing. See why FortiGate SSL VPN is going away and how to migrate to IPsec.
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.
2-3x
The threat-protection throughput uplift of the FortiGate G-series (FortiSP5) over the F-series it succeeds (Fortinet product data).
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.
Before you replace hardware, confirm you are on a supported, mature FortiOS branch. 7.4 and 7.6 are the current production branches (7.6.6 is widely recommended). FortiOS 7.2 reaches end-of-support in September 2026, so plan upgrades off 7.2. FortiOS 8.0 exists but is a new feature release and is not yet recommended for production.
The FortiGate speed test checks your link; an iPerf3 test through the firewall with your real security profiles checks the box. Size on threat-protection and SSL-inspection throughput, not the firewall-only headline. If the CPU is pinned under inspected traffic and tuning is exhausted, you have outgrown the model, and the G-series is the current answer.
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-testsyntax and SD-WAN monitor requirement. - Fortinet Document Library, “config system speed-test-setting” (FortiOS 7.6.2 CLI Reference):
latency-thresholdandmultiple-tcp-streamoptions. - 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.
