invalid SPI on ASA to PIX

peterblersch · ‎01-19-2009

Hello,

on the ASA 5510 configured with a site to site VPN tunnel i get the following messages :

Jan 15 2009 12:10:50: %ASA-1-713900: Group = 123.123.123.123, IP = 123.123.123, construct_ipsec_delete(): No SPI to identify Phase 2 SA!

Jan 15 2009 12:10:50: %ASA-3-713902: Group = 123.123.123.123, IP = 123.123.123.123, Removing peer from correlator table failed, no match!

Jan 15 2009 12:15:51: %ASA-3-713902: Group = 123.123.123.123, IP = 123.123.123.123, QM FSM error (P2 struct &0xd6baffb8, mess id 0xd918a302)!

and on the PIX the message is :

402101: decaps: rec'd IPSEC packet has invalid spi for destaddr=123.123.123.123, prot=esp, spi=0x3e4e73c4(1045328836), srcaddr=234.234.234.234

I have hints that the crypto ACL are not symmetric or PFS is mot the same, but customer says this fits.

Any other reasons int tunnel parameters ?

Thanks

Peter

Ivan Martinon · ‎01-19-2009

Has this tunnel worked before? is this a new setup? did the tunnel go down and is not coming up or something? invalid SPI would mean that the tunnel is active but out of sync what are the vpn endpoints?

peterblersch · ‎01-19-2009

The tunnel has worked perfect bevor the migration.

I migrated a PIX 515 to a ASA 5510 with the

PIXtoASA migration tool.

There are 4 tunnels in a hub to spoke toplogy

with PIX 506 at the spoke endpoints.

2 tunnels work without error messages after the migration, 2 tunnles have problems.

The configuration is set up with nested group-object with hosts and networks for the crypto acl.

Could this be a problem ?

Ivan Martinon · ‎01-20-2009

It could if the match address on both ends is not exactly mirrored.

Danilo Dy · ‎01-20-2009

There's an SPI mismatch.

The VPN works before you migrate one of the firewall. Previously, the two firewalls SPI matched. When you migrate one of the firewall, the new firewall SPI start to zero while the other end firewall SPI could already reached 10 digits. You need to reset the SPI of the other firewall.

I experience this in Routers where I found it later as an IOS bug. Haven't experience this in PIX/ASA so far but I know that it happens to some and most of the events that triggers it are;

- One end Router/Firewall replaced/migrated

- One end Router/Firewall OS upgrade and rebooted

- One end Router/Firewall was down for a long period of time