Technical Tip: Explanation of 'Unknown SPI' message in Event log

[#1]

Description	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 (diag debug app ike -1) while these logs are occurring:
Scope	IPsec on FortiGate.
Solution	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'. - In some scenarios, it's possible that a random host on the Internet is 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 in the event that such a packet is received by the FortiGate, This behavior can be changed for more information review the next KB ARTICLE: Technical Tip: Difference in ESP and IKE packet handling of local-in policies 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