Backup Line Settings

In the deployment of multiple links, a link might serve as backup line which is inactive unless it matches the enabling criteria. The choice of backup lines mostly depends on cost, especially in areas where charges are based on data traffic. Backup lines in standby do not cost a cent, thus only basic fees are charged. Contrary to backup lines, main lines are lines commonly in use. The concept is to be used below.

FortiWAN provides log mechanism to the Backup Line service, see “Log”.

Threshold Parameters

Backup Line Enable Time    :   The interval to enable backup lines after main lines have broken down.

Backup Line Disable Time    :   The interval to disable backup line after main lines have returned to normal.

Backup Line Rules table

Field Purpose / Description

Main Line    :   Select main lines, which can be multiple links.

IP Grouping

Backup Line    :   Select backup lines.

Algorithm    :          5 options to activate backup lines:

• All fail: when all lines defined in [Main line] are down l One fails: when one of the lines defined in [Main line] is down l Inbound bandwidth usage reached: when the inbound bandwidth consumption of all lines defined in [Main Line] reaches the defined level
• Outbound bandwidth usage reached: when the outbound bandwidth consumption of all lines defined in [Main Line] reaches the defined level
• Total traffic reached: when the total bandwidth consumption of all lines defined in [Main Line] reaches the defined level

Parameter         :         When the latter 3 options are chosen in [Algorithm], you can define here the bandwidth usage of the main lines over which backup lines are to be enabled.

IP Grouping

[IP Grouping] lets you create and manage IP groups exclusively and efficiently. These predefined IP groups are available and easy to use in the drop-down list of the fields of [Source] and [Destination] on such [Service] submenus as [Firewall], [NAT], [Persistent Routing], [Auto Routing], [Inbound BM], [Outbound BM], [Connection Limit], and [Cache Redirect]. This section walks you through the steps to create an IP group.

IP Grouping Table:

After you have clicked [Show IPv4/IPv6 Detail], [IPv4/IPv6 Rules Settings] table displays. You can click [Hide IPv4/IPv6 Details] to close the table.

IPv4/IPv6 Rule Settings Table:

E    :   Check the field to add the list of IP addresses to the current IP group.

IP Address         :       Enter a single IPv4/IPv6 address, IPv4/IPv6 range, IPv4/IPv6 subnet or FQDN.

Service Grouping

Action         :       Two options, to belong and not to belong, to determines whether an IP address defined in [IP Address] belongs to the IP group. For exceptions in an IP range or subnet that belongs to the IP group, the action of not to belong makes the configuration easier than separating an IP range or subnet into several groups.

Service Grouping

[Service Grouping] lets you create and manage service groups exclusively and efficiently. You can group an ICMP, a TCP/UDP Port, and a group of TCP/UDP Ports, particular applications and server ports. These predefined service groups are available and easy to use in the drop-down list of the fields of [Source] and [Destination] on such [Service] submenus as [Firewall], [NAT], [Virtual Server], [Auto Routing], [Inbound BM], [Outbound BM].

Here is an example to elaborate on how to configure [Service Grouping]. Create a service group “MSN File Transfer”, which uses TCP 6891-6900. Then enter TCP@6891-6900 in the [Service] field.

Busyhour Settings

[Busyhour Settings] plays a crucial role in managing bandwidth. .Generally opening hours Mon-Fri: 09h00 to 18h00 is configured to be busy hours, for this period sees the advent of bandwidth-intensive applications in both intranet and extranet.

For the case that time period 09:00-18:00 from Monday to Saturday belongs to busy hour and only Sunday belongs to idle hour, set an idle rule for 00:00-00:00 on Sunday beyond a busy rule for Any day 09:00-18:00. The rule would be first matched from the top down.

As is shown in the figure, Sunday and hours beyond Mon-Sat: 09h00-18h00 are set to be idle hours. Remaining hours of the week belong to busy hours.

Diagnostic Tools

Click the tabs [IPv4] and [IPv6] on the upper side to choice diagnostic tools for IPv4 and IPv6.

IPv4

IPv4 ARP

Enforcement [ARP Enforcement] forces FortiWAN’s attached PCs and other devices to update ARP table. Click [Enforce] and system will send out ARP packets force ARP updates throughout the attached devices. Generally the function is used only when certain devices in DMZ cannot access the Internet after FortiWAN has been installed initially.

IP Conflict Test

[IP Conflict Test] checks if any PC’s IP address runs into conflict with that in WAN or DMZ settings in [Network Settings].

Click [Test] to start testing. And IP conflict message may be one of:

• Test completed, no IP conflict has been found.
• There is an IP conflict with a PC in DMZ, a public IP which has been assigned to WAN in [Network Settings] is now used in DMZ, for example. And the MAC address of this IP is also listed in the message.
• There is an IP conflict with a PC in WAN; a public IP has been assigned to DMZ in [Network Settings] is now used in WAN, for example. And the MAC address of this IP is also listed in the message.

Clean IPv4 Session Table (Only Non-TCP Sessions)

The function is used to clean up non-TCP session tables in FortiWAN. In FortiWAN, protocols are managed with a session timer. Old sessions may be continuously retried by users that they keep unexpired. These old sessions, are always being valid and active instead of new ones. Hence, new sessions will not get into use unless session tables are cleaned up.

IPv4 Ping & Trace Route

Ping

[Ping] is used to detect network status. Enter an IP address or host name of target device. Select a port (WAN, LAN, or DMZ). If WAN port is selected, specify the WAN link number index. Details of ICMP error message and ping are outside the scope of this manual. Please refer to other documents for more information.

Note: If you ping a domain name, ensure DNS server have been specified in [System]->[Network Settings]->[DNS Server] (See “Set DNS server for FortiWAN”).

Trace

[Trace] is used to trace the route path of a packet from a specific port to destination host. Enter an IP address or host name of target device in [Target]. Select a link port (WAN, LAN, or DMZ). If WAN port is selected, specify the WAN link number index. [Host] can be an IP address or domain name of the target device.

Note: If you trace route with a domain name, ensure DNS server has been specified in [System]->[Network Settings]->[DNS Server] (See “Set DNS server for FortiWAN”).

Arping

[Arping] is used to detect the MAC address of a PC. Enter an IP address or host name of target device. Select a port (WAN, LAN, or DMZ). If WAN port has been selected, specify the WAN link number index. Details of ARP and error message are out of the scope of this manual; please refer to other documents for more information.

Note: If you arping with a domain name, ensure DNS server has been specified in [System]->[Network Settings]-> [DNS Server] (See “Set DNS server for FortiWAN”).

IPv4 ARP Table Show & Clear

[IPv4 ARP Table Show & Clear] is used to display or clear the ARP information of certain port. Select a [port] and click [Show], to display the ARP information of this port. Or select a [port], click [Clear] to clean up the ARP information of this port, and confirm the message to clear. After this, a message shows that ARP table has been cleared successfully.

Nslookup Tool

