CISCO ASA Error construct_ipsec_delete(): No SPI to identify Phase 2 SA!

 This article is the most popular article on this blog as of July 2012.

Another one of those very cryptic CISCO log message. I guess these messages deserve to be cryptic, since my IOS code has a lot of "crypto" all over the place ;-)

Symptom:

When configuring for Site-to-Site VPN network, the IKE negotiation (Phase 1) works but Phase 2 results in a message like

• construct_ipsec_delete(): No SPI to identify Phase 2 SA!

What Fixed It:

It appears that this occurs when there is a significant mismatch in the VPN Tunnel IPSec configuration parameters. IPSec is also know as Phase 2. If you have come this far in your connection then Phase 1, or the IKE step is complete so do not go down the pass of "fixing" the Phase 1, for example, Shared Key mismatch. You are OK there, and focus on fixing this Phase 2 issue.

If you are using like me the ASDM, this information is in VPN->IPSec->IPSec Rules section.

• Be sure that the Network Address and Netmasks of End Points are properly set on both ends. For your end this is found at IPSec->IPSecRules->Traffic Selection. You could also be using Static NAT, so check to make sure that the NAT tables are correct. This is especially important if you are NATTing to external routable addresses to avoid non-routable IP address conflicts (this is a very very advanced topic and I don't even know what I am talking about so if this does not make sense, you do have to go to a CISCO professional for help. I am just a surfer with this job dropped on my lap.)
• Speaking of the NAT, you are likely that you have NATTed your inside address pool to a set of private addresses you have. If that is the case, then you DO have to make a NAT exception. The VPN wiz does that, but if you add another host in the same tunnel then you cannot use the Wiz any more so you'd forget this. Simply look in the NAT on the left control navigation bar and follow other examples in there that are working. I almost always forget this and scratch my heads for about an hour before I realize I have forgotten it (and even blogged about it!) If Phase 1 and 2 go OK but there still is no connection, then check the NAT table. Since there are a lot of people like me, they have forgotten the NAT exception too on their end. Be sure to ask them too.
• Be sure that PFS (Perfect Forwarding Secrecy) mode are matched on both ends. This is at the bottom of the Tunnel Policy (Crypto Map) - Basic panel.
• Also be sure that the traffic rules and netmasks match between two servers identically. If other side is going for 255.255.255.255 on individual IP address than you have do that on your end as well.You cannot use a wider mask on one end even the range includes the address you are accessing. The traffic access lists from both ends must match exactly.
• Now would also be a good time to download a TFTP client (may of them are out there), and backup your config on your local disk. Keep that config in Goodle Drive or somewhere with a descriptive file name (like ASA-5505-120605-AddedBostonOffice.txt) out in the cloud so that you won't lose it.