| Description | This article describes the logic/process, starting with FortiOS v7.0.1, for determining which IP address to use or set as a gateway for IPSec VPN tunnels in SD-WAN. |
| Scope | FortiOS v7.0.1 and above. |
| Solution |
Topology: HUB & Spoke.
Before FortiOS v7.0.1, it was possible to manually set which gateway to use by SD-WAN members, which are VPN tunnels. However, starting with FortiOS v7.0.1, this is no longer the case. It is possible to set it in v7.0.0 GA, but it is not supposed to be so, and was corrected in v7.0.1 GA and onward.
Since implementing SD-WAN over 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 the SD-WAN gateway for SLA check). Also, it can be confusing if the admin is not aware of this logic and starts checking the FortiGate's routing table; it starts 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 the network diagram). The HUB has only one ISP in this study. After configuring the VPN, the tunnel interfaces were added to the SD-WAN zone called IPSec VPN. It is possible to see how gateways are set on each.
VPN interfaces in SD-WAN obtain their gateway from what is called 'tunnel-id' in FortiOS 7.0.1 and onward, 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.
Remote IP is used to populate tunnel-id in cases where one VPN terminates 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 into 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, the next one will be .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.
 
Checking the FortiGate routing table, 10.0.0.1 has been used as a gateway as stated before.
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 the 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 addresses 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 addresses as tunnel-id (this IP is communicated to the HUB during IKE negotiation).
SPOKE_L1:
SPOKE_L2:
Related documents: Technical Tip: IPsec Tunnel ID expected behavior Dedicated tunnel ID for IPsec tunnels |