[Nslookup Tool] is used to inquire domain name of hosts. Enter a host in Target Domain. Select a host type from optical [Type] list: Any, A, AAAA, CNAME, DNAME, HINFO, MX, NS, PTR, SOA, SRV, TXT; and select a server from optical [Server] list: Internal DNS, Multihoming, etc. Click [Nslookup] to start the inquiring session, and the domain name of target host will show in the field. Click [Stop] to halt the session.

IPv6

IPv6 Neighbor Discovery Enforcement

When IPv6 Neighbor Discovery is enforced, FortiWAN will send out a “neighbor discovery” packet to neighbor servers or network devices within the same network to request for a reply of IPv6 and MAC address of devices found.

Clean IPv6 Session Table (Only Non-TCP Sessions)

The function is used to clean up non-TCP session tables in FortiWAN. In FortiWAN, protocols are managed with a session timer. Old sessions may be continuously retried by users that they keep unexpired. These old sessions, are always being valid and active instead of new ones. Hence, new sessions will not get into use unless session tables are cleaned up.

IPv6 Ping & Trace Route

Ping

[Ping] is used to detect network status. Enter an IP address or host name of target device. Select a port (WAN, LAN, or DMZ). If WAN port is selected, specify the WAN link number index. Details of ICMP error message and ping are outside the scope of this manual. Please refer to other documents for more information.

Note: If you ping a domain name, ensure DNS server have been specified in [System]->[Network Settings]->[DNS Server] (See “Set DNS server for FortiWAN”).

Trace

[Trace] is used to trace the route path of a packet from a specific port to destination host. Enter an IP address or host name of target device in [Target]. Select a link port (WAN, LAN, or DMZ). If WAN port is selected, specify the WAN link number index. [Host] can be an IP address or domain name of the target device.

Note: If you trace route with a domain name, ensure DNS server has been specified in [System]->[Network Settings]->[DNS Server] (See “Set DNS server for FortiWAN”).

Arping

[Arping] is used to detect the MAC address of a PC. Enter an IP address or host name of target device. Select a port (WAN, LAN, or DMZ). If WAN port has been selected, specify the WAN link number index. Details of ARP and error message are out of the scope of this manual; please refer to other documents for more information.

Note: If you arping with a domain name, ensure DNS server has been specified in [System]->[Network Settings]-> [DNS Server] (See “Set DNS server for FortiWAN”).

IPv6 Neighbor Table Show & Clear

[IPv6 Neighbor Table Show & Clear] is used to display or clear the IPv6 and MAC address of neighbor servers or devices. Select a [port] and click [Show], to display the neighbor information of this port. Or select a [port], click [Clear] to clean up the neighbor information of this port, and confirm the message to clear. After this, a message shows that neighbor table has been cleared successfully.

Nslookup Tool

[Nslookup Tool] is used to inquire domain name of hosts. Enter a host in Target Domain. Select a host type from optical [Type] list: Any, A, AAAA, CNAME, DNAME, HINFO, MX, NS, PTR, SOA, SRV, TXT; and select a server from optical [Server] list: Internal DNS, Multihoming, etc. Click [Nslookup] to start the inquiring session, and the domain name of target host will show in the field. Click [Stop] to halt the session.

Tcpdump

Setting the system time & date

[Date/Time] lets you configure time, date, and time zone. [Date] follows the year/month/day date format, and [Time] uses 24-hour time system in the hour:minute:second format. [Time Zone] is represented by continent and city, [America] and [New York], for example. FortiWAN uses NTP time server for accurate time synchronization, simply by clicking the [Synchronize Time] button. And other time servers are also included in the drop-down list which can be added or deleted at your preference.

Remote Assistance

Enabling this function allows Fortinet’s technical support specialist to enter your system for further troubleshooting when assistance is needed. FortiWAN allows technical support specialist to access the Web UI and backend system remotely, so as to assist users promptly upon the occurrence of problems. Remote assistance opens both TCP ports 443 for web UI and 23 for SSH debug.

Note: To enter the backend system via SSH login, a debug patch file is required.

Administration

Go to System > Administration, Administration lets you perform administrative tasks, including changing passwords of Administrator and Monitor. Every FortiWAN is shipped with the same default passwords. For security concerns, it is thus strongly recommended that the passwords shall be changed.

By default, FortiWAN uses 443 as the Web UI login port. And it allows administrators to change the port, to avoid possible port conflict caused for virtual server services.

Update/downgrade section enables to update or downgrade firmwares once new firmwares are available (from our website or dealers). Simply click the Update/Downgrade button and follow exactly the on-screen instructions.

Configuration Files gives you the ability to back up configuration files, by clicking the [Save] button. Or you can click [Restore] to reload the previous backup files to FortiWAN. System configurations can be recovered from failures via the backup configuration files.

In Maintenance, you can restore factory default configurations and reboot FortiWAN. Due to the limitation of HTML syntax, no hint displays after reboot has been completed. Thus you have to wait about two minutes before navigating to Web UI in browser.

Administrator and Monitor Password

FortiWAN maintains a common local authentication database for its Web UI, CLI and SSH login (See

“Connecting to the Web UI and the CLI”). Accounts for authentication are classified into two groups,

Administrator and Monitor, with different permissions. Accounts belonging to Administrator have the permission to monitor and modify system parameters via Web UI, CLI and SSH login, while limited operations are allowed (monitor system information and traffic statistics via Web UI ONLY) to accounts belonging to Monitor.

Configurations applying, system administrations (managements introduced in this topic), Tunnel Routing Benchmark, CLI access and SSH login are invalid for Monitor group. Note that page System > Administration is not available to Monitor accounts.

Default account/password

While the first time you login to Web UI, you see the default accounts here. “Administrator” and “admin” are the default accounts of group Administrator, and “Monitor” is the default account of group Monitor. Passwords of accounts “Administrator” and “Monitor” are “1234” and “5678” respectively; password of account “admin” is null (See “Appendix A: Default Values”). All the accounts (default and customized) of group Administrator are able to log into Web UI, CLI and SSH login. All the accounts are case sensitive.

Create, modify and delete the account and password for Administrators or Monitors.

Event notifications via SNMP trap

You can receive notification via SNMP trap for any modification of the FortiWAN’s account. Configure the SNMP manager on your FortiWAN and enable the event type “Account change” to notify (See “Notification”), then notification will be delivered to your SNMP manager for the events. The correspondent MIB fields and OIDs are listed as following:

SNMP field names and OIDs

RADIUS Authentication

Except FortiWAN’s local authentication database described above, FortiWAN supports RADIUS authentication for Web UI login. Please make sure the following settings are complete on the RADIUS server working with FortiWAN.

Add Fortinet’s Vender Specific Attribute (VSA) to /etc/raddb/dictionary:

VENDOR Fortinet 12356 BEGIN‐VENDOR Fortinet …

ATTRIBUTE Fortinet‐FWN‐AVPair 26 string …

END‐VENDOR Fortinet

“12356” is Fortinet’s vender ID, “Fortinet-FWN-AVPair” is the attribute used for working with FortiWAN and “26” is the attribute ID. If the RADIUS server serves with other Fortinet products, please add the correspondent attributes between BEGIN‐VENDOR Fortinet and END‐VENDOR Fortinet.

Construct user database on RADIUS server for authentication. For example, we have accounts

