FortiWAN WAN Link Health Detection

WAN Link Health Detection

[WAN Link Health Detection] offers you insight into the health status of WAN links. It allows you to set up specific health detection criteria against each individual WAN link in network of multiple links. FortiWAN detects the connection status of the WAN link by sending out ICMP and TCP packets to targets, and determines the connection quality with data that reports back. [WAN Link Detection] lists a few fields to fulfill. Concerning about detection packets flooding, FortiWAN determines a WAN link alive without sending detection packets if inbound traffic on the WAN link is detected. The ICMP and TCP detection packets are sent only if no inbound traffic is detected.

For a single detection via ICMP / TCP packets, FortiWAN sends a ICMP or TCP packet (defineded in “Detection Protocol”) individually to multiple targets (defined in “Ping List / TCP Connect List” and “Number of Hosts Picked out per Detection”) via a WAN link (defined in “WAN Link”). FortiWAN determines the WAN link alive if receiving response from at least one of those targets in a time period (defined in “Detection timeout in milliseconds”), otherwise this detection is consider failed (FortiWAN will not judge whether a WAN link is down by just one detection failure). No matter whether a single detection succeed, FortiWAN continues the detection after seconds (defined in “Detection Period in Second”). The WAN link is determined as down only if multiple detections fail continually (defined in “Number of Retries”). WAN link health detection monitors the WAN links status which FortiWAN’s Summary, Auto Routing, Multihoming and Statistics will refer to.

Ignore Inbound Traffic Enable [Ignore Inbound Traffic], FortiWAN will determine WAN link status only by sending ICMP and TCP packets to targets, regardless of inbound traffic on the WAN link. Disable [Ignore Inbound Traffic], FortiWAN monitors WAN links status via the mixture of inbound traffic and ICMP / TCP packets.
Detection timeout in milliseconds This indicates the timeout period for every single detection in milliseconds. If no response packets are detected during this period, the system will consider the detection failed.
WAN Link The WAN link to be configured health detection criteria to. Configure the WAN links individually by selecting them from the list.

 

WAN Link Health Detection

Detection Protocol Two protocols used to perform WAN link detection are available: ICMP and TCP.
Detection period, in seconds The time interval between ICMP or TCP packets sending for detection. The unit is second. A shorter interval configuration can detect connection condition earlier, but it consumes more bandwidth resource.
Number of hosts picked per detection The number of hosts that is picked out from Ping List or TCP Connection List for detection. When FortiWAN starts checking the link health, it will send out ICMP and TCP packets to the IP address of the hosts that has been picked out. Detection will not be performed if setting the value to zero.
Number of retries The number of times FortiWAN retries if a detection being indicated failed. Once all the retries in the number of times fail, FortiWAN claims the WAN connection fails.
Number of successful detection The number of continuously successful detections that is required for declaring a WAN link indeed available.

If this field is set to 5 and detection period is set to 3 seconds, it will require at least 15 seconds to detect an available WAN link. If Ignore Inbound Traffic is disabled, inbound traffic being detected on a WAN link will be counted to one successful detection.

In ICMP packet detection, the optional list is:

Ping List: Lists the data of hosts (Destination IP: IPv4 or IPv6) available to ping detection. Each detection sends one ping packet to the IP address of a host that has been picked out randomly from the list. The TTL (Time to Live) of the ping packet is determined by Hops and generally defined as “3”. FortiWAN takes the TTL expired message as a legal response for a ICMP detection, even the detection packet is not delivered to the destination.

Note that always employ real external IP addresses (hosts in Internet) for the Ping List, gateway and hosts in near WAN are not appropriate destinations for the detection.

In TCP packet detection, the optional list is:

TCP Connect List: Lists the data of hosts (Destination IP: IPv4 or IPv6) available to TCP connect detection. Each detection performs TCP connect test for a host that has been picked out randomly from the list, and assigns a value to the TCP port.

A WAN link is determined alive if:

