Encountering np-sp-invalid-spi can be a common VPN IPSEC issue. Let’s look at the details and possible remediations.
So life is beautiful but suddenly you get a call/ticket that your vendor or customer is unable to reach your resources over the VPN.
Both sides didn’t make any changes but traffic starts to drop.
At this point it’s always good to start debugging your VPN.
debug crypto ipsec 127
debug crypto ikev1 127
Sample output can be displayed as follow:
73: 13:25:40.553224 RemotePublicIP > LocalPublicIP: ip-proto-50, length 100 Drop-reason: (np-sp-invalid-spi) Invalid SPI
74: 13:25:42.565934 RemotePublicIP > LocalPublicIP: ip-proto-50, length 100 Drop-reason: (np-sp-invalid-spi) Invalid SPI
75: 13:25:45.582596 RemotePublicIP > LocalPublicIP: ip-proto-50, length 100 Drop-reason: (np-sp-invalid-spi) Invalid SPI
76: 13:25:48.265931 RemotePublicIP > LocalPublicIP: ip-proto-50, length 100 Drop-reason: (np-sp-invalid-spi) Invalid SPI
77: 13:25:48.373607 RemotePublicIP > LocalPublicIP: ip-proto-50, length 100 Drop-reason: (np-sp-invalid-spi) Invalid SPI
You can also verify (without debug) if you are getting any packet drops on i.e ASA ASP(accelerated security path) by doing the following.
Clear current asp drop counter
clear asp drop
Check ASP table for any increments
sh asp drop
IPSEC tunnel is down (ipsec-tun-down) 6372
VPN reclassify failed (vpn-reclassify-failed) 176
Invalid TCP Length (invalid-tcp-hdr-length) 43
No valid adjacency (no-adjacency) 35
No route to host (no-route) 6973
Flow is denied by configured rule (acl-drop) 72188006
Invalid SPI (np-sp-invalid-spi) 18895
First TCP packet not SYN (tcp-not-syn) 2347204
Bad TCP flags (bad-tcp-flags) 17
TCP data send after FIN (tcp-data-past-fin) 120
TCP failed 3 way handshake (tcp-3whs-failed) 4878718
TCP RST/FIN out of order (tcp-rstfin-ooo) 6445774
TCP SEQ in SYN/SYNACK invalid (tcp-seq-syn-diff) 167
TCP SYNACK on established conn (tcp-synack-ooo) 39
TCP packet SEQ past window (tcp-seq-past-win) 56180
TCP invalid ACK (tcp-invalid-ack) 114
TCP replicated flow pak drop (tcp-fo-drop) 15
TCP Out-of-Order packet buffer full (tcp-buffer-full) 235
TCP Out-of-Order packet buffer timeout (tcp-buffer-timeout) 8
TCP RST/SYN in window (tcp-rst-syn-in-win) 1002
TCP dup of packet in Out-of-Order queue (tcp-dup-in-queue) 354
TCP packet failed PAWS test (tcp-paws-fail) 2476
Slowpath security checks failed (sp-security-failed) 2457921
IP option drop (invalid-ip-option) 60
From the output we can see that our Invalid SPI (np-sp-invalid-spi) is increasing.
Cisco published command reference guide for all ASP frame type drops which I encourage you to save as your favorite.
This counter will increment when the appliance receives an IPSec ESP packet addressed
to the appliance which specifies a SPI (security parameter index) not currently known by
Occasional invalid SPI indications are common, especially during rekey processing.
Many invalid SPI indications may suggest a problem or DoS attack. If you are experiencing
a high rate of invalid SPI indications, analyze your network traffic to determine the
source of the ESP traffic.
Bottom line is SPI’s (Security Parameter Indexes) needs to match on both sides which are tags and are part of SA(security association). It’s the relationship between two remote sites i.e host to host relationship. If they don’t match for some reasons the connection will never be established and traffic will drop.
Relation can be verified by checking SPI’s for this particular network that is having problems:
sh crypto ipsec sa | in ident|encap|decap|current
local ident (addr/mask/prot/port): (10.254.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (10.255.0.0/255.255.0.0/0/0)
#pkts encaps: 577497274, #pkts encrypt: 585929391, #pkts digest: 585929391
#pkts decaps: 316226349, #pkts decrypt: 316226349, #pkts verify: 316226349
#PMTUs sent: 4729, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
current outbound spi: 014635AC
current inbound spi : EA643E65
Our outbound SPI should match remote side inbound SPI. Something to verify with the other side.
Now there is a rekeying that happens every x lifetime (based on your established settings) where SPI’s will be asked to be refreshed. So the whole SA relationship is new.
Now that’s where the grey area comes in. Sometime the rekeying will only happen on one side and the other will use inactive SPI causing the issue.
To verify if you have any inactive SPI’s you can perform the following
ASA-Mgmt/act/pri# sh crypto ipsec sa inactive
Checking for inactive IPsec SAs…
Inactive IPsec SAs: 0
If in fact SPI’s are not matching AND/OR you are seeing inactive ones please clear them (both sides if applicable).
clear crypto ipsec sa inactive
Last resort would be to bounce the IPSEC between the sides.
clear crypto ipsec sa peer RemotePeerIP
If you are still experiencing the issue after refreshing SPI’s OR rebouncing the IPSEC raise the debug to 255 and collect data to analyze. There might be more issues.
Long story short my peer had inactive SPI’s causing the packets drop. Clearing SPI’s did the trick.
I hope this has been informative to you and thanks for stopping by.