“Administrator/1234” and “admin/(null)” belong to Administrator group, and “Monitor/5678” belongs to Monitor group.

Add the followings to /etc/raddb/users:

Administrator User‐Password := “1234”

Fortinet‐FWN‐AVPair := “user‐group=Administrator” admin User‐Password := “”

Fortinet‐FWN‐AVPair := “user‐group=Administrator”

Monitor User‐Password := “5678”

Fortinet‐FWN‐AVPair := “user‐group=Monitor”

Please make sure “user-group” is specified for every account, or FortiWAN denies the login even the account and password are authorized by RADIUS server.

To enable FortiWAN’s RADIUS authentication, please click the checkbox and complete the configuration below.

Firmware Update

Click [Update] or [Downgrade] and follow the on-screen instructions to perform firmware update/downgrade. Note that firmware downgrade will reset current configurations to factory default, please backup current configurations in advance. Firmware update and downgrade support jump directly to a version from current version without applying all the updates or downgrades that have been released between the versions.

Updating the FortiWAN Firmware:

• Before proceeding with the firmware update, ALWAYS backup system configurations.
• Obtain the latest firmware upgrade pack from https://support.fortinet.com. l Log onto the Web UI with administrator account and go to [System]→ [Administration]. l Click on “Update”. l Use [..] to select the path of the new firmware image.
• For High Availability (HA) deployment (See “FortiWAN in HA (High Availability) Mode”), check [Update Slave] to perform firmware update on the slave unit at the same time. Please double check and make sure the peer device is under normal condition (from page [System > Summary]) before HA firmware update.
• Click [Upload File] to start updating.
• The firmware update will take a while, so please be patient. During the update process, be sure NOT to turn off the system or unplug the power adapter. DO NOT click on the [Upload] button more than once.
• Update is completed when the “Update succeeded” message appears. FortiWAN unit(s) will reboot automatically then.

Errors that occur during the update can be caused by any reason below:

• General error – Please contact your dealer if this happens repeatedly.
• Invalid update file – The file uploaded for firmware update is invalid, please make sure the uploaded file is correct. l MD5 checksum error – Image file is damaged. Please reload and try again.
• Incompatible version/build – Firmware version incompatible. System requires a higher version firmware for update and a lower version firmware for downgrade.Check with your dealer for the correct firmware version.
• Incompatible model/feature – Firmware image does not match the FortiWAN system. Check with your dealer for the correct model and version.
• Incompatible platform – Firmware image does not match the current FortiWAN platform. Check with your dealer for the correct model and version.
• Update error – If this error message appears during firmware update, please do not turn off the device and contact your dealer immediately. l Unknown error – Contact your dealer.

When a firmware update has being processed in system, users (multi-account login, see “Using the Web UI”) are unable to perform concurrent firmware updates at the same time.

Configuration File

Click [Save] to back up the current configurations of all functions in one binary file on your PC. Click [Show] to display a binary configuration file (.cfg) as readable content. Click [Restore] to recover whole system with the backed up configurations. Note that Restore will apply the configurations to system and then perform synchronization to the slave unit if HA mode is deployed. After this, system automatically reboot. The configuration file here is in binary format and should NOT be edited outside of FortiWAN tools and systems. The configuration file here contains all the configurations of FortiWAN’s functions. You can have individual configuration file of every single function via the export function in every function page. Do NOT to turn off the power while restoring the configuration file, or repetitively clicking on the [Restore] button.

Configuration File for individual function Export and Import:

• Log on to FortiWAN as administrator. On every single function page of Web UI, click [Export Configuration] to back up the configuration in an editable text file.
• To import the previously saved configuration file, click [Browse] on the function page of Web UI to select the configuration file previously saved, and then click [Import Configuration] to import previous configurations. The imported configuration will be displayed on the Web UI, but not be applied to system. Click [Apply] button to apply it to system.

During the configuration file restoration process, if an error occurs, it is most likely the result of one of the following:

• The total WAN bandwidth setting in the restored configuration file exceeds the max bandwidth defined for the current system. The bandwidth can be either upload stream and download stream.
• The restored configuration file contains port numbers exceeding the port numbers defined by the system.
• The restored configuration file contains VLAN parameters not supported by the machine. l The total number of WAN links in the restored configuration file exceeds the current system definition. l Incompatible versions and/or systems.

Note:

• FortiWAN does not guarantee full compatibility of configuration files for different models. l After the firmware upgrade, it is encouraged to backup the configuration file.

Configuration file backup and restore are available in the following function page:

Maintenance

Click [Factory Default] to reset configurations to factory default. Or you can perform “resetconfig” command in console. Click [Reboot] to reboot FortiWAN. For information on console command, please refer to Console Mode Commands.

Web UI Port

Type the port number in [New Port] and then click [Setport]. Enter the new port number when you log in again into Web UI. Additionally, the new port shall avoid conflict with FortiWAN reserved ports when configuring the port. Otherwise, FortiWAN will display error message of port settings failure and resume to the correct port number that was configured last time.

License Control

License Control provides users with all the License Key configurations, including:

Bandwidth Upgrade License:

FortiWAN provides various bandwidth capabilities for individual model. Bandwidth upgrade on models is supported via a license key. You could ask your distributor for bandwidth upgrade license keys.

• FortiWAN 200B provides 200 Mbps, 400 Mbps and 600 Mbps bandwidth capability.
• FortiWAN 1000B provides 1 Gbps, and 2 Gbps. l FortiWAN 3000B provides 3 Gbps, 6 Gbps, and 9 Gbps bandwidth capability.

Product Model Bandwidth Capability

Note: Conditional bandwidth upgrade is provided for old models. Please contact customer support to gain further information.

Load Balancing & Fault Tolerance

With the rapid proliferation and decreasing prices of broadband solutions, more and more small and medium enterprises are opting for the use of multiple WAN links from various ISPs. The benefits include:

• Single link failure does not result in a total loss of internet connectivity, thus WAN reliability increases.
• Traffic can be evenly dispersed across multiple WAN links, resulting in increased efficiency and improved performance of bandwidth.
• Multiple WAN links for fault tolerance and load balancing has two advantages:
• The outbound traffic, i.e. traffic originating from LAN traveling outwards, can be load-balanced across multiple WAN links. This is Auto Routing. l Traffic from the WAN, i.e. traffic originating from WAN traveling towards the LAN, can be load-balanced across multiple WAN links. This is Multihoming.

Load Balancing Algorithms

Load balancing algorithm is one of the important components for achieving purpose of traffic load balancing via FortiWAN’s various services, such as Auto Routing, Multihoming, Tunnel Routing, Virtual Server and DNS Proxy. These services distribute inbound or outbound traffic over multiple resources (WAN links or internal servers) according to predefined policies, which consist of a load balancing algorithm and the participating resources. A Load balancing algorithm dynamically evaluates on the availability of the participants against factors such as weight, connections or traffic, and picks an appropriate one for the load balancing services assign traffic to. When traffic (sessions or packets) matches a filter rule or policy of a load balancing service, the corresponding algorithm (specified to the policy) determines the appropriate one from the specified resources for the service to handle the traffic. All the load balancing services detect and label the unavailable resources by their own mechanism, such as WAN link health detection (see WAN Link Health Detection). The algorithms will ignore the failed resources and work with the available ones.

