FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
fwilliams
Staff
Staff
Article Id 230181
Description This article describes the logic/process used by FortiOS 7 to determine which IP address to use or set as a gateway for IPSec VPN tunnels in SD-WAN.
Scope FortiGate v7.0 and above.
Solution

Topology: HUB & Spoke.

 

fwilliams_0-1668705909328.png

 

Before FortiOS 7.0.1, it was possible to manually set what gateway to use by SD-WAN members that are VPN tunnels.

However, starting from v7.0.1, this is no longer the case.

It is possible to set it in 7.0.0 GA, but it’s not supposed to be so and was corrected in 7.0.1 GA upward.

 

Since implementing SD-WANover IPSec VPN is becoming more popular, it is important to understand how the gateway IP is set since this affects SLA health check (the kernel route uses SD-WANgateway for SLA check). Also, it can cause confusion if the admin is not aware of this logic and checking his FortiGate routing table, it started seeing IP(s) not configured anywhere in the network, being used as a gateway (for example, x.x.x.x via 10.0.0.1 – this will be explained later).

To demonstrate this logic, HUB & Spoke topology is used, with two tunnels to HUB via two ISPs (L1 & L2 on our network diagram).

The HUB has only one ISP in this study.

After configuring the VPN, the tunnel interfaces were added into SD-WAN zone called IPSec VPN.

It is possible to see how gateways are set on each.

 

fwilliams_1-1668705959240.png

 

VPN interfaces in SD-WAN obtained its gateway from what is called 'tunnel-id' in FortiOS 7.0 upward, which is usually the remote IP configured during IPSec VPN configuration (in this article, the remote IP on Spoke VPNs is 24.200.200.200). 

Note that another rule applies when several tunnels (two or more) terminate on the same IP on the HUB, like in dynamic VPN’s (set type dynamic) – It will be explained later.

 

fwilliams_2-1668705983172.png

 

Remote IP is used to populate tunnel-id in cases where one VPN terminated on one remote IP, or for the first VPN tunnel to connect to a dynamic VPN. 

Others after the first, if there is more than one IPSec tunnel terminating on the same destination IP (remote IP), just like we have in this article, another rule comes to play: FortiOS uses or assigns the first available IP from a dummy IP range of 10.0.0.0/8.

The first assignment from this IP range is usually 10.0.0.1, after .2, and so on.

 

In this case, both tunnels:  SPOKE_L1-HUB_L1 & SPOKE_L2-HUB_L1, terminated on 24.200.200.200, and as IP 24.200.200.200 has been used as tunnel ID (tun_id) for VPN: SPOKE_L1-HUB_L1, FortiOS assigned tun_id of 10.0.0.1 to VPN: SPOKE_L2-HUB_L1.

 

fwilliams_3-1668706009043.pngfwilliams_4-1668706017554.png

 

Checking the FortiGate routing table, 10.0.0.1 has been used as a gateway as stated before.

 

fwilliams_5-1668706035930.png

 

Let’s discuss how tunnel-id is assigned to dynamic tunnels on the HUB.  Since there is no remote IP specified on the dynamic VPN configuration, the IP assigned to the spoke tunnel interface (overlay) is used as tunnel-id.

Or, it can be the IP assigned to the spoke by HUB in cases where 'set mode-cfg enable'  is configured on the HUB tunnel.

 

In this demonstration, we manually assigned IP address to the overlays (Spoke_L1 = 10.100.1.0/24 & Spoke_L2 = 10.100.2.0/24), so the HUB used those spokes’ manually assigned IP as tunnel-id (this IP is communicated to the HUB during IKE negotiation).

 

SPOKE_L1:

 

fwilliams_6-1668706058230.png

 

SPOKE_L2:

 

fwilliams_7-1668706069380.png
Contributors