For security purposes, VPN peers refresh the encryption key every hour, by default, after establishing the IPsec tunnel. This is called the "rekey" process. During the rekey process, users might see a bad SPI event and observe a few packet drops going through the IPsec tunnel.

This article gives the reason for the bad SPI events to occur and if any action is required.

Note: A Security Parameter Index (SPI) is an arbitrary value that uniquely identifies which SA to use at the receiving host. The sending host uses the SPI to identify and select which SA to use to secure every packet. The receiving host uses the SPI to identify and select the encryption algorithm and key used to decrypt packets.

Topology

[SRX340](ge-0/0/0) --- <VPN> -- [SRX240H2]

Below is an example output of a syslog message and the related command output when a bad SPI event occurs.

Note: This output is confirmed on SRX340 that is running Junos OS 15.1X49-D140.3.

IPsec SA Status

Users will observe old/new SPI entries simultaneously during the rekey process.

root@jtac-srx340-r2021> show security ipsec security-associations | refresh 1

---(refreshed at 2019-01-16 14:32:40 JST)---
Total active tunnels: 1
ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
<131073 ESP:aes-cbc-256/sha256 aea6b37 97/ unlim - root 500 10.51.0.253
>131073 ESP:aes-cbc-256/sha256 85426da1 97/ unlim - root 500 10.51.0.253
---(refreshed at 2019-01-16 14:32:44 JST)---
Total active tunnels: 1
ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
<131073 ESP:aes-cbc-256/sha256 aea6b37 expir/expir - root 500 10.51.0.253 << OLD SPI
>131073 ESP:aes-cbc-256/sha256 85426da1 expir/expir - root 500 10.51.0.253 << OLD SPI 
<131073 ESP:aes-cbc-256/sha256 398bbc8d 298/ unlim - root 500 10.51.0.253 << NEW SPI
>131073 ESP:aes-cbc-256/sha256 eba754bf 298/ unlim - root 500 10.51.0.253 << NEW SPI
---(refreshed at 2019-01-16 14:32:48 JST)---
Total active tunnels: 1
ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
<131073 ESP:aes-cbc-256/sha256 398bbc8d 295/ unlim - root 500 10.51.0.253
>131073 ESP:aes-cbc-256/sha256 eba754bf 295/ unlim - root 500 10.51.0.253

Syslog Output Example

Users may observe bad SPI events towards the ESP packet with the new SPI.

Note: SPI 0x398bbc8d is the new SPI, which will be used after completion of the rekey process.

Jan 16 14:32:43  jtac-srx340-r2021 RT_IPSEC: RT_IPSEC_BAD_SPI: IPSec tunnel on int ge-0/0/0.0 with tunnel ID 0x20001 received a packet with a bad SPI.
10.51.0.253->10.51.0.193/156, ESP, SPI 0x398bbc8d, SEQ 0x1.

Output of show interfaces detail

Users may observe "No SA" in the incoming SPI counter value increment. This is related to the above bad SPI event.

show interfaces ge-0/0/0 detail | match "No SA" | refresh 3

---(refreshed at 2019-01-16 14:32:41 JST)---
No SA for incoming SPI:            0
---(refreshed at 2019-01-16 14:32:44 JST)---
No SA for incoming SPI:            1  << count up

At the time of the rekey process, the SRX device installs the new key into the data plane after negotiating the SA with the VPN peer.

The timing of this installation can be slightly different between VPN devices. Sometimes, one device may install the new key faster than the other device and send the ESP packet with the new SPI. When the above ESP packet arrives, however, the other device might not be ready to accept it.

Due to this, a "bad SPI" event is sometimes logged on the SRX device.

This is by design. The installation timing of the new key can be slightly different between the VPN devices, depending on the platform, resource usage state, and so on.

This bad SPI event is frequently seen in lab environments where VPN devices are located very close to each other. In this situation, traffic from one VPN device can reach the other device very fast.

On the other hand, real network environments are likely to have more distance, which will help the SRX device install the new key before receiving the new ESP packet. As a result, the chances of encountering this bad SPI message decrease.