This article is the most popular article on this blog as of July 2012.
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!
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.
Great job on the heads up. Troubeshooting this exact issue and stumbled accross this. Ended up being a mismatch on the PFS settings. thanks!
Glad this helped out! It actually took me about 3 hours or so to solve, ending up doing this with CISCO tech over the phone.
Hey thanks a lot! I'm new to this switch and had no idea what was going on. Sneaky PFS settings strike again. You saved my day and made me the office hero (if it still works tomorrow lol)
Thank you very much! I came across the same error today and this fixed it. A good reminder to walk through all your configs when troubleshooting!
Make sure both sides of the VPN tunnel have the same host and/or CIDR entries or this msg will occur.
I think I'm expanding a bit on what Jynx wrote:
For a L2L connection using a Pre-shared key, use only the IP address to identify the peer, not a hostname.
Also, the "crypto isakmp identity" must be
acceptable to each side. Typically, setting it to "auto" in the ASA's general config works:
ASA(config)# crypto isakmp identity auto
Having it set to "hostname" is not always acceptable to the remote side and will generate the same Phase 2 error.
"show run all isamkp" will display the current setting.
PFS was the culprit in my case. Unchecking it on my end brought up the vpn. Looked like the peer at the other end had it unchecked, or maybe they have a different firewall model.
You came up with a great guide. It helped me a lot most especially with that error. Thanks
Post a Comment