Author: 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.

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.

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.

diagnose traffictest server-intf port2   # define the server interface
diagnose traffictest client-intf port1   # define the client interface
diagnose traffictest run                 # run the iperf3 test

The 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        receiver

How 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).

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 receives

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        receiver

Reverse (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        receiver

How 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.

Fortinet FortiGate firewalls offer multiple Internet support with flexibility in how the different Internet connections are utilized.

There are 2 different ways to configure a multi WAN setup on the firewall which is determined by what is required for the Internet connections.

The first way to configure a multi WAN is for a redundant scenario in which the secondary Internet connection is only used when the primary goes down. In this scenario the secondary Internets static route (gateway) would have a higher metric than the primary so that it is not active when the primary is up. In order to configure a multi WAN setup for Internet redundancy a few steps must be performed which are listed below.

1. Configure the interface to be used for the secondary Internet connection (i.e. Ip address, netmask, administrative access options, etc.)
2. Configure the static route for the secondary Internets gateway with a metric that is higher than the primary Internet connection. If the secondary Internet is not a manual connection (i.e. DHCP or PPPoE) you will need to set the metric/distance within the interface settings.
3. Create dead gateway detection entries. These are required when using multiple Internet connections in order for the firewall to know what Internet connections are up/available. The setup for the dead gateway detection is quite simple; add an upstream IP address to be pinged by the FortiGate which will tell the firewall if the connection is up or down. **see tip below.
4. Configure/copy all the required firewall rules that are needed for the secondary Internet connection, if the primary is WAN1 and the secondary is WAN2 then most or all of the firewall rules for WAN1 will need to be recreated for WAN2 in order to allow traffic when the WAN2 Internet connection is active.

The second type of mutli WAN setup is having both Internet connections active at the same time in order to utilize both connections simultaneously and still have redundancy.

When using both Internet connections at the same time a ECMP (Equal Cost Multi-Path) load balancing method must be selected. The options are Source IP based Weighted load balance or Spillover.

Source IP based is the default load balance method which works by using a round robin method based on source IP addresses. The first outgoing session is routed out of the WAN1 while the second outgoing session from a different source IP address is routed out of the WAN2 Internet connection, then the next connection with a different source IP is routed out the WAN1 and so on for all new connections with different source IPs.

Weighted load balance is used to control which Internet connection will be used more based on weights. For example if WAN1 has a weight of 10 and WAN2 has a weight of 20 then WAN2 would get more sessions as it has the higher value.

Spillover is used to control outgoing traffic based on bandwidth usage. For example if WAN1 has been configured with a spillover threshold of 5 Mbit then it will handle all traffic until the bandwidth usage hits 5 Mbit then it will start sending new sessions out of the WAN2 connection until the WAN1 bandwidth usages goes below 5 Mbit then it will send connections out the WAN1 again.

1. Configure the interface to be used for the secondary Internet connection (i.e. IP address, netmask, administrative access options, etc.)
2. Configure the static route for the secondary Internets gateway with a metric that is the same as the primary Internet connection. If the secondary Internet is not a manual connection (i.e. DHCP or PPPoE) you will need to set the metric/distance within the interface settings.

Tip Using priority within the static route will tell the FortiGate which connection has higher priority when the distance/metric are the same. Use the default value of 0 for the priority of the connection you wish to be the primary and a higher priority for the secondary connection. The lower priority primary connection will be used when the FortiGate is not sure which default gateway to use for an outbound connection.

3. Create dead gateway detection entries. These are required when using multiple Internet connections in order for the firewall to know what Internet connections are up/available. The setup for the dead gateway detection is quite simple; add an upstream IP address to be pinged by the FortiGate which will tell the firewall if the connection is up or down. **see tip below.
4. Configure/copy all the required firewall rules that are needed for the secondary Internet connection, if the primary is WAN1 and the secondary is WAN2 then most or all of the firewall rules for WAN1 will need to be recreated for WAN2 in order to allow traffic when the WAN2 Internet connection is active.

Tip To force outgoing traffic through one of the Internet connections regardless of what equal cost load balancing method is being used is accomplished by using policy routes.

Policy routes are very powerful and are checked even before the active route table so any mistakes made can disrupt traffic flows. Basically how they work is by matching all of the configured values within the policy route which can be source IP/network, destination IP/network, protocol, etc. then if a match is made the FortiGate checks for a firewall policy that will allow the traffic. Also if there were policy routes for WAN2 and WAN2 is currently down, then the FortiGate does not try to make any matches for policy routes going out WAN2.

Tip When creating dead gateway detection entries, ensure that the ping server IP being used is not the default gateway as default gateway routers are usually directly connected to the FortiGate and the FortiGate will think the connection is always up even if the Internet connection is actually down. This happens because the FortiGate is pinging a local device and not an upstream device through the Internet connection.

In conclusion, Fortinet FortiGate firewalls offer businesses the flexibility to support multiple Internet connections, which can be configured in two ways: for Internet redundancy or for utilizing both connections simultaneously while still having redundancy. Both configurations require setting up the interface, configuring the static route, creating dead gateway detection entries, and configuring the firewall rules. Additionally, when utilizing both connections simultaneously, an ECMP load balancing method must be selected, which includes “Source IP based,” “Weighted load balance,” and “Spillover” options. By following these steps, businesses can ensure that their Internet connections are reliable, and their traffic is optimized for both performance and redundancy.