Description
This article describes an issue where one of the SPA tunnels in FortiSASE goes down for a specific Point of Presence (POP), while other POPs continue to operate normally. It also provides possible causes, troubleshooting steps, and workarounds to restore connectivity.
Scope
FortiSASE.
Solution
As shown in the image, the SPA tunnel to the Singapore POP is down.
IKE debug and packet capture can be taken on the HUB side FortiGate.
diagnose debug app ike -1 <----- To do the VPN debug.
diagnose debug console timestamp enable <----- To cross-check with VPN events.
diagnose debug enable <------ To display the debug output.
diagnose debug disable <----- To stop the debug output.
Packet capture can be taken:
diagnose sniff packet any ‘host x.x.x.x and (port 500 or 4500)’ 4 0 l
2025-09-28 20:27:21.437911 port1 in 10.5.146.81.500 -> 10.5.146.16.500: udp 304
2025-09-28 20:27:24.439992 port1 in 10.5.146.81.500 -> 10.5.146.16.500: udp 304
2025-09-28 20:27:30.436475 port1 in 10.5.146.81.500 -> 10.5.146.16.500: udp 304
The capture shows incoming traffic on UDP 500, but no outgoing response packets are seen.
Verify if local in policy is set up on the HUB FortiGate
erbium-kvm56 # show firewall local-in-policy
config firewall local-in-policy
edit 1
set uuid 278472fa-9c7b-51f0-8620-eefda2655c6b
set intf "port1"
set srcaddr "Singapore"
set dstaddr "all"
set service "IKE"
set schedule "always"
next
end
The issue was traced to a local-in policy blocking IKE traffic from the Singapore geo-location. This configuration prevented the tunnel from coming up. Once the local-in policy was removed, the tunnel was restored.
