Troubleshooting Tip: Shortcut Tunnels Fail to Establish Between Spokes in ADVPN 2.0

[auppal]

Description	This article describes how to troubleshoot when shortcut tunnels cannot be established between spokes configured with ADVPN 2.0 and get an error message in IKE debugs, such as 'found duplicate in ike_check_update_addr_key'.
Scope	FortiGate v7.4.2 and later.
Solution	Prerequisites: ADVPN 2.0 is configured across all the hubs and spokes. End-to-end connectivity between spokes via hubs. In some circumstances, an otherwise valid shortcut may fail to establish a connection between Spoke1 and Spoke2. When the traffic is initiated from 172.16.1.2 towards 172.16.2.2, the Hub will send a SHORTCUT-OFFER to Spoke1: HUB1 # ike V=root:0: shortcut ADVPN_ISP1-1_0:x.x.x.x:0 to ADVPN_ISP2-2_0: x.x.x.x 2:0 for 172.16.1.2->172.16.2.2 0 ike 0 ike_ui_admin_caps_trigger sport 2048, dport 0, proto 1, iif 18 ike V=root:0 send shortcut-offer to ADVPN_ISP1-1_0 ike V=root:0:ADVPN_ISP1-1_0:25106: sending NOTIFY msg ike V=root:0:ADVPN_ISP1-1_0:24692:25106: send informational After receiving SHORTCUT-OFFER, the Spoke1 will then send a SHORTCUT-QUERY towards the HUB1, which is then forwarded to Spoke2: Spoke1 # ike V=root:0:SPK1-1-Hub1-1:94: processing notify type SHORTCUT_OFFER ike V=root:0:SPK1-1-Hub1-1: ikev2_process_shortcut_offer sport 2048, dport 0, proto 1, iif 18 ike V=root:0:SPK1-1-Hub1-1: shortcut-offer 172.16.1.2->172.16.2.2 0 psk 64 ppk 0 ver 2 mode 0, peer-addr x.x.x.x:02025-07-30 19:28:38.143367 ike V=root:0 looking up shortcut by addr 172.16.2.2, resp-name:, name SPK1-1-Hub1-1, peer-addr x.x.x.x:0 2025-07-30 19:28:38.143617 ike V=root:0:SPK1-1-Hub1-1: send shortcut-query xx20687486 fd433xx1cf2ea/0000000000000000 x.x.x.x 172.16.1.2->172.16.2.2 0 psk 64 ttl 32 nat 0 ver 2 mode 0 network-id 11 ike 0:SPK1-1-Hub1-1:94: enc 0F0E0D0C0Bxx08xx040302010F ike 0:SPK1-1-Hub1-1:94: out Hub1 receives the SHORTCUT-QUERY and forwards it: Hub1 # V=root:0:ADVPN_ISP1-1_0:24692: received informational request ike V=root:0:ADVPN_ISP1-1_0:24692: processing notify type SHORTCUT_QUERY ike V=root:0:ADVPN_ISP1-1_0: recv shortcut-query 547994xx87486 fd433c2x Spoke2 receives the SHORTCUT-QUERY: Spoke2 # ike V=root:0:SPK2-2-Hub2-2:61: received informational request ike V=root:0:SPK2-2-Hub2-2:61: processing notify type SHORTCUT_QUERY ike V=root:0:SPK2-2-Hub2-2: recv shortcut-query 54799x0687486 fdxx1cf2ea/0000000000000000 x.x.x.x 172.16.1.2:2048->172.16.2.2:0  0 psk 64 ppk 0 ttl 31 nat 0 ver 2 mode 0 network-id 11 Spoke2 sends a SHORTCUT-REPLY: Spoke2 # ike V=root:0:SPK2-2-Hub2-2: send shortcut-reply 54x9520687486 fd433x/7axa6a81bf66 x.x.x.x to 172.16.1.2 0 psk 64 ppk 0 ver 2 mode 0 network-id 11/22 Hub1 receives the SHORTCUT-REPLY: Hub1 # ike V=root:0:ADVPN_ISP2-2_0: recv shortcut-reply 547x569520687486 fd433c2x/7a8cff8xbf66 x.x.x.x to 172.16.1.2 0 psk 64 ppk 0  ver 2 mode 0 ext-mapping 0.0.0.0:0, network-id 11/22 Spoke1 receives the SHORTCUT-REPLY: Spoke1 # ike V=root:0:SPK1-1-Hub1-1:recv shortcut-reply 5479xx69520687486 fd4xx101cf2ea/7a8cff8x81bf66 18.2.4.2 to 172.16.1.2 0 psk 64 ppk 0 ver 2 mode 0 ext-mapping 18.2.4.2:0, network-id 11/22 Upon receiving SHORTCUT-REPLY, Spoke1 may silently reject it and print the error 'found duplicate in ike_check_update_addr_key': ike V=root:0:SPK1-1-Hub1-1: recv vwl advpn oif response (0x2cd40736) ike V=root:0:SPK1-1-Hub1-1: vwl oif result: port5 ike V=root:0:SPK1-1-Hub1-1: auto-discovery crossover detected ike V=root:0:SPK1-1-Hub1-1: crossover allowed, initialize connection on network_id ike V=root:0 found duplicate in ike_check_update_addr_key 10.10.1.2:0, name SPK1-1-Hub1-1, resp-name SPK2-1-Hub1-1, peer-addr x.x.x.x:0 ike :shrank heap by 163840 bytes If the error 'found duplicate in ike_check_update_addr_key' is seen in the debugs, the spoke believes a duplicate shortcut already exists and will silently drop the new shortcut request. There is a known issue 1130683 that can cause a false positive duplicate shortcut, preventing new shortcut formation. This issue occurs when ADVPN 2.0 is used in conjunction with SD-WAN and may occur on v7.4 and v7.6. The false duplicate issue is resolved in v7.6.4, August 2025 released and v7.4.9, expected late September 2025. Firmware release outlooks are estimates and are subject to change without notice. To confirm the issue, run the following diagnostic commands on the hub and spokes and generate the traffic from one spoke to another: diagnose vpn tunnel list diagnose debug application ike -1 diagnose debug console timestamp enable diagnose debug enable To disable debug after collecting the output:  diagnose debug disable diagnose debug reset If the original spoke receives the shortcut reply but drops it with 'found duplicate in ike_check_update_addr_key', and the spoke has no existing shortcut to the target spoke, then it may match the known issue. Workaround: Flushing the tunnel on Spoke1 may clear the issue temporarily. To flush the tunnel: diagnose vpn ike gateway flush name <phase1-name> Alternatively, if administrative access to the spoke does not depend on the tunnel, the tunnel can be flushed by disabling the parent tunnel interface for a few seconds then enabling it again: config system interface     edit "phase1-name"         set status down     next end Wait for 10 seconds, then re-enable the tunnel interface: config system interface     edit "phase1-name"         set status up     next end