l A single detection succeeds. l Value of field “Number of hosts picked per detection” is sat to zero or “Ping List / TCP Connect List” is leaved blank. l “Ignore Inbound Traffic” is disable and inbound traffic on the WAN link is detected.

A WAN link is determined down if:

  • All the detection retries fail. l No carrier signal detected (failures on cables or physical ports).

WAN Link Health Detection

  • The WAN link is disable or a sleeping backup line. l A PPPoE or DHCP WAN link which fails to get a dynamic IP address.

FortiWAN provides statistics to the WAN Link Health Detection service, see “Statistics: WAN Link Health Detection”.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Virtual Server & Server Load Balancing

Virtual Server & Server Load Balancing

Virtual Server is a method for single gateway machine to act as multiple servers while the real servers sit inside corporate network to process requests passed in from the gateway machine. Inbound traffic does not have to know where the real servers are, or whether there are just one or many servers. This method prevents direct access by users and therefore increases security and flexibility.

FortiWAN has built in virtual server and is capable of supporting various virtual server mapping methods. For example, different public IP addresses can be mapped to various real servers in LAN or DMZ. Or ports can be mapped to public IP address on different servers.

Virtual server are configured by designating and adjusting virtual server rules. Each rule specifies a mapping condition. It maps WAN IP address and a service (port or ports) to an internal server IP. The order of virtual server rules is like any other rule tables in FortiWAN as it also uses the “first match scheme”, viz. the first rule of request matched is the rule to take effect.

For example, a public IP address 211.21.48.196 and wants a web server on 192.168.123.16 to handle all the web page requests coming to this public IP address. To do this, a virtual server rule must be created with 211.21.48.196 to be its WAN IP, 192.168.123.16 to be its Server IP, and HTTP(80) to be its Service.

Virtual Server makes intranet (LAN) servers accessible for the internet (WAN). The private IP addresses assigned to intranet servers will become invisible to the external environment, making services accessible for users outside the network. Then FortiWAN is available to redirect these external requests to the servers in LAN or DMZ. Whenever an external request arrives, FortiWAN will consult the Virtual Server table and redirect the packet to the corresponding server in LAN or DMZ. The rules of Virtual Server tables are prioritized top down. If one rule is similar to another in the table, only the higher ranked one will be applied, and the rest will be ignored. In addition, Virtual Server enables to balance load on multiple servers, which is to distribute traffic over a group of servers (server cluster), making services highly accessible.

 

Virtual Server & Server Load Balancing

FortiWAN provides mechanisms to record, notify and analysis on events refer to the Virtual Server service, see “Log”, “Statistics: Virtual Server Status” and “Report: Virtual Server”.

IPv4 Virtual Server

E   Check the box to enable the rule
When   Options: Busy hour, Idle hour, and All-Time (See “Busyhour Settings”).
WAN IP   For external internet users, the virtual server is presented as a public IP (IPv4) on WAN port. This WAN IP is the “visible” IP for the virtual server in external environment. Select a public IP, and in “Routing Mode”, either enter the IP manually or select the IP obtained from WAN link; In “Bridge Mode One Static IP”, insert WAN IP and the public IP assigned by ISP; Or choose “dynamic IP at WAN#”, if WAN type is none of the above.
Service   The type of TCP/UDP service to be matched. Select matching criteria from publicly known service types, or choose port number from TCP/UDP packets. To specify a range of port numbers, type starting port number plus hyphen “-“ and ending port number, e.g. “TCP@123-

234” (See “Using the web UI”).

Algorithm   Algorithms for server load balancing (See Load Balancing Algorithms)
  l Round-Robin
  l By Connection
  l By Response Time
  l Hash
Keep Session   Check the box to keep session after a connection has been established. If the session is to be stored, then enter a time period. Default value is 30s
Server Pool l Server IP: The real IP (IPv4) of the server, most likely in LAN or DMZ.
  l Detect: Choose the protocol for detecting server status: ICMP, TCP@, and No-Detect. Note:

port number must be specified for “TCP@”.

  l Service: The type of TCP/UDP service to be matched. Select matching criteria from publicly known service types (e.g. FTP), or choose port number from TCP/UDP packet. To specify a range of port numbers, enter starting port number plus hyphen “-“ and ending port number, e.g.

“TCP@123-234” (See “Using the web UI”).

  l Weight: Weight determines which server responds to the incoming requests. The higher the weight, the greater the chance is for the corresponding server to be used.
L   Check to enable logging: Whenever the rule is matched, system will record the event to log file.

IPv6 Virtual Server

E Check the box to enable the rule.
When Options: Busy hour, Idle hour, and All-Time (See “Busyhour Settings”).
WAN IP For external internet users, the virtual server is presented as a public IP (IPv6) on WAN port. This WAN IP is the “visible” IP for the virtual server in external environment. Select a public IP, and in “Routing Mode”, either enter the IP manually or select the IP obtained from WAN link; In “Bridge Mode One Static IP”, insert WAN IP and the public IP assigned by ISP; Or choose “dynamic IP at WAN#”, if WAN type is none of the above.
Service The type of TCP/UDP service to be matched. Select matching criteria from publicly known service types, or choose port number from TCP/UDP packets. To specify a range of port numbers, type starting port number plus hyphen “-“ and ending port number, e.g. “TCP@123-

234” (See “Using the web UI”).

Server IP The real IP (IPv6) of the server, most likely in LAN or DMZ.
L Check to enable logging: Whenever the rule is matched, system will record the event to log file.

Example 1

The settings for virtual servers look like:

  • Assign IP address 211.21.48.194 to WAN1. Refer to [System] -> [Network Settings] -> [WAN Settings] for more regarding WAN IP configurations. l Assign IP address 211.21.33.186 to WAN2.

Virtual Server & Server Load Balancing

  • Forward all HTTP requests (port 80) through WAN1 or WAN2 to the two HTTP servers 192.168.0.100 and 192.168.0.101 in LAN.
  • Forward all FTP requests (port 21) through WAN1 or WAN2 to two FTP servers 192.168.0.200 and 192.168.0.201 in LAN.
  • Assign 211.21.48.195 and 211.21.33.189 to WAN 1 and WAN2. Forward all requests to 211.21.48.195 or 211.21.33.189 to two SMTP servers 192.168.0.200 and 192.168.0.201 in LAN. l Forward all requests from 211.21.48.197 to 192.168.0.15 in LAN.

Note:

  1. FortiWAN can auto-detect both active and passive FTP servers.
  2. All public IPs must be assigned to WAN 1. To configure these IPs, go to “IP(s) on Localhost of the Basic Subnet” table in [System] -> [Network Settings] -> [WAN Settings] -> [WAN Link 1].
  3. 21.48.197 does not belong to any physical host, and it must be assigned to WAN port.

Virtual server table for the above settings:

WAN IP Service Server Pool

Server IP

Detect Service Weight
211.21.48.194

211.21.33.186

211.21.48.194

211.21.33.186

211.21.48.195

211.21.33.189

HTTP (80)

HTTP (80)

FTP (21)

FTP (21)

SMTP (25)

SMTP (25)

192.168.0.100 ICMP HTTP (80) 1
192.168.0.101 TCP@80 HTTP (80) 1
192.168.0.100 ICMP HTTP (80) 1
192.168.0.101 TCP@80 HTTP (80) 1
192.168.0.200 ICMP FTP (21) 1
192.168.0.201 TCP@21 FTP (21) 1
192.168.0.200 ICMP FTP (21) 1
192.168.0.201 TCP@21 FTP (21) 1
192.168.0.200 ICMP SMTP (25) 1
192.168.0.201 TCP@25 SMTP (25) 1
192.168.0.200 ICMP SMTP (25) 1
192.168.0.201 TCP@25 SMTP (25) 1
211.21.48.197 Any 192.168.0.15 ICMP Any 1

Example 2