The followings are the algorithms that FortiWAN provides for services Auto Routing, Multihoming, Tunnel Routing, Virtual Server and DNS Proxy.

See also

Outbound Load Balancing and Failover (Auto Routing)

Inbound Load Balancing and Failover (Multihoming)

Tunnel Routing

Virtual Server & Server Load Balancing DNS Proxy

Round Robin (weighted)

Weight Round Robin picks one of the participating resources in circular order according to the specified weights. Round Robin works without considering resource’s ability such as processing connections, available bandwidth and response time. In FortiWAN, algorithm Round Robin serves for Auto Routing, Multihoming, Tunnel Routing, Virtual Server and DNS Proxy (it is called By Weight in DNS Proxy). To create a load balancing policy with Round Robin, you need specify the participants (WAN links or internal servers) and assign the weight to each of them.

For example, if three WAN links (WAN1, WAN2 and WAN3) are defined in an Auto Routing policy with weight

3:1:2, Round Robin returns one of the three WAN links to Auto Routing in the order of WAN1, WAN1, WAN1, WAN2, WAN3, WAN3. So that Auto Routing can distribute sessions to WAN links in the order. If some of the participants get failed, Round Robin will ignore them and work with the rest participants. For example, if WAN2 goes to failure, then Round Robin return the WAN link to Auto Routing in the order of WAN1, WAN1, WAN1, WAN3, WAN3.

Round Robin works similarly for Multihoming, Tunnel Routing, Virtual Server and DNS Proxy. For the details of configuring a policy of a service, see the section relevant to each of them.

By Connection

By connection picks one of the participating resource (WAN links or internal servers) for Auto Routing and Virtual

Server, but the processes that By Connection works for Auto Routing and Virtual Server are totally different. For

Auto Routing, an idea of weighted Round Robin is involved in the By Connection algorithm. The goal of Auto Routing’s By Connection is to guarantee the number of connections being processed by each participating WAN link in a fixed weight. By Connection counts the number of connections running on each participating WAN link and picks one for a new-coming connection to keep the ration of connections running on the WAN links closely fixed after adding the new connection to the picked one. For example, there are three WAN links (WAN1, WAN2 and WAN3) are defined in an Auto Routing policy with weight 1:1:2. By Connection will respectively return WAN1, WAN2 and WAN3 to Auto Routing for the first three connections, if all the three WAN links are idle. So far, the count of connections running on WAN1, WAN2 and WAN3 goes to 1:1:1. To match the specified weight 1:1:2 of the policy, By Connection will return WAN3 for the forth connection. Next, By Connection returns WAN1 and WAN2 respectively for the fifth and sixth connections and so the count goes to 2:2:2. Obviously, By Connection will return WAN3 for the next two (seventh and eighth) connections, so that the count will be 2:2:4 which is in the ratio 1:1:2. Considering the two connections on WAN2 are closed (the counts become 2:0:4), By Connection must return WAN2 for the next two connections to keep the counts be in ratio 1:1:2. If some of the participants get failed, By Connection will ignore them and work with the rest participants. For example, if WAN2 goes to failure, By Connection will work by keeping the connection count on WAN1 and WAN3 in weight 1:2.

As for Virtual Server, By connection treats service requests coming from the same source IP address as the same connection. The algorithm determine an internal server from server pool for incoming requests of a connection by hashing source IP address of the connection. The hash mechanism that By connection uses is the same as algorithm Hash (see section Hash later). Every internal server in the server pool has the same weight for By connection’s hash mechanism.

By Downstream Traffic

By Downstream Traffic picks one of the participating resources (WAN links) according to the weight mainly relevant to their data downloading availability. Each of the participating WAN links is weighted every three seconds by summing 80% available inbound bandwidth and 20% available outbound bandwidth up. For example, there is an Auto Routing policy with participants WAN1, WAN2 and WAN3. If, at some time, the available inbound bandwidth on WAN1, WAN2 and WAN3 is 4Mbps, 10Mbps and 6Mbps, and the available outbound bandwidth on WAN1, WAN2 and WAN3 is 8Mbps, 5Mbps and 20Mbps, the weight of each WAN link is so that calculated as:

WAN1: 0.8*(4/10) + 0.2*(8/20) = 0.4

WAN2: 0.8*(10/10) + 0.2*(5/20) = 0.85

WAN3: 0.8*(6/10) + 0.2*(20/20) = 0.68

Before the weights are updated next time , By Downstream Traffic returns one of the three WAN links for the load balancing policy in circular order with weight 40:85:68. Weights will be updated by calculating with real-time available bandwidth every three seconds. By Downstream Traffic serves for Auto Routing, Multihoming and DNS Proxy.

By Upstream Traffic

By Upstream Traffic serves Auto Routing, Multihoming, Tunnel Routing and DNS Proxy. However, the process that By Upstream Traffic works for Tunnel Routing is different from Auto Routing, Multihoming and DNS Proxy. For working with Auto Routing, Multihoming and DNS Proxy, By Upstream Traffic picks one of the participating resources (WAN links) according to the weight mainly relevant to their data uploading availability. Each of the participating WAN links is weighted every three seconds by summing 80% available outbound bandwidth and 20% available inbound bandwidth up. For the same example, there is an Auto Routing policy with participants

WAN1, WAN2 and WAN3. If, at some time, the available inbound bandwidth on WAN1, WAN2 and WAN3 is 4Mbps, 10Mbps and 6Mbps, and the available outbound bandwidth on WAN1, WAN2 and WAN3 is 8Mbps, 5Mbps and 20Mbps, the weight of each WAN link is so that calculated as:

WAN1: 0.8*(8/20) + 0.2*(4/10) = 0.4

WAN2: 0.8*(5/20) + 0.2*(10/10) = 0.4

WAN3: 0.8*(20/20) + 0.2*(6/10) = 0.92

Before the weights are updated next time , By Upstream Traffic returns one of the three WAN links for the load balancing policy in circular order with weight 40:40:92. Weights will be updated by calculating with real-time available bandwidth every three seconds.

As for working with Tunnel Routing, By Upstream Traffic divides the available uploading bandwidth of each participating WAN link by the number of GRE tunnel deployed on the WAN link, and picks one with the most available uploading bandwidth. For example, there is a Tunnel Routing Group consisting of three GRE tunnels deployed on WAN1, WAN2 and WAN3 respectively. Other Tunnel Routing Groups deploy 2 GRE tunnels on WAN1, 3 GRE tunnels on WAN2 and 1 GRE tunnel on WAN3. Totally, there are 3 tunnels on WAN1, 4 tunnels on

WAN2 and 2 tunnels on WAN3. If, at a time, the available uploading bandwidth of WAN1, WAN2 and WAN3 is 6Mbps, 20Mbps and 12Mbps, By Upstream Traffic will picks WAN3 for transferring packets matching this Tunnel Routing Group because:

WAN1: 6Mbps/3 = 2Mbps

