Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

BAD SPI messages in the event log



Article ID: KB10091 KB Last Updated: 30 Jul 2015Version: 9.0
BAD SPI messages in the event log
BAD SPI messages in the event log:

Message     IPSec tunnel on interface <if_name> with tunnel ID 0x<sa_tid_hex> received a packet with a bad SPI. <src_ip><dst_ip>-><pak_len><esp_or_ah>/<spi_hex>, <seq_number_hex>, SPI 0x%x, SEQ 0x%x. 

  The ScreenOS Message Log Reference Guide describes the error as follows:

Meaning     The local security device received a packet with an incorrect security parameters index (SPI) number through the IPSec tunnel with the specified ID number (in hexadecimal notation) arriving at the specified interface. The message indicates the source and destination IP addresses of the outer packet header and the packet length (in bytes). The packet was either formatted for the Encapsulating Security Payload (ESP) or Authentication Header (AH) protocol, and had the specified SPI number and the sequence number—both in hexadecimal notation. The security device dropped the packet, and if it found a valid VPN configuration for the source IP address and Initial Contact notification was enabled, it also sent an Initial Contact Notify message to that address.

Note: By default, when the security device detects multiple packets with a bad SPI number, this message appears in the log once every 10 seconds per tunnel. If you want the security device to make a log entry for every detected packet with a bad SPI number, enter the "set firewall log-self ike" command; however, Juniper Networks does not recommend this because the logging can become excessive.

The following are also possible reasons for BAD SPI messages in the Event Log (get event):

1. If the Bad SPI messages in the Event Log tend to occur at the same interval as the rekey, the security gateways on both sides may be attempting to renegotiate the IKE tunnel at the same time (or at a very slight delay), which can result in a SPI mismatch.  A possible solution is to adjust the soft-lifetime-buffer, which is the time for IKE to initialize before the hard lifetime. This solution is only available from the CLI by entering the following command:
set ike soft-lifetime-buffer 

The default is 10 seconds.
Try setting it at 40, and then the fine tune it by increasing or decreasing.

2. If the Bad SPI messages occur continuously and if the ScreenOS version is below 5.4, then the firewall may mistakenly be interpreting an embedded ICMP packet as a BAD SPI.  In ScreenOS 5.0, 5.1, 5.2 and 5.3, the Juniper firewall is not inspecting the packets smartly to identify whether the packet is an ICMP packet and take necessary action;  instead it is logging it as a BAD SPI message.

Here’s a scenario to explain it.  

The Juniper firewall is connected to an upstream router such as a Cisco on the Untrust side. The Juniper firewall is the end VPN termination point.
The Juniper firewall is encrypting all the packets going on the tunnel and transmitting it out the physical Untrust interface.
Let’s say for some reason the upstream router lost the Internet link, and the default route is disappeared.
The Juniper firewall continues to send the IPSec packets as the gateway on the Untrust is reachable.
In this condition, the router replys to every IPSec packet sent from the Juniper firewall with an ICMP Destination Unreachable message indicating the ISP link is down.
When such messages are received, the firewall removes the ICMP header and checks for the payload packet which is a IPSec packet sent from the firewall, and tries to match the session on the firewall.
When it checks the SPI numbers on the IPSec packet, it sees a wrong SPI numbers as it is seeing the self assigned SPI number for incoming and outgoing and drops the packet and logs a "BAD SPI" message in the event log.

This scenario of ICMP embedded messages can also occur for other ICMP Unreachable conditions, such as Path MTU, depending on the customer network.

A way to confirm if the ICMP embedded message is the cause is to correlate the ICMP Destination Unreachable messages shown in Debug Flow/Snoop/Sniffer with the Bad SPI messages in the Event Log.  If there is a Bad SPI message for every ICMP packet generated from the router, then upgrade to ScreenOS 5.4 or later.

In screenOS 5.4 and above, the embedded ICMP packet is inspected and verified if it was a packet sent from the firewall by-itself and drop it as packet for self without logging any BAD SPI event log message.

3. The new SPI might be used on one side of the VPN before it is fully installed on the other. When this occurs you will see the Bad SPI error before the P2 complete in the event log. To correct this see

4.If either of the above do not correct the issue, then capture the following data and open a case with JTAC:
get tech
get event
get ike cookie
get sa
get sa stat
get sa  id <id> (for sa in question)

Sniffer traces at time of the Bad SPI event, along with corresponding debug flow/snoop data

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search