The settings for virtual servers look like:

  • Forward all the TCP port 1999 requests established between external network and public IP 211.21.48.194 to FTP Server@ TCP port 1999 at 192.168.0.100 in LAN.
  • Note: Due to the nature of ftp protocol, in port style ftp-data connection, when ftp-control is used in port 1999, port 1998 will be taken by ftp-data.
  • Enable external users to access WAN IP 211.21.33.186, and connect PcAnywhere to .LAN hosts. l Note: PcAnywhere uses TCP port 5631 and UDP port 5632. Refer to PcAnywhere software manual for more details.
  • Enable external users to access WAN IP 211.21.48.194, and forward packets of TCP/UDP range 2000-3000 to host 192.168.0.15.

Note: Port range redirecting is supported as well.

Virtual server table for the settings above:

WAN IP Service Server Pool

Server IP

Detect Service Weight
211.21.48.194 TCP@1999 192.168.0.100 ICMP TCP@1999 1
192.168.0.101 TCP@1999 TCP@1999 1

WAN Link Health Detection

WAN IP Service Server Pool

Server IP

Detect Service Weight
211.21.33.186 TCP@5631 192.168.0.15 ICMP TCP@5631  
211.21.33.186 TCP@5632 192.168.0.15 TCP@5632 TCP@5632  
211.21.48.194 TCP@20003000 192.168.0.15 ICMP TCP@20003000  
211.21.48.194 UDP@20003000 192.168.0.15 ICMP UDP@20003000

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWAN Tunnel Routing – Benchmark

Tunnel Routing – Benchmark

To guarantee a performance aggregation transferring TR packets, FortiWAN requires equal quality for the WAN links employed in a tunnel group. The Benchmark here provides evaluation of WAN link quality for every single tunnel. Tunnels are judged in run trip time, packet loss and bandwidth. It is not suggested to employ a WAN link that is worse than others in a tunnel group.

Tunnel Routing’s Benchmark works as Client/Server mode. Test traffic is sent from the client site to the server site via every single configured tunnel, and then the benchmark results are reported at client site. Two steps to start Tunnel Routing’s Benchmark between two FortiWAN appliances (make sure the Tunnel Routing network is established between the two FortiWANs),

  1. Specify one of the FortiWANs to be the benchmark server.
  2. Start benchmark traffic from the benchmark client, the ForiWAN opposite to the benchmark server.

Start a benchmark server

From the WeB UI, the Tunnel Routing page, all the configured tunnel groups are listed in the Benchmark panel. To start the benchmark server on a FortiWAN for a tunnel group, you need:

  1. Specify the port number on the Test Port field for sending/receiving the testing traffic. Note that the port number on both benchmark sites (Client/Server) must be identical. It will fail to receive testing packets if unequal port numbers are used by the two sites.
  2. Click the button Start Test Server of the tunnel group that you want to test from the list (in Test Client Status block). This button will be switched to Stop Test Server while benchmark server is running; click it to stop the server.

While the benchmark server is running, a message Test server is running. Please do not change to another page or close browser will display and occupy the main page of Web UI. For all the administrator accounts, it become unable to apply new configurations to Tunnel Routing (the Apply button on Web UI becomes ineffective) during benchmark server is running. Web UI will allow apply configurations to other functions during benchmark server is running, but we suggest not to do this since changes to some functions such as Network Setting, Firewall or IPSec might interrupt benchmark server. During benchmark server running, you can switch Web UI main page to other functions, but a message Test server is running. Please stop it first displays when you turn the main page back to Tunnel Routing. This message reminds you the benchmark server is still running, and the Apply button of Tunnel Routing remains ineffective until you stop the server. Note that the benchmark server can work for only one tunnel group anytime; stop the server on one tunnel group to start it for another.

Start testing traffic from the benchmark client

