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.