| Description | This article describes the misordering of the address member configured in 'dst-name' in IPsec phase 2 in the secondary as the cause of the phase 2 tunnel status being down in the secondary. |
| Scope | FortiGate. |
| Solution |
The issue is phase 2 status of IPsec tunnels is displayed as down in the secondary.
First, verify if both FortiGates units are synchronized by following the troubleshooting procedures in article below.
If the FortiGates are already 'in-sync', proceed to check by the procedure below.
Normally, if the FortiGates are synchronized, the primary sends an ESP sequence update to the secondary every 5 minutes. When the secondary receives an ESP sequence update, if IPSec SA is not found, the secondary will send query info to the primary, and the primary will synchronize the IPSec again. Wait for 5 minutes and check by the command 'diagnose vpn tunnel list' to see if the IPsec SA can be synchronized to the secondary.
If the IPsec phase 2 status of the tunnel is still down in the secondary, check if the order of the address members in 'dst-name' used in phase 2 is configured in the same order. Differences in the ordering of the address members configured can result in such issues.
For example: Primary unit shows 'SA' and ordering of 'dst' as 10.11.0.0/16, 10.22.0.0/16, 10.33.0.0/16.
name=tunnel-A ver=1 serial=1 10.21.0.1:0->10.21.0.2:0 nexthop=10.21.0.2 tun_id=10.21.0.2 tun_id6=::10.21.0.2 dst_mtu=1500 dpd-link=on weight=1
bound_if=51 real_if=51 lgwy=static/1 tun=intf mode=auto/1 encap=none/552 options[0228]=npu frag-rfc run_state=0 role=sync-primary accept_traffic=1 overlay_id=0
proxyid_num=1 child_num=0 refcnt=4 ilast=0 olast=0 ad=/0 stat: rxp=5904043409 txp=4931735420 rxb=7315007593944 txb=3417321419337 dpd: mode=on-demand on=1 idle=5000ms retry=2 count=0 seqno=0 natt: mode=none draft=0 interval=0 remote_port=0 fec: egress=0 ingress=0 proxyid=tunnel-A proto=0 sa=1 ref=166 serial=2 auto-negotiate src: 0:10.30.0.0-10.30.127.255:0 dst: 0:10.11.0.0-10.11.255.255:0 0:10.22.0.0-10.22.255.255:0 0:10.33.0.0-10.33.255.255:0 SA: ref=6 options=18227 type=00 soft=0 mtu=1422 expire=1947/0B replaywin=2048 <-- 'SA' exists in the primary. seqno=2011d8f esn=0 replaywin_lastseq=025e747c qat=0 rekey=0 hash_search_len=1 life: type=01 bytes=0/0 timeout=42898/43200 ... run_tally=0
But in the Secondary unit, no 'SA' is displayed, and the ordering of 'dst' is 10.22.0.0/16, 10.11.0.0/16, 10.33.0.0/16.
name=tunnel-A ver=1 serial=1 10.21.0.1:0->10.21.0.2:0 nexthop=10.21.0.2 tun_id=10.21.0.2 tun_id6=::10.21.0.2 dst_mtu=1500 dpd-link=on weight= 1 bound_if=51 real_if=51 lgwy=static/1 tun=intf mode=auto/1 encap=none/552 options[0228]=npu frag-rfc run_state=0 role=standby accept_traffic=0 overlay_id=0
proxyid_num=1 child_num=0 refcnt=4 ilast=5341052 olast=5341053 ad=/0 stat: rxp=266831 txp=189879 rxb=352366472 txb=107511597 dpd: mode=on-demand on=1 idle=5000ms retry=2 count=0 seqno=0 natt: mode=none draft=0 interval=0 remote_port=0 fec: egress=0 ingress=0 proxyid=tunnel-A proto=0 sa=0 ref=2 serial=2 auto-negotiate src: 0:10.30.0.0-10.30.127.255:0 dst: 0:10.22.0.0-10.22.255.255:0 0:10.11.0.0-10.11.255.255:0 0:10.33.0.0-10.33.255.255:0 run_tally=0 <---- Also no 'SA' exists in the secondary unit.
The output of the 'diagnose vpn tunnel list' above of Primary and Secondary shows that the ordering of the 'dst' is different, which results in the IPsec phase 2 status of the secondary being down.
Verify the configuration of both primary and secondary and correct the ordering. After the correction, the IPsec phase 2 status of the secondary unit should be up.
config vpn ipsec phase2-interface edit "tunnel-A" set phase1name "tunnel-A" set proposal aes256-sha384 set dhgrp 21 set auto-negotiate enable set src-addr-type name set dst-addr-type name set src-name "IP_ADDR_LOCAL" set dst-name "IP_ADDR_REMOTE" next
config firewall address edit "Network_A" set allow-routing enable set subnet 10.11.0.0 255.255.0.0 next edit "Network_B" set allow-routing enable set subnet 10.22.0.0 255.255.0.0 next edit "Network_C" set allow-routing enable set subnet 10.33.0.0 255.255.0.0 next
Primary:
set allow-routing enable
Secondary:
set allow-routing enable
Besides comparing the ordering of 'dst' in the output of 'diagnose vpn tunnel list', the output of the debug IKE command below should also help to identify the ordering of address members.
diagnose debug enable diagnose debug console timestamp enable diagnose debug application ike 127 diagnose debug duration 10
Collect for 10 minutes on primary and secondary.
For example: The order received from the primary:
2025-03-10 09:31:21.468290 ike 0:tunnel-A:tunnel-A: HA add IPsec SA fb2000aa/30000bbb seq 1000292a 18227 2025-03-10 09:31:21.468328 ike 0:tunnel-A:tunnel-A: src 0 4 0:10.30.0.0/255.255.128.0:0 2025-03-10 09:31:21.468354 ike 0:tunnel-A:tunnel-A: dst 0 4 0:10.11.0.0/255.255.0.0:0 2025-03-10 09:31:21.468598 ike 0:tunnel-A:tunnel-A: dst 1 4 0:10.22.0.0/255.255.0.0:0 2025-03-10 09:31:21.468672 ike 0:tunnel-A:tunnel-A: dst 12 4 0:10.33.0.0/255.255.0.0:0 2025-03-10 09:31:21.469515 ike 0:tunnel-A:tunnel-A: failed to add IPsec SA: Invalid argument
Related articles: |
