Technical Tip: Explanation of 'Unknown SPI' message in the event log

This article describes a common VPN Event log seen on the FortiGate that states 'Received ESP packet with unknown SPI'. The following are examples of what an administrator may see when reviewing VPN Event Logs: 

date=2022-09-08 time=16:29:21 eventtime=1662679761670200983 tz='-0700' logid='0101037131' type='event' subtype='vpn' level='error' vd='root' logdesc='IPsec ESP' msg='IPsec ESP' action='error' remip=x.x.x.175 locip=x.x.x.242 remport=500 locport=500 outintf='port1' cookies='N/A' user='N/A' group='N/A' useralt='N/A' xauthuser='N/A' xauthgroup='N/A' assignip=N/A vpntunnel='BC_Tun' status='esp_error' error_num='Received ESP packet with unknown SPI.' spi='3a4e6946' seq='0000002d'

Administrators may also see the following when running IKE debugs (diagnose debug app ike -1) while these logs are occurring:

IPsec on FortiGate.

The Security Parameter Index (SPI) is a value that is sent with every ESP packet and is used as a means of matching incoming ESP packets to the correct IPsec tunnel on the VPN endpoint. These SPIs are created when an IPsec tunnel is formed between two endpoints, and also these SPIs are recreated whenever the VPN tunnel Phase 2 Security Associations (SAs) are rekeyed, or when the tunnel is restarted.

On the FortiGate, the SPIs for each VPN tunnel (along with other information) can be found by running diagnose vpn tunnel list. For checking specific tunnels by name, use the command diagnose vpn tunnel list name <Name of IPsec Tunnel>:

There are two SPIs per IPsec tunnel. IPsec utilizes two separate encryption keys (one for sending/encryption, the other for receiving/decryption), and so there are also corresponding SPIs used for either matching incoming ESP packets (decryption) or for attaching to outgoing ESP packets (encryption). Notably, these keys are the same on both VPN endpoints, but are flipped in terms of their usage (i.e., an encryption key on one side is the decryption key for the other, and vice versa).

There may be various reasons why the FortiGate will generate a log message regarding an unknown SPI, but ultimately, the root issue is that the FortiGate received an ESP packet whose SPI does not match any currently-active IPsec tunnel. The following are some examples of how this might occur:

• The VPN gateway or client performs a re-key for this IPsec tunnel (as defined in the VPN Phase 2 settings), and the other endpoint fails to synchronize with this change for some reason. In this situation, one VPN endpoint is using a new set of encryption/decryption keys (and thus new SPIs), whereas the other VPN endpoint is still using the old set of keys/SPIs.
• Another situation is when the VPN gateway 'disappears', such as the FortiGate being rebooted, powered off, or the Ethernet link going down. When the link or unit comes back up, the FortiGate will have deleted any previously existing IPSec tunnels. If a remote VPN peer is unaware of this disruption, then it may continue to send encrypted IPsec traffic to the FortiGate. If this occurs, the FortiGate will receive these packets, not recognize the SPI associated with them, and subsequently drop the packets as 'unknown SPI'.
• Another possible reason for this error is an HA split-brain condition, where heartbeat or HA link failure causes multiple FortiGate units to operate as primary and independently rekey IPsec Phase-2 SAs. This results in SPI mismatches between peers, so ESP packets are received with SPIs that do not correspond to any active tunnel on the device, leading to tunnel flapping and "Received ESP packet with unknown SPI" log messages. More information is provided in this article: Technical Tip: IPsec VPN flapping, DPD/ESP (unknown SPI) errors due to HA split-brain.
• In some scenarios, a random host on the Internet may be simply sending ESP packets to the FortiGate's public IP, even if a VPN tunnel had not been established between this remote peer and the FortiGate beforehand.

As a side note, it is not possible to drop incoming ESP packets as an attempt to prevent the 'unknown SPI' log message from being generated.

The following Community KB article discusses why, by default, it is not possible to drop ESP packets using local-in policies, and why an administrator should expect to see the 'unknown SPI' message if such a packet is received by the FortiGate. This behavior can be changed. For more information, see this article: Technical Tip: Difference in ESP and IKE packet handling of local-in policies.

Persistent unknown SPI messages can be resolved by flushing the tunnel:

diagnose vpn tunnel flush <my-phase2-name>

This is also explained in this article: Technical Tip: How to flush a VPN tunnel.

This forces the tunnel to renegotiate and synchronize SPIs.

Related documents:

Phase 1 configuration

Technical Tip: ESP Packets are not blocked by local-in policy

Troubleshooting Tool: Using the FortiOS built-in packet sniffer