WAN2: 20Mbps/4 = 5Mbps

WAN3: 12Mbps/2 = 6Mbps

By Upstream Traffic for Tunnel Routing is not a Round-Robin based algorithm, it always picks the resource with most available uploading bandwidth.

By Total Traffic

By Total Traffic serves Auto Routing, Multihoming and DNS Proxy. By Total Traffic picks one of the participating resources (WAN links) according to the weight evenly relevant to their data downloading and uploading availability. Each of the participating WAN links is weighted every three seconds by summing 50% available inbound bandwidth and 50% available outbound bandwidth up. For example, there is an Auto Routing policy with participants WAN1, WAN2 and WAN3. If, at some time, the available inbound bandwidth on WAN1, WAN2 and WAN3 is 4Mbps, 10Mbps and 6Mbps, and the available outbound bandwidth on WAN1, WAN2 and WAN3 is 8Mbps, 5Mbps and 20Mbps, the weight of each WAN link is so that calculated as:

WAN1: 0.5*(4/10) + 0.5*(8/20) = 0.4

WAN2: 0.5*(10/10) + 0.5*(5/20) = 0.625

WAN3: 0.5*(6/10) + 0.5*(20/20) = 0.8

Before the weights are updated next time , By Total Traffic returns one of the three WAN links for the load balancing policy in circular order with weight 400:625:800. Weights will be updated by calculating with real-time available bandwidth every three seconds.

Notices of By Upstream Traffic, By Downstream Traffic and By Total Traffic

What the available bandwidth that algorithms By Upstream, Downstream and Total Traffic using for Auto Routing and Multihoming will depend on how Bandwidth Management (see Bandwidth Management) is configured. Considering that a Bandwidth Management class limits the usage of maximum downloading and uploading bandwidth of a 20Mbps/10Mbps WAN link to 6Mbps and 3Mbps respectively. For traffic classified to this BM class, the available downloading and uploading bandwidth for algorithms By Upstream, Downstream and Total Traffic to evaluate this WAN link will never exceed the bandwidth limits 6Mbps/3Mbps, even if the WAN link is wholly idle.

Algorithms By Upstream, Downstream and Total Traffic measure the transmission ability of a WAN link only between the FortiWAN device and the gateway of its ISP network (last mile). The available bandwidth of a WAN link is measured on the network interface of the WAN link. Algorithms By Upstream, Downstream and Total Traffic do not guarantee transmission ability between the ISP network and destinations.

By Optimum Route

Relative to algorithms By Upstream, Downstream and Total Traffic , By Optimum Route evaluates a WAN link with not only its traffic loading but also the round-trip time (RTT) between FortiWAN and the destinations. The evaluation involves bandwidth usage of a WAN link and the RTT, which responses the network conditions closer to reality. For example a WAN link with the most available bandwidth might not be the best choice for data transferring to a destination, if it has the worst RTT. Conversely, the WAN link with fewer available bandwidth might be picked by Optimum Route if the RTT is good. By Optimum Route works for Auto Routing and Multihoming to mainly avoid the peering issue between ISP networks. Optimum Route works via various detections and measures. It requires to have the details configured first to make sure it works appropriately (See Optimum Route Detection).

By Response Time

By Response Time is only used by Virtual Server (see Virtual Server & Server Load Balancing) for distribute incoming service requests to internal servers to achieve server load balancing. By Response Time measures the response time of each internal server by sending a detection packets, and picks one server with the lowest response time for Virtual Server routes the matched requests to it.

By Static

By Static is only used by Multihoming for responding fixed IP addresses to DNS requests for an A/AAAA record without considering the traffic loading and connectivity state of each WAN link. By Static deprives Multihoming of inbound load balancing and WAN link failover; retrogrades it back to general DNS service. Note that the external clients will access to the responded IP addresses, and the accesses might be stuck or failed if the WAN link is congested or unavailable.

By Fixed

By Fixed is only used by Auto Routing for routing outbound traffic to a fixed WAN link without considering the traffic loading on the WAN link. Different from Multihoming’s By Static, By Fixed will not return the WAN link to Auto Routing if it is unavailable. It requires a fail-over policy (configured in a filter rule) to achieve WAN link failover when the fixed WAN link is failed. By Fixed deprives Auto Routing of outbound load balancing.

Hash

Hash is only used by Virtual Server for distribute incoming service requests to weighted internal servers to achieve server load balancing. The source IP addresses of a service request will be translated from dot-decimal address to a decimal value first. This value is then hashed by calculating the reminder of the division of the value by the sum of weights (modulo operation), and the reminder indicates the internal server that the service request should be directed to. For example, if there are three servers (serv1, serv2 and serv3) weighted with 1:2:3 in the server pool, requests that their IP addresses are congruent modulo 6 (sum of the servers’ weight:1+2+3) will be assigned to the same server according to the weights (reminder 0 indicates serv1, reminders 1 and 2 indicate serv2, reminders 3, 4 and 5 indicate serv3). The following table lists the examples how the hash function works for Virtual Server:

Outbound Load Balancing and Failover (Auto Routing)

Auto Routing Mechanism

Auto Routing load-balances the outbound traffic across multiple WAN links according to a pre-defined routing policies. During WAN link failures, auto routing will also adjust the routing methods to distribute the outbound traffic ONLY among the WAN links in fit and working conditions, thus avoiding the failed link(s).

The traditional method of backing up WAN links by having a secondary WAN link taking over the failed link. Basically having a main line and a second line as backup, aided by any standard router’s backup policy, minimum fault tolerance can be achieved. This kind of approach means certain lines remain idle for most of the time and it is a waste of resources. In addition, the router configurations can be tedious.

Another approach for multiple WAN links backup is by dividing the LAN into multiple segments, each doing its own thing as they are all independent WAN links. Under standard conditions, each segment has its own way using separate routers. When one of the WAN links fails, the administrator has to change the router configuration to bypass the failed link. The obvious drawback to this approach is the unnecessary workload for administrators. Whenever WAN link status changes, the LAN environment settings (such as gateway, netmask, router policies, proxy settings, etc) all need to be adjusted.

Fault Tolerance Mechanism

As previously stated, without WAN load-balancer such as FortiWAN, the traditional way of using multiple WAN links always involves human intervention.

FortiWAN has an internal “Virtual Trunk” circuit, which is essentially a combination of the multiple WAN links. Auto routing is capable of adjusting the ‘Virtual Trunk” to include only the WAN links that are functioning normally and to direct outbound traffic through the “Virtual Trunk circuit” without human intervention. Network users will therefore not be able to notice any change of status in WAN links (See “WAN Link Health Detection”).

The figure above illustrates auto routing securing uninterrupted connection to the internet even during WAN link failures. Compared to the traditional multiple WAN link usage, auto routing can effectively use all available WAN links to balance outbound traffic even when all the WAN links are in perfect working condition. Auto routing cannot prevent data loss on a WAN link when it fails, but all subsequent sessions will be automatically routed to other working links.

FortiWAN provides mechanisms to record, notify and analysis on events refer to the Auto Routing service, see “Log”, “Statistics: Traffic”, “Statistics: Bandwidth” and “Reports”.

