Maxim Kazachek To test bandwidth on a FortiGate, use the built-in diagnose traffictest command, which runs an embedded iperf3 client against an iperf3 server, either a public one across your WAN or a Linux/Windows host on your LAN. You set the client interface, the port, and the target server, then run the test to measure real throughput in each direction. For a live view of traffic already crossing an interface, use diagnose netlink interface monitor and the interface byte counters instead. This guide walks through both approaches on current FortiOS (7.4 and 7.6) and shows how to read the results.
diagnose traffictest
diagnose traffictest is a FortiOS CLI command that gives the FortiGate a built-in iperf3 client (and a limited embedded server) so you can measure TCP or UDP throughput from the firewall itself, without deploying a separate testing host. It is the supported way to benchmark a link, a WAN circuit, or an IPsec tunnel directly from the device.
What is the diagnose traffictest command on a FortiGate?
It is FortiOS’s built-in bandwidth tester. The FortiGate ships with an iperf3 client and a limited embedded iperf3 server, and diagnose traffictest drives them from the CLI. You point the client at an iperf3 server, choose the interface the traffic leaves through, and the FortiGate reports transfer size and throughput per second. The command is available on all current FortiOS branches, including 7.4 and 7.6.
The embedded server has real limits: it is not a full iperf3 server, and the FortiGate cannot act as the server endpoint for another FortiGate’s throughput test. In practice you use the FortiGate as the iperf3 client and provide a real iperf3 server as the other end, either a public server on the internet or a machine running iperf3 on your own network.
If you are still running FortiOS 7.2.x, plan your upgrade now: the 7.2 branch reaches end of support in September 2026. The mature production branches are 7.4 and 7.6 (7.6.6 is widely recommended). FortiOS 8.0 exists but is not yet recommended for production, so do not move business firewalls to it purely to run a bandwidth test.
How do you test bandwidth between two FortiGate interfaces?
You can run a port-to-port test using the embedded server, but understand what it actually measures. Set one interface as the server, another as the client, and run the test. This validates the data path and basic interface function on the device; it is a loopback-style connectivity check, useful across two interfaces or two VDOMs. It does not push real production traffic between the ports, so treat the number as an interface sanity check, not a true measure of what a client behind the firewall will get.
Set the server interface: tell the FortiGate which port hosts the embedded iperf3 server.
Set the client interface: choose the port that generates the test traffic.
Run the test: start iperf3 and read the per-second throughput.
diagnose traffictest server-intf port2 # define the server interface
diagnose traffictest client-intf port1 # define the client interface
diagnose traffictest run # run the iperf3 testThe output looks like the sample below. The final two lines (sender and receiver) are the summary you care about:
FortiGate # diagnose traffictest run
Connecting to host 192.168.0.1, port 5201
[ 8] local 192.168.0.2 port 20692 connected to 192.168.0.1 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 8] 0.00-1.00 sec 347 MBytes 2.90 Gbits/sec 0 352 KBytes
[ 8] 1.00-2.00 sec 356 MBytes 2.99 Gbits/sec 0 352 KBytes
[ 8] 2.00-3.00 sec 360 MBytes 3.01 Gbits/sec 0 352 KBytes
... (output trimmed) ...
[ ID] Interval Transfer Bandwidth Retr
[ 8] 0.00-10.00 sec 3.48 GBytes 2.99 Gbits/sec 0 sender
[ 8] 0.00-10.00 sec 3.48 GBytes 2.99 Gbits/sec receiverHow do you run an iperf3 bandwidth test from a FortiGate to a server?
This is the test that measures real WAN or internet throughput. Set the client interface (usually your WAN port), set the iperf3 port the server is listening on, then run against the server’s IP. The FortiGate connects out as an iperf3 client and reports throughput. You need the server’s IP address and port; you can use a machine running iperf3 on your LAN, or a public iperf3 server (a maintained list is at iperf.fr).
Set the client interface: for a WAN test this is the interface that reaches the internet (for example wan1).
Set the iperf3 port: match the port the server is listening on (5201 is the iperf3 default).
Run against the server IP: use run -c <server-ip>. Add -R to reverse direction and measure download instead of upload.
diagnose traffictest client-intf wan1 # define the client (WAN) interface
diagnose traffictest port 5201 # iperf3 port on the remote server
diagnose traffictest run -c 216.218.207.42 # run against a public iperf3 server (iperf.he.net)By default the FortiGate sends and the server receives, which measures upload. To measure download, add -R for reverse mode so the server sends and the FortiGate receives:
diagnose traffictest run -c 216.218.207.42 -R # reverse mode: server sends, FortiGate receivesAlways run the test both ways. A circuit can look healthy on upload and poor on download (or the reverse), and asymmetric results often point to the exact direction where a duplex mismatch, congested uplink, or ISP shaping is hurting you. Run diagnose traffictest run -h to see every option, including protocol, parallel streams, and duration.
Default (upload) output, FortiGate sending to the server:
FortiGate # diagnose traffictest run -c 216.218.207.42
Connecting to host 216.218.207.42, port 5201
[ 8] local 203.0.113.10 port 5744 connected to 216.218.207.42 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 8] 0.00-1.01 sec 820 KBytes 6.65 Mbits/sec 0 141 KBytes
[ 8] 1.01-2.00 sec 3.08 MBytes 26.1 Mbits/sec 0 389 KBytes
... (ramping up as the TCP window grows) ...
[ 8] 9.00-10.00 sec 15.0 MBytes 126 Mbits/sec 0 1.33 MBytes
[ ID] Interval Transfer Bandwidth Retr
[ 8] 0.00-10.00 sec 105 MBytes 88.0 Mbits/sec 0 sender
[ 8] 0.00-10.00 sec 105 MBytes 88.0 Mbits/sec receiverReverse (download) output, server sending to the FortiGate:
FortiGate # diagnose traffictest run -c 216.218.207.42 -R
Connecting to host 216.218.207.42, port 5201
Reverse mode, remote host 216.218.207.42 is sending
[ 8] local 203.0.113.10 port 1787 connected to 216.218.207.42 port 5201
[ ID] Interval Transfer Bandwidth
[ 8] 0.00-1.00 sec 6.98 MBytes 58.5 Mbits/sec
[ 8] 1.00-2.00 sec 45.7 MBytes 383 Mbits/sec
... (output trimmed) ...
[ 8] 9.00-10.00 sec 48.4 MBytes 406 Mbits/sec
[ ID] Interval Transfer Bandwidth Retr
[ 8] 0.00-10.00 sec 451 MBytes 379 Mbits/sec 0 sender
[ 8] 0.00-10.00 sec 443 MBytes 371 Mbits/sec receiverHow do you check live interface bandwidth on a FortiGate without iperf?
Use the interface diagnostics, which read real traffic instead of generating a synthetic test. diagnose netlink interface monitor <port> gives a continuous, live view of packets and bytes per second on an interface; press Ctrl-C to stop. diagnose netlink interface list <port> dumps the cumulative RX/TX byte and packet counters plus error and drop counts, which is where you catch a failing link. These are the right tools when you want to see what production traffic is actually doing, not benchmark a link’s ceiling.
| Command | What it shows | Best for |
|---|---|---|
diagnose traffictest run | Synthetic iperf3 throughput (Mbps/Gbps) in one direction | Benchmarking a WAN circuit or tunnel’s real ceiling |
diagnose netlink interface monitor <port> | Live packets/sec and bytes/sec on an interface | Watching real-time load on a port right now |
diagnose netlink interface list <port> | Cumulative RX/TX bytes, packets, errors, drops | Spotting errors, discards, or a saturated link |
diagnose system link-monitor interface <name> | Bandwidth, session count, latency, jitter, packet loss | Link-health and SD-WAN quality metrics |
For a visual, per-IP breakdown of who is consuming bandwidth, FortiView in the GUI shows live bandwidth by source, destination, and application without touching the CLI.
How do you interpret FortiGate bandwidth test results?
Read the summary line, then compare it to what the link should deliver. The last two lines of a traffictest run (sender and receiver) give the averaged throughput over the test window; that is your headline number. Compare it against the provisioned circuit speed or the interface’s rated capacity. A steadily climbing rate in the first few seconds is normal TCP window ramp-up, so judge the run by the 10-second average, not the opening interval.
- Well below the provisioned speed: suspect a duplex mismatch, a congested uplink, ISP shaping, or an undersized firewall model for the inspection you have enabled.
- Non-zero Retr (retransmits): packet loss or congestion on the path; a few retransmits are normal, a steadily climbing count is not.
- Asymmetric upload vs download: expected on many broadband circuits, but a large unexplained gap points to a problem in one direction.
- Rising errors or drops in
interface list: a cabling, SFP, or negotiation fault, not a bandwidth ceiling.
Throughput on a firewall is not a fixed number; it drops as you enable deeper inspection (IPS, SSL inspection, antivirus). If your traffictest results are well under the link speed with security services on, the bottleneck is often the firewall model, not the circuit. Test with and without inspection to see the real cost.
Which FortiGate should you be running these tests on?
Run them on a model sized for your throughput with security services enabled, not just the raw firewall figure. If your bandwidth tests keep landing under your circuit speed once IPS and SSL inspection are on, the device is likely undersized. For new multi-year buys, price the current G-series (30G, 50G, 70G, 90G) built on the FortiSP5 security processor, which delivers roughly 2 to 3 times the threat-protection throughput of the F-series it succeeds (40F to 30G/50G, 60F to 70G, 80F to 90G). The F-series is still sold and fully supported, so there is no need to rush a swap, but new purchases should compare against the G-series.
2-3x
Threat-protection throughput gain of the FortiSP5-based G-series over the F-series it replaces (Fortinet)
Not sure which model fits your traffic and inspection needs? As a Fortinet partner since 2003, we size, deploy, and tune FortiGate firewalls for mid-market organizations across the GTA. See our managed firewall services and Fortinet solutions, or read our companion guide on running a FortiGate speed test.
Sources
- diagnose traffictest, FortiGate / FortiOS 7.6.6 CLI Reference (Fortinet Document Library)
- Technical Tip: Explaining diagnose traffictest command limitation on FortiOS (Fortinet Community)
- Technical Tip: Use cases for the diagnose traffictest command (Fortinet Community)
- diagnose netlink interface, FortiGate / FortiOS CLI Reference (Fortinet Document Library)
- Technical Tip: Interface bandwidth usage, session and link-performance commands (Fortinet Community)
Paul Thresher 
