Solution | The absence of port forwarding in an existing VIP entry on an ADVPN spoke FortiGate, as shown below, may prevent shortcut tunnels from establishing, particularly when the ADVPN tunnel on the spoke uses the same WAN interface and IP as the VIP in the VPN local gateway configuration.
config system interface
  edit "wan1"
    set vdom "Internet"
    set ip x.x.x.x/30 <-----
    set type physical
    set lldp-reception enable
    set role wan
end
config firewall vip
  edit "VIP_Server"
    set extip x.x.x.x <-----
    set extintf "wan1" (or "any")
    set mappedip "10.10.10.230"
  next
config vpn ipsec phase1-interface
  edit "ADVPN-Wan1"
    set interface "wan1" <-----
    set local-gw x.x.x.x <-----
    set ike-version 2
    set dhgrp 32
    set proposal aes256-sha256
    set peertype any
    set mode-cfg enable
    set localid "Spoke"
    set remote-gw y.y.y.y
    set idle-timeout enable
    set idle-timeoutinterval 5
    set dpd-retrycount 2
    set dpd-retryinterval 2
    set net-device enable
    set auto-discovery-receiver enable
    set psksecret *********
    set network-overlay enable
    set network-id 11
    set auto-discovery-shortcuts dependent
    set mode-cfg-allow-client-selector enable
end
 As a result of the above configuration, after the spoke establishes a tunnel with the hub, and when interesting traffic from one spoke to another triggers IKE shortcut negotiation on the hub, the following behavior may occur: The IKE Shortcut Offer messages from the hub to the initiating spoke, and the IKE Shortcut Query/Reply messages from the peer spoke to the misconfigured spoke, may match VIP-based firewall policies on the spokes. These messages may be translated to the mapped IP address of the VIP entry. Hence, the IKE daemon on the spokes will not receive or process these IKE informational (shortcut) messages.
 As a result, after a specific retransmission timeout for the IKE shortcut messages on the hub, the hub may drop the tunnel to the spoke, assuming there is one-way traffic over the tunnel. This is because DPD (Dead Peer Detection) on the Hub Firewall may interpret the lack of response as a failure and bring the tunnel down. See below.  IKE debug logs on the Hub FortiGate:
