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.
iskandar_lie
Staff
Staff
Article Id 245084
Description

 

This article describes how to implement IPsec Backup Tunnel.

 

Scope

 

FortiGate.

 

Solution

 

Simple topology:

 

iskandar_lie_0-1675804245901.png

 

Scenario:

1) It is necessary to create a IPsec backup tunnel for redundancy purposes: only one tunnel will be active at one time.

2) There are 2 ISPs/uplinks setup to reach the IPsec partner .

 

Refer to this KB article to create IPsec site to site:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-configure-VPN-Site-to-Site-between/...

 

ike2: The primary tunnel.

ike2_backup1: The backup tunnel.

port3: Interface to user network.

 

Both IPsec tunnels will be up at the same time.

 

iskandar_lie_1-1675804280305.png

 

In order to avoid asymmetric routing:

It is necessary to make sure that both sides will have to agree on which tunnel is primary and which tunnel is backup. Make sure that every time FGT1 sends traffic via the primary tunnel to FGT2, FGT2 will reply to the traffic via the primary tunnel too, and vice versa.

 

Create a simple static route where a higher distance on the backup tunnel has been put so that the backup tunnel will become an active route whenever the primary tunnel is down. 

 

A similar static route is also applied on FGT2:

 

FGT1 # show  router static

config router static

    edit 2

        set device "ike2"    --> default distance is 10 

        set comment "VPN: ike2 (Created by VPN wizard)"

        set dstaddr "ike2_remote"

    next

    edit 3

        set distance 254

        set comment "VPN: ike2 (Created by VPN wizard)"

        set blackhole enable

        set dstaddr "ike2_remote"

    next

    edit 8

        set distance 15   --> higher distance for backup tunnel  

        set device "ike2_backup1"

        set comment "VPN: ike2_backup1 (Created by VPN wizard)"

        set dstaddr "ike2_backup1_remote"

    next

    edit 9

        set distance 254

        set comment "VPN: ike2_backup1 (Created by VPN wizard)"

        set blackhole enable

        set dstaddr "ike2_backup1_remote"

    next

end

 

Simulation scenario:

1) Primary tunnel is being used.

 

iskandar_lie_2-1675804307337.png

 

FGT1 # get router info routing-table details 172.16.100.2

Routing table for VRF=0
Routing entry for 0.0.0.0/0
Known via "static", distance 10, metric 0, best
* 192.168.100.2, via ike2distance 0    <----- Ike2 is being used.

Routing entry for 0.0.0.0/0
Known via "static", distance 254, metric 0
directly connected, Null distance 0

Routing entry for 0.0.0.0/0
Known via "static", distance 15, metric 0
directly connected, ike2_backup1 distance 0

 

FGT1 # diagnose sniffer packet any "host 172.16.100.2 and icmp" 4

Using Original Sniffing Mode

interfaces=[any]

filters=[host 172.16.100.2 and icmp]

16.798599 port3 in 192.168.91.2 -> 172.16.100.2: icmp: echo request

16.798622 ike2 out 192.168.91.2 -> 172.16.100.2: icmp: echo request

16.799600 ike2 in 172.16.100.2 -> 192.168.91.2: icmp: echo reply

16.799623 port3 out 172.16.100.2 -> 192.168.91.2: icmp: echo reply

 

2) Primary tunnel is down, therefore the backup tunnel is now being used.

 

iskandar_lie_3-1675804328057.png

 

FGT1 # get router info routing-table details 172.16.100.2

Routing table for VRF=0
Routing entry for 0.0.0.0/0
Known via "static", distance 10, metric 0
192.168.100.2, via ike2 inactive distance 0  <----- primary tunnel is down.

Routing entry for 0.0.0.0/0
Known via "static", distance 254, metric 0
directly connected, Null distance 0

Routing entry for 0.0.0.0/0
Known via "static", distance 15, metric 0, best   
* directly connected, ike2_backup1 distance 0    --> ike2_backup1 is now being used 

 

FGT1 # diagnose sniffer packet any "host 172.16.100.2 and icmp" 4

Using Original Sniffing Mode

interfaces=[any]

filters=[host 172.16.100.2 and icmp]

1.577358 port3 in 192.168.91.2 -> 172.16.100.2: icmp: echo request

1.577380 ike2_backup1 out 192.168.91.2 -> 172.16.100.2: icmp: echo request

1.578165 ike2_backup1 in 172.16.100.2 -> 192.168.91.2: icmp: echo reply

1.578185 port3 out 172.16.100.2 -> 192.168.91.2: icmp: echo reply

 

3) Primary tunnel is now recovered.

 

iskandar_lie_4-1675804351268.png

 

FGT1 # diagnose sniffer packet any "host 172.16.100.2 and icmp" 4

Using Original Sniffing Mode

interfaces=[any]

filters=[host 172.16.100.2 and icmp]

16.798599 port3 in 192.168.91.2 -> 172.16.100.2: icmp: echo request

16.798622 ike2 out 192.168.91.2 -> 172.16.100.2: icmp: echo request

16.799600 ike2 in 172.16.100.2 -> 192.168.91.2: icmp: echo reply

16.799623 port3 out 172.16.100.2 -> 192.168.91.2: icmp: echo reply

 

Conclusion:

- It is possible to setup 2 or more VPN tunnels on a pair of FortiGate, although there is the same phase2 selectors.

- It is impossible to create more than 1 VPN tunnel from 1 underlay physical interface to the same remote-ip address.  

 

 *Note: IPsec config and CLI status from FGT1 and FGT2 are attached to this article.

 

Related documents:

https://docs.fortinet.com/document/fortigate/6.2.12/cookbook/432685/manual-redundant-vpn-configurati...

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configure-automation-backup-over-IPsec-tun...

https://community.fortinet.com/t5/FortiGate/Technical-Tip-SD-WAN-primary-and-backup-ipsec-tunnel-Sce...