For the symmetric FortiWAN sites of a tunnel routing network, benchmark client, the site that is opposite to the benchmark server, triggers the testing traffic. Similarly, all the configured tunnel groups are listed in Benchmark panel. To start benchmark traffic on the site you need:

  1. Specify the port number on the Test Port field for sending/receiving the test traffic. Note that the port number on both benchmark sites (Client/Server) must be identical. It will fail to receive testing packets if unequal port numbers are used by the two sites.
  2. Click the button Test of the same tunnel group that the opposite benchmark server is working for. You will be direct to a management panel to start benchmark testing. For a disable tunnel group, a error message This group is not enabled
  3. In the testing management panel, you see all the tunnels of the tunnel group listed (IP addresses of the two endpoints of a tunnel), and two test cases provided:
    1. Single tunnel test: Click the Test button of a tunnel, testing traffic will be generated and sent to the opposite (the server side) of the tunnel. All the packets of the testing session will be sent through only the specified tunnel. This will bring out a testing result for evaluating performance of the specified tunnel.
    2. Tunnel group test: Click the Test button of the last item All Tunnels in Group (at the bottom of the table), testing traffic will be generated and sent to the opposite (the server side) of the tunnel group. All the packets of the testing session will be distributed over the tunnels of the tunnel group according to the configured algorithm of the tunnel group. This will bring out a testing result for evaluating performance of the tunnel group.
  4. On the upper right corner of the table, there is a button Test All used to perform every Single Tunnel Testing and the Tunnel Group Testing one by one in a top-down order.
  5. You can click Close to stop and leave the benchmark management panel.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWAN How to set up routing rules for Tunnel Routing

How to set up routing rules for Tunnel Routing

To perform Tunnel Routing, symmetric FortiWAN deployment is a basic requirement. Therefore, symmetric routing rules are also required for two-way data transmission. A routing rule here contains three basic elements that are

What is the traffic to be transferred by Tunnel Routing? Tunnel Routing filter traffic by Source, Destination and Service.

Which Tunnel Group is employed to transfer the traffic? Apply a predefined tunnel group to the specified traffic, then it will be transferred according to the how the tunnel group is defined; the balancing algorithm, the tunnels, the weight, the encryption and DSCP.

What to do if the Tunnel Group fails? A failed tunnel group means all the tunnels defined in the tunnel group are disconnected (detected by Tunnel Routing’s tunnel healthy detection mechanism). Therefore, it is necessary to specify another way for the traffic. Note that as long as one tunnel in a tunnel group remains connected, Tunnel Routing keeps employing the tunnel group for transmission.

Next we introduce the two ways, Routing Rule and Default Rule, to establish the routing rules for Tunnel Routing.

Routing Rules

This is the general way to set routing rules for Tunnel Routing. A routing rule contains the three basic elements above, which evaluates traffic by Source, Destination, Service, (Tunnel) Group and Fail-Over. Note that a routing rule sat on a FortiWAN site is required symmetrically for the opposite FortiWAN site, so that the bidirectional transmission is achieved.

Add Click the Add button to add a new rule.
Source The source of the connection (See “Using the web UI”).

IPv4 Address, IPv4 Range and IPv4 Subnet: To filter out the traffic coming from the specified IPv4 Address, IPv4 Range or IPv4 Subnet. LAN: To filter out the traffic coming from LAN area.

DMZ: To filter out the traffic coming from DMZ area.

Any Address: To filter out the traffic coming from any IP address

Destination The destination of the connection (See “Using the web UI”).

IPv4 Address, IPv4 Range and IPv4 Subnet: To filter out the traffic going to the specified IPv4 Address, IPv4 Range or IPv4 Subnet.

WAN: To filter out the traffic going to WAN area.

Service The TCP/UDP service type to be matched. The default is “Any”. Administrators can select from the publicly known service types (e.g. FTP), or can choose the port number in TCP/UDP packet. To specify a range of port numbers, type starting port number plus hyphen “-” and then end port number. e.g. “TCP@123-234” (See “Using the web UI”).
Group The tunnel group used to transfer the specified traffic (filtered by Source, Destination and Service). The balancing algorithm and tunnels for distributing the traffic are defined in the tunnel group.
Fail-Over This field defines the fail-over policy for situation that all the WAN links (tunnels) of the specified tunnel group in the routing rule fail. Possible options are:

NO-ACTION: Traffic will not be diverted when the tunnel group get failed, and transmission will get failed.