Configurations

It allows administrators to determine the way traffic is routed to WAN links. Multiple WAN links have a variety of ideal auto-routing methods for any network environment. Auto routing is configured in 2 steps: Policies and Filters.

Policy

An Auto Routing policy defines how to dynamically distribute outbound traffic (sessions) over multiple WAN links according to traffic loading of the WAN links, which achieve the outbound load balancing. The basic items to define a policy are the load balancing algorithm and the related WAN parameters. By associating an Auto Routing filter rule with a policy, Auto Routing can determine a good WAN link among the candidates and route the outgoing sessions that match the filter rule to the WAN link.

Filter

Auto Routing filters are used to evaluate against the outbound sessions (sessions from LAN and DMZ to the Internet through the FortiWAN). The routing policy and fail-over of a matching filter rule are applied to the evaluated sessions. Base on the specified policies, Auto Routing determines which WAN port to use for forwarding packets of the sessions. A filter rule consists of a set of filter terms (When, Input Port, Source, Destination and Service) and the related policies (Routing policy and Fail-over policy) for action.

Example 1

The auto routing policies to be established accordingly:

1. Always route connections through WAN#1, which is an ADSL WAN link with 512k downstream/512k upstream.
2. Always route connections through WAN#2, which is an ADSL WAN link with 1.5M downstream/384k upstream.
3. Route connections with algorithm “Optimum Route”.
4. Route connections based on the current downstream traffic of WAN links.
5. Route connections based on the total traffic of each WAN link. Policy table will look like:

Note: Labeling the policies alone does not mean the policy has been set up. Configuring WAN link bandwidth must be done under [System] -> [Network Settings].

Defining filters for the following:

1. When LAN users access web server on the internet, use policy “By Optimum Route” to route connections to the best-conditioned link.
2. When LAN users access the FTP server on the internet, use policy “WAN1(512/512)” to route connections. If WAN#1 fails, the connections will be routed “By Optimum Route”. Note: In this case, “By Optimum Route” will only route connections through WAN#2 as WAN #1 has failed.
3. The connections from 211.21.48.195 in DMZ to SMTP server on the internet will be routed by policy “WAN1 (512/512)”. If WAN#1 fails, it will be routed by “WAN2 (1536/384)”.
4. The connections from 211.21.48.195 in DMZ to POP3 server on the internet will be routed by “WAN1 (512/512)”. If WAN#1 fails, no action will be taken. Note: When WAN #1 fails, connection to the external POP server will also fail.

Inbound Load Balancing and Failover (Multihoming)

Multihoming

Multihoming is a technique when external users request any server’s IP address; Multihoming promptly returns DNS response according to the link quality. This provides unmatched availability of bandwidth and load-balances incoming traffic across the multiple ISP lines.

Simultaneously using multiple IP address provided by the ISP connections can result in problems with inbound traffic. For example, if the network is currently using an IP provided by ISP1, and a problem occurs with this ISP, then the inbound query will not be received because the external traffic only knows the IP address provided by ISP1. Also, by using the IP provided ISP1, ISP2 cannot manage the inbound traffic of ISP1. Therefore the concern with multiple ISP links is how to effectively display IP address to the external environment.

Multihoming uses DNS fault-tolerance technique to resolve this problems with the simultaneous use of multiple ISP connections. For example, if the web server for external traffic uses a single ISP connection, then any problems with that connection will affect the network. However, if the DNS periodically assigns different IP addresses provided by different ISP connections, then the external traffic will always have a valid IP to connect to. The actual implementation is assigning a name of different IP, and any query to this name will receive an IP address. As a result, different users can access the web server through different IPs, which is the purpose of Multihoming.

Assuming, there are three WAN links (therefore three different IPs) for the web site of www.example.com, the DNS record has three entries:

www IN A 211.21.10.3 www IN A 63.98.110.123 www IN A 192.136.1.243

All DNS requests to www.example.com will be sent to FortiWAN. Multihoming will constantly measure the health conditions as well as the state of each WAN link and compute the optimal return answer to the DNS queries, defined as the SwiftDNS technology. The SwiftDNS technology will not only ensure fault tolerance for inbound traffic, it also supports powerful and flexible load balancing algorithms as in the Auto Routing mechanism to enable users with heavy web presence to maximize the reliability and efficiency of their web services.

The SwiftDNS Multihoming mechanism requires network administrators to understand the details of the system behavior. The fundamental concept of the DNS mechanism is shown in the next section. A step by step deployment tutorial will also be provided.

Introduction to DNS

DNS server differs from the host file based on name resolution. Host file contains information of IP address mapping information. It is only useful for intranet where the information of host machines is relatively static. Name resolution by DNS server is dynamic because it can adapt to changes easily. The way it works is based on DNS server hierarchy on the Internet. If a DNS server cannot resolve a name (the information is not in its cache), it will ask other DNS servers. There is a protocol on how and where to ask other DNS servers.

A name resolution request may go through a number of DNS servers. When an answer is found, it will be saved in cache so that the same request can be answered immediately without asking other DNS servers again. Each name resolution result saved in cache has a TTL (Time To Live). After the period of TTL, it will be discarded in order to avoid stale information.

The whole internet has a large DNS hierarchy. The top of the hierarchy is called Root. It consists of a set of Root DNS servers coordinated by ICANN. The next level below Root is Top Level Domain (TLD). TLD registration database contains information about top level domains such as CA, COM, EDU, GOV, NET, etc. The next level below TLD is Second Level Domain (such as whitehouse.gov, Microsoft.com, inforamp.net, etc.) followed by Third Level Domain, and so on.

You can apply for domains for your organization. First, go to the Internet’s Network Information Center (InterNIC) to find out if the domain has been registered already. You can also consult the ICANN-accredited registrar database. Second, register the domain with a registrar. You have to provide at least two DNS servers to serve DNS requests. If your registration has been approved, then any DNS request to your domain will be forwarded to the DNS servers you are registered with. For example, xtera.com is registered and InterNIC has put the name “xtera” into the COM DNS servers.

Once the domain is registered, sub-domains can be created. Example: a part or the network can be named “sales.xtera.com”. InterNIC’s approval is not required for creating sub-domains. However, it is important to put DNS information about sales.xtera.com into the DNS servers of xtera.com.

Here is an example of how DNS hierarchy works. A user at a university sees a link to sales.xtera.com on a web page and clicks it. The browser will ask the local DNS server dns.utexas.edu about sales.xtera.com. Suppose it is not in the cache of dns.utexas.edu. The DNS server goes to a Root DNS server to find the DNS server for COM TLD. The DNS server for COM TLD tells dns.utexas.edu to go to dns1.xtera.com. Finally dns.utexas.edu is given the IP address of sales.xtera.com by dns1.xtera.com.

SwiftDNS

One of the problems with traditional DNS servers are facing is TTL. A long TTL means a long update time when IPs have been changed. Before the update time is up (i.e. TTL is expired), DNS requests may be answered with incorrect information. FortiWAN employs SwiftDNS for multihoming based on the health state of the link and a traffic re-directing algorithm. SwiftDNS dynamically answers DNS requests to prevent broken or congested links. In order to solve the TTL issue stated above, SwiftDNS maintains a very short TTL and actively sends out updates to internal DNS in case of link status changes.

