Tunnel group information
In Test Client Status panel, all the configured tunnel groups are listed in the table. Information of tunnel groups is also listed in the table, it includes the group name, remote host ID, algorithm, enable and the group tunnels of a tunnel group. Click Show/Hide Details to expand or collapse information of the tunnel group. Note that information of tunnel groups listed in the table cannot be changed for benchmark, and testing cannot be performed for a disable (the checkbox “Enable” is unchecked) tunnel group. Buttons to trigger benchmark testing and display test result are also listed together with every tunnel group in the table.
Measurement
All the benchmark testing cases (single tunnel testing and tunnel group testing) contain two parts, testing without traffic and testing with traffic. In the first 20 seconds, benchmark client continues to send ping ICMP echo requests to the benchmark server without sending other testing traffic together. In the next 20 seconds then, benchmark client continues to creates TCP data streams together with ping ICMP echo requests to measure the throughput of the tunnel (WAN links). The testing traffic between benchmark client and server is encapsulated with GRE header, so that it simulates real tunnel transmission for performance measurement. Benchmark server responses client for the testing traffic via the same tunnel, and the measurement result can be generated by benchmark client and displays in the table. The measurement result contains
| Tunnel | WAN links employed by the tunnel between the symmetric sites. |
| Without Traffic – RTT | Round-Trip Time of the ping ICMP packets in average (without other tunnel traffic). |
| Without Traffic – Packet Loss | Packet loss of the ping ICMP packets in percentage (without other tunnel traffic). |
| With Traffic – Bandwidth | Throughput of the tunnel. |
| With Traffic – RTT | Round-Trip Time of the ping ICMP packets in average (with the traffic of throughput measurement). |
| With Traffic – Packet Loss | Packet loss of the ping ICMP packets in percentage (with the traffic of throughput measurement). |
To evaluate the quality of a tunnel (two WAN links) exactly, we suggest to stop any general-purpose traffic passing through the WAN links while a measurement is running on a tunnel.
See also
Tunnel Routing
How the Tunnel Routing Works
Tunnel Routing – Setting
How to set up routing rules for Tunnel Routing Scenarios
Scenarios
Example 1
A company’s headquarters and two branch offices are located in different cities. Each office has a LAN, multiple WAN links and a DMZ with VPN gateway:
| Headquarters | Branch 1 | Branch 2 | |
| WAN1 | 1.1.1.1 | 2.2.2.2 | 6.6.6.6 |
| WAN2 | 3.3.3.3 | 4.4.4.4 | 8.8.8.8 |
| WAN3 | Dynamic IP | N/A | 10.10.10.10 |
| LAN | 192.168.1.0/24 | 192.168.2.0/24 | 192.168.3.0/24 |
The settings for the headquarters:
Set the field Local Host ID as HQ. Local Host ID: HQ
Tunnel Group
| Group Name | Remote Host
ID |
Algorithm | Tunnels
Local IP |
Remote IP | Weight |
| HQ-Branch1
HQ-Branch1 Backup HQ-Branch2 |
B1
B1 B2 |
Round-Robin
Round-Robin Round-Robin |
1.1.1.1 | 2.2.2.2 | 1 |
| 1.1.1.1 | 4.4.4.4 | 1 | |||
| 3.3.3.3 | 2.2.2.2 | 1 | |||
| 3.3.3.3 | 4.4.4.4 | 1 | |||
| 1.1.1.1 | 6.6.6.6 | 1 | |||
| 3.3.3.3 | 8.8.8.8 | 1 | |||
| HQ-Branch2 Backup | B2 | Round-Robin | Dynamic WAN | 10.10.10.10 | 1 |
Routing Rules
| Source | Destination | Service | Group | Fail-Over |
| 192.168.1.1-192168.1.10 | 192.168.2.1-192.168.2.10 | Any | HQ-Branch1 | HQ-Branch1 Backup |
| 192.168.1.1-192.168.1.10 | 192.168.3.1-192.168.3.10 | Any | HQ-Branch2 | HQ-Branch2 Backup |
| 1.1.1.11 | 2.2.2.22 | Any | HQ-Branch1 | AR |
| 1.1.1.11 | 6.6.6.66 | Any | HQ-Branch2 | No-Action |
The settings for the branch1
Set the field Local Host ID as B1 Local Host ID: B1
| Group Name | Remote Host
ID |
Algorithm | Tunnels
Local IP |
Remote IP | Weight |
| Branch1-HQ | HQ | Round-Robin | 2.2.2.2 | 1.1.1.1 | 1 |
| 2.2.2.2 | 3.3.3.3 | 1 | |||
| 4.4.4.4 | 1.1.1.1 | 1 | |||
| 4.4.4.4 | 3.3.3.3 | 1 |
Routing Rules
| Source | Destination | Service | Group | Fail-Over |
| 192.168.2.1-192168.2.10 | 192.168.1.1-192.168.1.10 | Any | Branch1- HQ | No-Action |
| 2.2.2.22 | 1.1.1.11 | Any | Branch1- HQ | AR |
The settings for the branch2
Set the field Local Host ID as B2 Local Host ID: B2
Tunnel Group
| Group Name | Remote Host
ID |
Algorithm | Tunnels
Local IP |
Remote IP | Weight |
| Branch2-HQ | HQ | Round-Robin | 6.6.6.6 | 1.1.1.1 | 1 |
| 6.6.6.6 | 3.3.3.3 | 1 | |||
| 8.8.8.8 | 1.1.1.1 | 1 | |||
| 8.8.8.8 | 3.3.3.3 | 1 | |||
| 10.10.10.10 | Dynamic IP | 1 |
Routing Rules
| Source | Destination | Service | Group | Fail-Over |
| 192.168.3.1-192168.3.10 | 192.168.1.1-192.168.1.10 | Any | Branch2- HQ | No-Action |
| 6.6.6.66 | 1.1.1.11 | Any | Branch2- HQ | AR |
According to example 1, any data sent from 1.1.1.11 (or 192.168.1.1-192.168.1.10) to 2.2.2.22 will be wrapped and sent as a GRE packet. If 1.1.1.1 experiences a WAN link failure, the packet will still be sent from 3.3.3.3 to continue the transfer.
NOTE: When using tunnel routing in FortiWAN, the settings must correspond to each other or else tunnel routing will not perform its function. For example, if FortiWAN in Taipei has removed the values 2.2.2.2 to 3.3.3.3 in their routing rule settings, then the FortiWAN in Taichung will not be operational.
Example 2: Tunnel Routing with Dynamic IP
A company operates a branch office oversea. In the headquarters, two WAN links are deployed: a fixed IP WAN and a dynamic IP WAN; in the branch, two dynamic IP WAN.
Requirements
As illustrated in the diagram below, a tunnel is established between LAN1 and LAN2. Packets are transferred via two WAN links evenly.