Auto Routing: Traffic will be re-evaluated against Auto Routing’s rules and transferred according to the Auto Routing policies. Transmission gets failed if there is no rule matches.

Tunnel: [Group Name]: All the defined tunnel groups are listed for options. Traffic will be diverted to the specified tunnel group here, however, the diverted traffic will not be diverted again if the beck-up tunnel group is also failed. Note: it takes the same action as “NO-ACTION” if a tunnel group that is the same as what specified in field “Group” is selected as back-up for fail-over here.

If your TR network deployment requires more than 100 TR routing rules, replacing the TR routing rules with TR default rules will be suggested for better performance.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Block Specific Devices From Internet Access

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

 


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWAN Tunnel Routing – Setting

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

Tunnel Route Log Enable or disable logging. FortiWAN provides mechanisms to record, notify and analysis on events refer to the Tunnel Routing service, see “Log”, “Statistics: Tunnel Status”, “Statistics:

Tunnel Traffic”, “Report: TR Status” and “Report: TR Reliability”.

Local Host ID Assign a unique host name for this unit. Tunnels are established between two FortiWAN units. Host ID is used for Tunnel Routing to recognize the units running TR transmission.

Symmetrically, this field is required to the opposite unit.

Key Decide a secret key for tunnel encryption and enter it here, if the encryption function is enabled for a tunnel group. Tunnel Routing encryption employs only one secret key for all tunnel transmissions, therefore, please set the decided key to all the tunnel routing hosts.

This key is used for the data encryption built in Tunnel Routing, not for encryption of IPSec.

For an IPSec protection on Tunnel Routing, please refer to “IPSec”.

Confirm Confirm the key above.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWAN Tunnel Routing

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.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWAN Configurations

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.

TTL Set the TTL for the PTR record. TTL (Time To Live) Specifies the amount of time that the record will stay in cache on systems requesting the record (other resolving nameservers, applications, browsers and etc.).

 

Reverse Lookup Zone Set the reverse lookup zone (domain) of the hosts for the PTR record. Click the add button to create new tables for configuring other zones.

 

 

  Zone Name The reverse lookup zone name. For hosts in IPv4 subnet 1.2.3.0/24

(such as 1.2.3.4, 1.2.3.5 and etc.), the reverse lookup zone for its PTR records is 3.2.1.in-addr.arpa. Thus, this field should be filled in with “3.2.1”. For host with IPv6 2001:470:0:64::2 (/64), the reverse lookup zone is 4.6.0.0.0.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa and this field should be filled in with “4.6.0.0.0.0.0.0.0.7.4.0.1.0.0.2”.

Click Hide Details / Show Details to collapse or expand the SOA configurations of the reverse lookup zone.

 

  SOA SOA (Start of Authority) record of the reverse lookup zone.
Primary Name

Server

The primary name server for the reverse lookup zone or the first name server in the name server list below.
Host Email The responsible party for the reverse lookup zone.
Serial Number A timestamp that changes whenever you update the reverse lookup zone.
Refresh Time The number of seconds before the reverse lookup zone should be refreshed.
Retry Time The number of seconds before a failed refresh should be retried.
Expire Time The upper limit in seconds before the reverse lookup zone is considered no longer authoritative.
Minimum TTL The negative result TTL.
NS1                 NS record. The primary name server for the reverse lookup zone.
NS2                NS record. The secondary name server for the reverse lookup zone.
Entries Set the PTR entries in the reverse lookup zone. Click the add button to create multiple PTRs.
IP Number The last octet of the host IP address for resolving in the reverse lookup zone. For a IPv4 host 1.2.3.4 in the reverse lookup zone

“3.2.1.in-addr.arpa”, this field should be filled in with “4”. For host with IPv6 2001:470:0:64::2 (/64), this field should be filled in with “2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0”.

Host Name The FQDN of the host that that Multihoming will response to the request for resolving IPv4 address 1.2.3.4 or IPv6 address 2001:470:0:64::2, such as “www.example.com”.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!