How does SwiftDNS work?

Here is an example to illustrate how SwiftDNS works. When Multihoming is enabled, SwiftDNS becomes active. In this case, the upper level DNS server for example.com has two NS records and they are for Primary DNS server at 210.58.100.1 and Secondary DNS server at 210.59.100.1. Both of them are pointing to FortiWAN.

In this case, a web site at 192.168.100.1 in LAN is exposed to these two IPs. When both ISP links are working properly, FortiWAN replies to DNS requests for www.example.com with 210.58.100.1 and 215.59.100.1 at ratio of 1:2 (weight ratio).

Assuming ISP1 is down and a DNS request for www.example.com comes in, it would not be able to go through 210.58.100.1 but it will be able to reach 215.59.100.1. Multihoming detects the link status of WAN1 and answer the request with 215.59.100.1.

Prerequisites for Multihoming

In order to multihome properly, review the requirements below.

Prerequisites for Multihoming:

• Multiple WAN links (minimum of 2).
• Registered domain names for public servers. Please make sure DNS requests for the domains can be delivered to FortiWAN. l Public servers must be configured as virtual servers, or have public IPs

Besides, Multihoming is a non-recursive name server which is an authoritative DNS service that allows others to find your domain only. Multihoming does not answer for unknown domains.

DNSSEC Support

The DNS Security Extensions (DNSSEC) is a specification that adds data authentications and integrity to standard DNS. To resist tampering with DNS responses, DNSSEC introduces PKI (Public Key Infrastructure) to sign and authenticate DNS resource record sets within the zone. A signed zone includes a collection of new resource records: RRSIG, DNSKEY and DS.

• RRSIG contains the DNSSEC signature for the corresponded DNS records (A, AAAA, MX, CNAME and etc.) within the zone.
• DNSKEY contains the public key corresponded to the private key used to generate RRSIG records. A DNS resolver uses it to verify DNSSEC signatures in RRSIG.
• DS (Delegation Signer) references to the public key used to verify the RRSIG in your zone. Every DS record should be signed by your parent zone and stored in the parent zone to establish trust chain between DNS zones.

Multihoming supports basic DNSSEC which employs only one key pair KSK (Key Sign Key) to generate DNSKEY and RRSIG records for the zone (NSEC is not supported). The supported algorithm and key size are only RSASHA512 and 2048 bits. Note that Multihoming’s DNSSEC is not supported for Relay Mode.

Remember that you have to configure DS records with your domain registrar after you complete configurations for DNSSEC. Please contact your domain registrar for further details about managing DS records.

Relay Mode

For the case that a DNS server already exists in you network, Relay Mode is the way to combine the existing DNS servers with Multihoming’s inbound load balance and fault tolerance. With Relay Mode enabled, FortiWAN will forward all the DNS requests it receives to the specified name servers, in stead of processing the requests directly. Answer of the DNS request will be responded to FortiWAN from the name server. FortiWAN’s

Multihoming then reprocess the answer with appropriate IP address according to the AAAA/A records and AAAA/A policies (load balancing algorithm). The DNS answer that contains appropriate IP address will finally responded to client, so that the inbound access could connect via the appropriate WAN link.

Enable Backup

FortiWAN Multihoming employs Backup mechanism to provide disaster recovery approach for network across various regions. Under this mechanism, the same backup service is set up across different regions. Therefore, when master site is down, backup site will immediately take over to resume the service.

To deploy Multihoming Backup between two FortiWAN units for one domain, at least one of the WAN links’ localhost IPv4 addresses of each FortiWAN unit must be registered with the parent domain (so that a DNS request for the domain can be delivered to the two FortiWAN units). Check “Enable Backup” on the Slave FortiWAN Web UI and specify the IPv4 addresses (which are registered with parent domain) of the Master FortiWAN in “Remote Master Servers”. Configurations for Multihoming Backup deployment is only necessary on the Slave unit, please do not check “Enable Backup” on the Master unit.

Then the Slave unit will detect the state of the Master unit periodically with its built-in Dig tool. The detect packets will be delivered to Master unit via the IP addresses specified on the Slave unit. When the Master’s Multihoming works properly, the Slave’s Multihoming will get into non-active mode (Unit that is in non-active mode will not answer to any DNS request); when the Master’s Multihoming is down, the Slave will get into active mode and take over to resume Multihoming. After takeover, the Slave will continuously detect Master’s state. Once the Master recovers, the Slave will return Multihoming service back to Master and get into non-active mode. This is how the Backup mechanism offers disaster recovery function. DNS database synchronization is not provided for Multihoming Backup deployment, so that DNS database can be maintained individually on the two units for local and remote-backup services. In case that multiple IP addresses of FortiWAN are registered with parent domain (to avoid single WAN links failure), those IP addresses should be configured into the “Server IPv4 Address” field on the Slave unit.

Configurations

Auto-routing is a trunking technology that provides load balancing and fault tolerance for all outbound requests, but it does not apply to inbound requests. These are handled by a unique technology called SwiftDNS, a multihoming service which includes load balancing and fault tolerance for inbound requests. The minimum requirements for multihoming are networks must have multiple WAN links and registered domain names for publicly accessible servers. Note that a DNS request from client is delivered to FortiWAN via a fixed WAN link, whose the IP address is registered with parent domain. It would be better to have multiple IP addresses registered to avoid single WAN link failure.

When FortiWAN receives a DNS query, it replies with a public IP assigned to one of the WAN links based on the settings of the answering policies. Therefore, subsequent requests to server will be sent to a public IP of the WAN link based on FortiWAN’s previous response. The policies are based on weight for each WAN link and are definable. Multihoming is also capable of automatically detecting the best links by “Optimum Route”, and if WAN link failure occurs, the public IP assigned to that failed link will not be returned even though the servers are still reachable via other links.

FortiWAN offers two options for Multihoming: Non Relay Mode and Relay Mode. The details of will be explained in this section.

The section explains how to configure Multihoming. First, check the box to enable Multihoming in “Enable Multihoming”. Multihoming supports Backup mechanism. To enable this function, check “Enable Backup” and enter the IP addresses of the backup server.

FortiWAN provides mechanisms to record, notify and analysis on events refer to the Multihoming service, see “Log”, “Statistics: Traffic”, “Statistics: Bandwidth” and “Reports”.

Non-Relay Mode

To enable Multihoming in non-relay mode, go to Service > Multihoming on the Web UI, check the box Enable Multihoming, and uncheck the box Enable Relay. FortiWAN will performs DNS analysis on local host if the relay mode is disabled. It contains three blocks to get non-relay mode Multihoming configured: Global Settings, Policy Settings and Domain Name Settings.

Global Settings: IPv4/IPv6 PTR Record

PTR (Pointer Record) is used to resolve the IPv4/IPv6 address to a domain or hostname.

Tunnel Routing

