Created on 02-15-2006 12:00 AM Edited on 09-09-2022 01:50 PM
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:
Administrators may also see the following when running IKE debugs (diag debug app ike -1) while these logs are occurring:
|
Scope |
IPsec on FortiGate |
Explanation |
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 Associatiations (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>:
Note that 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 for 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 to 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 goes 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. |
Recommendations |
Enabling Dead Peer Detection (DPD) on both ends of the VPN can help in scenarios where one of the VPN endpoints temporarily 'disappears'. DPD works by sending ISAKMP/IKE keepalives via UDP/500 (or UDP/4500 with NAT-Traversal in-use), and in the event that the keepalives fail, the VPN tunnel is restarted (which can help to re-synchronize the SPIs and Security Associations between both VPN endpoints).
To enable Dead Peer Detection 1) Go to VPN -> IPSec Tunnels and select the VPN Tunnel to edit. 2) Select Edit for the Network settings. 3) Set Dead Peer Detection to either On Idle or On Demand. 4) Select OK.
For more information on DPD and other IPsec settings, please refer to the following: https://docs.fortinet.com/document/fortigate/latest/administration-guide/790613/phase-1-configuratio...
Adjusting the KeyLife value in Phase2 (on both the gateway and client) can be useful for verifying if the unknown SPI problem occurs more or less frequently. For example, increasing the keylife will result in a lower frequency of rekey events, which in-turn means fewer new SPIs are being generated. This may help to reduce (but perhaps not necessarily resolve) the number of unknown SPI logs being generated. Use the following FortiGate CLI commands to produce live debugs when a re-key occurs:
diag deb app ike 2 diag deb en
As mentioned above, the actual SPI values for each tunnel are displayed using the diag vpn tunnel list command on the FortiGate. As well, the SPI itself is visible when examining the ESP packet in a tool like Wireshark:
With that in mind, an administrator could run a packet capture on the FortiGate interface receiving these unknown SPIs, then compare against the current IPsec tunnel list to confirm if the Source/Destination IP addresses and the observed SPIs are correct or not. Using the sniffer, and decoding the packets is explained in the following Fortinet Knowledge Base article: Troubleshooting Tool: Using the FortiOS built-in packet sniffer |
Extra Notes |
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 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: Technical Tip: Difference in ESP and IKE packet handling of local-in policies. |
Related Articles |
Troubleshooting Tool: Using the FortiOS built-in packet sniffer |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.