2025-09-10 20:18:01.555711 ike V=root:0:t-cdw1_9: forward shortcut-query
18256319074504739019 61321f2c8c588c01/0000000000000000
63.141.218.82 10.217.128.120->10.217.30.14 0 psk 6
4 ppk 0 ttl 31 ver 2 mode 0, ext-mapping 63.141.218.82:0, network-id 2
2025-09-10 20:18:01.555777 ike V=root:0:t-cdw1_9:73310: sending NOTIFY msg
2025-09-10 20:18:01.555790 ike V=root:0:t-cdw1_9:1689:73310: send informational
2025-09-10 20:18:01.555803 ike 0:t-cdw1_9:1689:
enc 000000F40000F0FCCB080BDE78795BFD1F2000000008001061321F2C8C588C010000000000000000001B
002400000000000000000000000000000000000000
0000000000000000000000000000000000000100040AD98078000300040
AD91E0E000500043F8DDA52000D00043F8DDA52000F00020000000000160002D660000000170002
EED10000000700400940BFAA8F6E9125C4DDD7EB
9BC40C16BE9B3CCE161B057AC226F416D4935CF05679107D8DFC633B8938C
13941C86FAC846C50D8EF603C0FA369B1E7AFC4BF2E000B0001025F
7361000C000100703D3700100001002E31330011000102206C6F0012000100
392E330B0A0908070605040302010B
2025-09-10 20:18:01.555838 ike 0:t-cdw1_9:1689:
out 6068C29F87C7D664DD581A878CF5E6B42E20250000000014000001482900012C8B28BE
100E0B1BBF5213895075AE2E1BC92FD34943C456CF8F1B9C209C2A1C
3FE87B80961781010738D06BDE1F792F7D56D92CCC9711DD8D3E557BBD885F6
EC09C2D2B5E9331877B60D040D77AB01D410CCAC5FD88FEFE9E57AB163BA0DB85C559D9C74
C9285AC11212FF620F9C35B3164D3F4ACD7D57A84
E91CEC6C4379C808BC69057A5B707C9CFB09379CA92023434CF4A34F244A4F14036D2637111529
C1A61A35155814177F032144CA2B0CE8E392E10BDF8C1174958C54FC95F48451D817592F522CBB516385A0D78316A9FD42ED
8B766BB681073BFFC691C3776EDCF526EEDBDBF6DF1C00A678E4975153279AAB9FF887824
D7C2004CEEDEACE504D240132B52D4310C9E0510B1FFC08FDE37DA19DA6AC1914BA10645E8EC927BE5A3384B87AC840FFD325
2025-09-10 20:18:01.555876 ike V=root:0:t-cdw1_9:1689:
sent IKE msg (INFORMATIONAL): 69.31.97.147:500->74.199.168.54:500,
len=328, vrf=0, id=6068c29f87c7d664/dd581a878cf5e6b4:000
00014, oif=3
2025-09-10 20:18:02.999015 ike 0 ike_ui_admin_caps_trigger sport 59268, dport 53, proto 6, iif 24
2025-09-10 20:18:04.552514 ike 0:t-cdw1_9:1689:
out 6068C29F87C7D664DD581A878CF5E6B42E20250000000014000001482900012C8B28
BE100E0B1BBF5213895075AE2E1BC92FD34943C456CF8F1B9C209C2A1C
3FE87B80961781010738D06BDE1F792F7D56D92CCC9711DD8D3E557BBD885F6
EC09C2D2B5E9331877B60D040D77AB01D410CCAC5FD88FEFE9E57AB163
BA0DB85C559D9C74C9285AC11212FF620F9C35B3164D3F4ACD7D57A84
E91CEC6C4379C808BC69057A5B707C9CFB09379CA92023434CF4A34F244
A4F14036D2637111529C1A61A35155814177F032144CA2B0CE8E392E10
BDF8C1174958C54FC95F48451D817592F522CBB516385A0D78316A9FD42ED
8B766BB681073BFFC691C3776EDCF526EEDBDBF6DF1C00A678E4975153279
AAB9FF887824D7C2004CEEDEACE504D240132B52D4310C9E0510B1FFC08FDE37
DA19DA6AC1914BA10645E8EC927BE5A3384B87AC840FFD325
2025-09-10 20:18:04.552583 ike V=root:0:t-cdw1_9:1689:
sent IKE msg (RETRANSMIT_INFORMATIONAL): 69.31.97.147:500->74.199.168.54:500,
len=328, vrf=0, id=6068c29f87c7d664/dd581a878
cf5e6b4:00000014, oif=3
2025-09-10 20:18:10.553301 ike 0:t-cdw1_9:1689:
out 6068C29F87C7D664DD581A878CF5E6B42E20250000000014000001482900012C8
B28BE100E0B1BBF5213895075AE2E1BC92FD34943C456CF8F1B9C209C2A1C
3FE87B80961781010738D06BDE1F792F7D56D92CCC9711DD8D3E557BBD885F6EC09C2
D2B5E9331877B60D040D77AB01D410CCAC5FD88FEFE9E57AB163BA0DB85C559
D9C74C9285AC11212FF620F9C35B3164D3F4ACD7D57A84
E91CEC6C4379C808BC69057A5B707C9CFB09379CA92023434CF4A34F244A4
F14036D2637111529C1A61A35155814177F032144CA2B0CE8E392E10BDF8C1174958C54
FC95F48451D817592F522CBB516385A0D78316A9FD42ED
8B766BB681073BFFC691C3776EDCF526EEDBDBF6DF1C00A678E4975153279AAB9
FF887824D7C2004CEEDEACE504D240132B52D4310C9E0510B1FFC08FDE37DA19DA6AC1914
BA10645E8EC927BE5A3384B87AC840FFD325
2025-09-10 20:18:10.553374 ike V=root:0:t-cdw1_9:1689:
sent IKE msg (RETRANSMIT_INFORMATIONAL): 69.31.97.147:500->74.199.168.54:500,
len=328, vrf=0, id=6068c29f87c7d664/dd581a878
cf5e6b4:00000014, oif=3
2025-09-10 20:18:22.551153 ike 0:t-cdw1_9:1689: out 6068C29F87C7D664DD581A878CF5E6B42
E20250000000014000001482900012C8B28BE100E0B1BBF5213895075AE2E1BC92FD34943C456CF8F1B9C209C2A1C
3FE87B80961781010738D06BDE1F792F7D56D92CCC9711DD8D3E557BBD885F6EC09C2D2B5E9331877
B60D040D77AB01D410CCAC5FD88FEFE9E57AB163BA0DB85C559D9C74C9285AC11212FF620F9C35B3164D3F4ACD7D57A84
E91CEC6C4379C808BC69057A5B707C9CFB09379CA92023434CF4A34F244A4F14036D2637111529
C1A61A35155814177F032144CA2B0CE8E392E10BDF8C1174958C54FC95F48451D817592F522CBB516385A0D78316A9FD42ED
8B766BB681073BFFC691C3776EDCF526EEDBDBF6DF1C00A678E4975153279AAB9
FF887824D7C2004CEEDEACE504D240132B52D4310C9E0510B1FFC08FDE37DA19
DA6AC1914BA10645E8EC927BE5A3384B87AC840FFD325
2025-09-10 20:18:22.551227 ike V=root:0:t-cdw1_9:1689:
sent IKE msg (RETRANSMIT_INFORMATIONAL): 69.31.97.147:500->74.199.168.54:500,
len=328, vrf=0, id=6068c29f87c7d664/dd581a878
cf5e6b4:00000014, oif=3
2025-09-10 20:18:46.556466 ike 0:t-cdw1_9:1689: out 6068C29F87C7D664DD581A878CF5E6B42
E20250000000014000001482900012C8B28BE100E0B1BBF5213895075AE2E1BC92FD34943C456CF8F1B9C209C2A1C
3FE87B80961781010738D06BDE1F792F7D56D92CCC9711DD8D3E557BBD885F6EC09C2D2B5
E9331877B60D040D77AB01D410CCAC5FD88FEFE9E57AB163BA0DB85C559D9C74C9285AC11212FF620F9C35B3164D3F4ACD7D57A84
E91CEC6C4379C808BC69057A5B707C9CFB09379CA92023434CF4A34F244A4F14036
D2637111529C1A61A35155814177F032144CA2B0CE8E392E10BDF8C1174958C54FC95
F48451D817592F522CBB516385A0D78316A9FD42ED
8B766BB681073BFFC691C3776EDCF526EEDBDBF6DF1C00A678E4975153279AAB9FF887824D7
C2004CEEDEACE504D240132B52D4310C9E0510B1FFC08FDE37DA19DA6AC1914BA10645E8EC927BE5A3384B87AC840FFD325
2025-09-10 20:18:46.556533 ike V=root:0:t-cdw1_9:1689: sent IKE msg (RETRANSMIT_INFORMATIONAL): 69.31.97.147:500->74.199.168.54:500, len=328, vrf=0, id=6068c29f87c7d664/dd581a878
cf5e6b4:00000014, oif=3
2025-09-10 20:19:34.551740 ike V=root:0:t-cdw1_9:1689: 6068c29f87c7d664/dd581a878cf5e6b4 retransmission timeout
2025-09-10 20:19:34.551778 ike V=root:0:t-cdw1_9:1689: expiring IKE SA 6068c29f87c7d664/dd581a878cf5e6b4
2025-09-10 20:19:34.551793 ike V=root:0:t-cdw1_9: going to be deleted
2025-09-10 20:19:34.551872 ike V=root:0:t-cdw1_9: flushing
2025-09-10 20:19:34.551931 ike V=root:0:t-cdw1_9: deleting IPsec SA with SPI f4a6c246
2025-09-10 20:19:34.551994 ike V=root:0:t-cdw1_9:t-cdw1: deleted IPsec SA with SPI f4a6c246, SA count: 0
2025-09-10 20:19:34.552005 ike V=root:0:t-cdw1_9: sending SNMP tunnel DOWN trap for t-cdw1
2025-09-10 20:19:34.552046 ike V=root:0:t-cdw1_9: assigned addr down event 10.49.1.10 (devidx=24)
2025-09-10 20:19:34.552609 ike V=root:0:t-cdw1_9:t-cdw1: delete
2025-09-10 20:19:34.552714 ike V=root:0:t-cdw1_9:73355: sending NOTIFY msg
2025-09-10 20:19:34.552723 ike V=root:0:t-cdw1_9:1689:73355: send informational
If SD-WAN is enabled on these IPsec tunnels, the associated SD-WAN health checks may also fail on the spoke shortly afterward.
Note:Â The initial IPsec tunnel is successfully established because the spoke actively initiates the connection to the hub. This is treated as local-out traffic, creating a temporary UDP session that is not affected by the incorrect VIP configuration. However, once that session times out, subsequent IKE messages from the hub to the spoke are subject to VIP-based firewall policy matching, especially when the VIP is configured with an 'any-to-any' port range.
Unlike IKE, ESP traffic is not affected, as the kernel handles it after the tunnel is established and no longer relies on VIP-based policy checks. The same issue will be presented when the FortiGate (Spoke/Hub) is configured with a Local-in-policy to deny incoming IKE/NAT-T traffic.
To resolve this issue, configure the VIPs with port forwarding instead of using an 'any-to-any port' VIP configuration. This prevents IKE shortcut messages from being misrouted or dropped due to VIP-based firewall policy interference on the spokes.
In cases where a DENY local-in-policy on the Hub or Spoke Firewalls drops IKE/NAT-T (ports 500/4500) traffic, ensure that a new local-in-policy is created and positioned at the top of the list to allow IKE/NAT-T ADVPN shortcut control messages.
Note: On the spokes, the local-in allow policy must permit IKE/NAT-T traffic (UDP/500 and UDP/4500) from the remote spokes’ underlay IP addresses, including their translated public IP addresses when NAT is present, as applicable to the deployment. Allowing only the hub IP address may permit the parent tunnel to establish while blocking direct spoke-to-spoke shortcut negotiation. Place the allow policy before the matching deny policy and verify that its incoming interface and source address objects cover the intended shortcut peers.
|