Tunneling is a technique to perform data transmission for a foreign protocol over a incompatible network; such as running IPv6 over IPv4, and the transmission of data for use within a private, corporate network through a public network. Tunneling is done by encapsulating and decapsulating data and information of the particular protocol within the incompatible transmission units symmetrically.

Traditional tunneling is established over single WAN link which is a lack of load balancing and fault tolerance. FortiWAN’s Tunnel Routing (TR) is a technique that builds a special connection between two FortiWAN units to deliver link aggregation and fault tolerance over multiple WAN links ideally tailored for multinational intranet systems. Different to Auto Routing distributing sessions over WAN links, Tunnel Routing breaks further a session down to packets over multiple WAN links and allows data to be prioritized during transfer while boosting the performance of critical services such as VPN and live video streaming while avoiding delays and data loss.

Basically, FortiWAN’s Tunnel Routing implies routing packets of a session over tunnels (WAN links), which contains the two elements – Tunnels and Routing.

GRE Tunnel

FortiWAN’s Tunnel Routing sets up proprietary tunnels between symmetric FortiWAN sites (local and remote) with GRE (Generic Routing Encapsulation) protocol. GRE (Generic Routing Encapsulation) Protocol packs the Payload (Original Packet) with Delivery Header and GRE Encapsulation Header. Physically, a point-to-point GRE tunnel for Tunnel Routing is the transimission of GRE packets via a pair of WAN links predefined on the symmetric FortiWAN sites (a WAN link on the local FortiWAN, and another one on the remote FortiWAN) (See “Tunnel Group” and “Group Tunnel” in “Tunnel Routing – Setting”).

Routing

With the multiple WAN links on each FortiWAN, Tunnel Routing distributes (routes) GRE packets of a session over the GRE tunnels (a tunnel group) according the balancing algorithms and tunnel status detection. This is what the load balancing and fault tolerance Tunnel Routing provides for tunneling. Moreover, with proper policy setting, Tunnel Routing can route GRE packets over multiple sites (more than two sites) without full-mesh connections between the sites (See “Default Rule”, “Routing Rule” and “Persistent Rules” in “How to set up routing rules for Tunnel Routing”). Briefly, it performs routing of GRE packets over multiple tunnels and multiple sites.

Next we introduce Tunnel Routing in the following topics:

How the Tunnel Routing Works

Tunnel Routing – Setting

How to set up routing rules for Tunnel Routing

Tunnel Routing – Benchmark

Scenarios

How the Tunnel Routing Works

Here is an example to explain the processes that how Tunnel Routing delivers packets to remote private internal network via Internet. Here are two FortiWAN sites (FWN-A and FWN-B) connected to Internet with two WAN links respectively. Two private LAN networks: 192.168.10.0/255.255.255.0 and 192.168.20.0/255.255.255.0 are connected to FWN-A and FWN-B respectively. Now host 192.168.10.100 would like to communicate with host 192.168.20.100 which is located at remote private LAN. Here are the steps:

1. Host 19.168.10.100 sends the first original packet to FWN-A, source IP and destination IP of the packet are indicated as 192.168.10.100 and 192.168.20.100.
2. FWN-A’s Tunnel Routing takes charge of transferring the packet because it matches a tunnel routing rule (A routing rule is predefined for packets from 192.168.10.0/255.255.255.0 to 192.168.20.0/255.255.255.0).
3. According the specified balancing algorithm (determining a WAN link for transferring), FWN-A encapsulates the original packet with GRE and Delivery headers which the source IP and destination IP are indicated as public addresses 1.1.1.1 (FWN-A’s WAN 1) and 3.3.3.3 (FWN-B’s WAN 1) respectively.
4. The GRE packet is then transferred via Tunnel 1 (from FWN-A’s WAN 1 to FWN-B’s WAN 1 via Internet).
5. FWN-B receives this GRE packet and decapsulates it to recover the original packet.
6. The original packet then is forwarded to host 192.168.20.100 in the private LAN network.
7. The subsequent packets (for example the packet 2 in the figure below) of the session from host 192.168.10.100 are transferred in the same way except the different tunnels that balancing algorithm determines.

After the basic concept how Tunnel Routing transfers packets, several topics related to Tunnel Routing are explained in detail.

Priority over Auto Routing and NAT

Tunnel Routing rules are in higher priority than Auto Routing rules and NAT rules for FortiWAN matching packets with. Predefine a Tunnel Routing rule, a Auto Routing rule (See “Auto Routing”) and a NAT rule (See “NAT”) with the same source and destination, packets that are indicated the source and destination will be first matched to the Tunnel Routing rule and transferred by Tunnel Routing, without be processed by FortiWAN’s Auto Routing and NAT.

Healthy detection for tunnels

Tunnel Routing maintains a unique mechanism of healthy detection for tunnels, which is different from FortiWAN’s WLHD (See “WAN Link Health Detection”). Symmetric FortiWAN sites continue sending GRE encapsulated detection packets to each other via the defined tunnels. The detection receiver on each FortiWAN site decides the status of a tunnel (OK or Fails) by monitoring if the detection packets arrive continuously. Tunnel Routing’s balancing algorithms distribute packets only over those healthy tunnels, so that the network connection and the data transfer reliability are guaranteed. Tunnel Routing’s healthy detection contains the whole connection between two FortiWAN sites (from the WAN link one side to the WAN link another side via Internet), while WLHD only detects the status of connections to Internet. Therefore, the two mechanisms might show different detection result. For example, the Web UI reports a WAN link is OK but a tunnel established with the WAN link is failed. This might be the failed WAN link on the opposite site of the tunnel. For another example, the Web UI reports a WAN link is failed but a tunnel established with the WAN link is OK. This might because a incorrect configuration to WLHD results in incorrect detection.

Dynamic IP addresses and NAT pass through

FortiWAN’s Tunnel Routing supports dynamic IP addresses and NAT pass through. Only one static public IP address (No NAT employed to the static IP address) is required for tunnel routing deployment between the symmetric FortiWAN sites. A negotiation will be dynamically performed via the only one static public IP address to synchronize the dynamic IP addresses and the IP addresses of NAT device to each other. Therefore, changes on dynamic IP addresses or IP addresses NAT device causes no damage to tunnel connections. Note that NAT pass through for Tunnel Routing here is not the NAT function of FortiWAN, FortiWAN will never perform NAT translation for tunnel packets. The NAT pass through here is for the application that another NAT device in front of FortiWAN. Usually, this happens when a ISP provides WAN links with private IP addresses and does NAT translation for the private WAN links on the ISP side.

Tunnel Routing – Setting

There are two major steps to set up Tunnel Routing, define the association of tunnels (see the tables: Basic Setting and Tunnel Group) and set up the routing rules (see the tables: Default Rules, Routing Rules and Persistent Rules). Tunnel Routing works in symmetric FortiWAN sites, when the unit we are talking about or configuring to is called local host (or local site), the opposite unit is then called remote host (or remote site).

Basic Setting

The basic settings are located here: enabling or disabling Tunnel Route logging, define names and entering tunnel routing activation key (if the encryption function is enabled for a tunnel group).

Short video answer to a question a user sent me about the best ways to block internet traffic for specific machines and devices.