Description
This article describes one of the simplest methods to monitor a site-to-site IPsec VPN tunnel.
Scope
FortiGate.
Solution
Many network administrators need redundancy for their site-to-site IPsec VPNs to guarantee operational continuity should the primary tunnel fail.
The above topology is the simplest way to set up redundant site-to-site IPsec VPN.
This article assumes that both the primary and backup tunnels have already been configured, are up, and are passing traffic.
It is necessary to apply identical distances but a higher priority to the secondary route.
For each tunnel, there will be a set of Firewall Policies created by the wizard. They are mandatory for the VPN to work normally.
It is also possible to have only one set of policies, but it will be necessary to create a zone in which the two VPN interfaces are members.
Run the following CLI configuration for the backup tunnel phase1-interface:
config vpn ipsec phase1-interface
edit <Backup-phase1-name>
set monitor <primary's phase1-name>
end
For example:
config vpn ipsec phase1-interface
edit "VPN"
set interface "port1"
set peertype any
set net-device disable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set dpd on-idle
set comments "VPN: VPN (Created by VPN wizard)"
set remote-gw x.x.x.x <-- Remote gateway IP address for the primary.
set psksecret XXX
next
edit "VPN_77_backup"
set interface "port10"
set peertype any
set net-device disable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set dpd on-idle
set comments "VPN: VPN_77_backup (Created by VPN wizard)"
set remote-gw y.y.y.y <-- Remote gateway IP address for the secondary.
set monitor "VPN" <-- Monitor.
set psksecret ENC XXX
next
end
Note:
- Starting firmware version 7.4.1, multiple interface monitoring for IPsec is supported.
config vpn ipsec phase1-interface
edit <Backup-phase1-name>
set monitor <overlay> <overlay> ... <overlay>
set monitor-min <integer>
end
Check the changes apply as a failover for one WAN interface:
Routing table before:
#get router info routing-table all
S* 0.0.0.0/0 [10/0] via 10.191.31.254, port1-
[10/0] via 10.191.47.254, port10, [2/0]
C 10.191.16.0/20 is directly connected, port1
C 10.191.32.0/20 is directly connected, port10
C 172.16.0.0/24 is directly connected, port2
S 172.16.77.0/24 [10/0] is directly connected, VPN
Routing table after:
#get router info routing-table all
S* 0.0.0.0/0 [10/0] via 10.191.47.254, port10, [2/0]
C 10.191.32.0/20 is directly connected, port10
C 172.16.0.0/24 is directly connected, port2
S 172.16.77.0/24 [10/0] is directly connected, VPN_77_backup
Packet sniffers from both FortiGates:
Traffic goes to the primary tunnel and is changed to the secondary tunnel.
Local FortiGate:
#diagnose sniffer packet any "host 172.16.77.88 and icmp" 4 0
…
75.939942 VPN_66 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
75.939958 port2 out 172.16.0.66 -> 172.16.77.88: icmp: echo request
75.940391 port2 in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
75.940401 VPN_66 out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
76.940061 VPN_66 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
76.940079 port2 out 172.16.0.66 -> 172.16.77.88: icmp: echo request
76.940521 port2 in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
76.940532 VPN_66 out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
87.939877 VPN_66_backup in 172.16.0.66 -> 172.16.77.88: icmp: echo request
87.939922 port2 out 172.16.0.66 -> 172.16.77.88: icmp: echo request
87.940754 port2 in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
87.940778 VPN_66_backup out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
88.940118 VPN_66_backup in 172.16.0.66 -> 172.16.77.88: icmp: echo request
88.940140 port2 out 172.16.0.66 -> 172.16.77.88: icmp: echo request
88.940678 port2 in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
88.940689 VPN_66_backup out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
89.940044 VPN_66_backup in 172.16.0.66 -> 172.16.77.88: icmp: echo request
89.940063 port2 out 172.16.0.66 -> 172.16.77.88: icmp: echo request
89.940482 port2 in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
Remote FortiGate:
#diagnose sniffer packet any "host 172.16.77.88 and icmp" 4 0
…
88.935693 VPN in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
88.935707 port2 out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
89.934793 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
89.934805 VPN out 172.16.0.66 -> 172.16.77.88: icmp: echo request
89.935857 VPN in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
89.935872 port2 out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
90.934853 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
91.934692 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
92.934839 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
93.934745 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
94.934805 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
95.938448 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
95.938480 VPN_77_backup out 172.16.0.66 -> 172.16.77.88: icmp: echo request
100.934745 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
100.934762 VPN_77_backup out 172.16.0.66 -> 172.16.77.88: icmp: echo request
100.936048 VPN_77_backup in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
100.936076 port2 out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
101.934821 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
101.934840 VPN_77_backup out 172.16.0.66 -> 172.16.77.88: icmp: echo request
101.935917 VPN_77_backup in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
101.935937 port2 out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
102.934810 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
102.934828 VPN_77_backup out 172.16.0.66 -> 172.16.77.88: icmp: echo request
102.935794 VPN_77_backup in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
After the connection is re-established:
Local FortiGate:
#diagnose sniffer packet any "host 172.16.77.88 and icmp" 4 0
…
30.022251 port2 out 172.16.0.66 -> 172.16.77.88: icmp: echo request
30.022708 port2 in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
30.022712 VPN_66_backup out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
31.022223 VPN_66_backup in 172.16.0.66 -> 172.16.77.88: icmp: echo request
31.022246 port2 out 172.16.0.66 -> 172.16.77.88: icmp: echo request
31.022678 port2 in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
31.022688 VPN_66_backup out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
36.928584 VPN_66 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
36.928628 port2 out 172.16.0.66 -> 172.16.77.88: icmp: echo request
36.929191 port2 in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
36.929216 VPN_66 out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
37.928652 VPN_66 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
Remote FortiGate:
#diagnose sniffer packet any "host 172.16.77.88 and icmp" 4 0
…
27.017152 VPN_77_backup out 172.16.0.66 -> 172.16.77.88: icmp: echo request
27.017909 VPN_77_backup in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
27.017929 port2 out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
28.017187 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
28.017200 VPN_77_backup out 172.16.0.66 -> 172.16.77.88: icmp: echo request
28.017896 VPN_77_backup in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
28.017912 port2 out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
29.017199 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
29.017253 VPN out 172.16.0.66 -> 172.16.77.88: icmp: echo request
33.923459 port2 in 172.16.0.66 -> 172.16.77.88: icmp: echo request
33.923495 VPN out 172.16.0.66 -> 172.16.77.88: icmp: echo request
33.924495 VPN in 172.16.77.88 -> 172.16.0.66: icmp: echo reply
33.924520 port2 out 172.16.77.88 -> 172.16.0.66: icmp: echo reply
To test, use a ping from the Windows CLI:
When it goes down, the traffic route changes to the secondary VPN. When connectivity is restored, the traffic route changes to the primary.
Notes:
- This feature is only available for IPsec VPN and it cannot be used for Dial-UP tunnels.
- IPSEC monitor works differently than a link monitor. In the IPSEC monitor, only one link (tunnel) will remain up at a point. For instance, this example has one monitor set on the secondary tunnel, the secondary tunnel will remain down until the primary goes down.
To remove the monitor tunnel and set the status of both tunnels to 'up', run the following in the CLI:
config vpn ipsec phase1-interface
edit "phase1-tunnel name"
unset monitor
end