VPN Connection Keeps Dropping

[loyalist]

Hi there,

Have 3 remote users all in the same office connecting via individual vpn clients (cisco 4.0.2) to corporate network(PIX 515E, IOS 6.3(1))with ipsec. Users all using wireless to Linksys to connect to internet. VPN connection keeps dropping, sometimes only takes a few seconds sometimes up to 30 minutes, however still drops. Get following error on client logs:

1339 11:17:01.729 10/01/03 Sev=Warning/3 IKE/0xA3000056
Driver says we received a packet with invalid SPI (2938282918), sending INVALID-SPI notify.
1340 11:17:01.729 10/01/03 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:INVALID_SPI) to xxx.xxx.xxx.xxx
1341 11:17:02.250 10/01/03 Sev=Info/5 IKE/0x6300002F
Received ISAKMP packet: peer = xxx.xxx.xxx.xxx
1342 11:17:02.250 10/01/03 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK INFO *(HASH, DEL) from xxx.xxx.xxx.xxx
1343 11:17:02.250 10/01/03 Sev=Info/5 IKE/0x6300003C
Received a DELETE payload for IKE SA with Cookies: I_Cookie=4404DD87B1E8A573 R_Cookie=3E9F3193C90AE0D9
1344 11:17:02.260 10/01/03 Sev=Info/5 IKE/0x63000018
Deleting IPsec SA: (OUTBOUND SPI = 73C6A922 INBOUND SPI = 12FA531C)
1345 11:17:02.260 10/01/03 Sev=Info/4 IKE/0x63000048
Discarding IPsec SA negotiation, MsgID=E2A97F2B
1346 11:17:02.260 10/01/03 Sev=Info/4 IKE/0x63000017
Marking IKE SA for deletion (I_Cookie=4404DD87B1E8A573 R_Cookie=3E9F3193C90AE0D9) reason = PEER_DELETE-IKE_DELETE_UNSPECIFIED
1347 11:17:02.700 10/01/03 Sev=Info/4 IKE/0x63000055
Received a key request from Driver: Local IP = 10.100.40.64, GW IP = 0.0.0.0, Remote IP = 10.100.50.5
1348 11:17:02.700 10/01/03 Sev=Warning/3 IKE/0xE3000065
Could not find an IKE SA for 10.100.50.5. KEY_REQ aborted.
1349 11:17:02.700 10/01/03 Sev=Warning/2 IKE/0xE3000099
Failed to initiate P2 rekey: Error dectected (Initiate:176)

Get following error on PIX:

402101: decaps: rec'd IPSEC packet has invalid spi for destaddr=xxx.xxx.xxx.xxx, prot=esp, spi=0xbc87ce55(1439598524)

This is what cisco says:

. %PIX-4-402101: decaps: rec'd IPSEC packet has invalid spi for destaddr=IP_addr, prot=protocol, spi=spi
Received IPSec packet specifies SPI that does not exist in SADB. This may be a temporary condition due to slight differences in aging of SAs between the IPSec peers, or it may be because the local SAs have been cleared. It may also be becau se of incorrect packets sent by the IPSec peer. This may also be an attack.

Recommended Action: The peer may not acknowledge that the local SAs have been cleared. If a new connection is established from the local router, the two peers may then reestablish successfully. Otherwise, if the problem occurs for more than a brief period, e ither attempt to establish a new connection or contact the peer's administrator.

Related documents: No specific documents apply to this error message.

Very helpful ;-)

Have 10 other users who are all connecting fine with no issues. Everyone is running the same client. Found this document, however the command that could fix this issue is not available on the pix:

When an invalid security parameter index (SPI) is encountered, the Invalid Security Parameter Index feature provides for the setting up of an IKE SA with the originator of the data, and the IKE &quot;INVALID SPI NOTIFY&quot; message is sent. The peer that originated the data &quot;sees&quot; the &quot;INVALID SPI NOTIFY&quot; message and deletes the IPSec SA that has the invalid SPI. If there is further traffic from the originating peer, there will not be any IPSec SAs, and new SAs will be set up. Traffic will flow again. The default behavior (that is, without configuring the Invalid Security Parameter Index Recovery feature) is that the data packet that caused the invalid SPI error is dropped. The originating peer keeps on sending the data using the IPSec SA that has the invalid SPI, and the receiving peer keeps dropping the traffic (thus creating the &quot;black hole&quot.

The IPSec module uses the IKE module to send an IKE &quot;INVALID SPI NOTIFY&quot; message to the other peer. Once the invalid SPI recovery is in place, there should not be any significant dropping of packets although the IPSec SA setup can itself result in the dropping of a few packets.

To configure your router for the Invalid Security Parameter Index Recovery feature, use the crypto isakmp invalid-spi-recovery command. The IKE SA will not be initiated unless you have configured this command.

Can someone please offer any suggestions?

Thanks,

Loyalist

 

[dx1]

Are you using a Linksys DSL/Cable Modem router? If you are, I think on some of the Linksys router, it allows only one IPSEC session through the router.
If that's the case, you can get another Linksys router that can terminate the VPN or get a PIX 501. Either way, your buying from the same company.

 

[loyalist]

Thanks dx1, however as of last week they were all connecting fine from that office. I released a new exchange server over the weekend and that's when the problems started. After posting this yesterday I was checking the pix logs and I kept seeing udp packets being sent by the exchange server to the private ip addresses that the remote clients were using in thier office. These were being blocked by the dmz access list, so as a test I let them through and now they are connecting fine(at least haven't heard any complaints since).

What I don't understand is why the exchange server was attempting to send udp packets to the private ip address instead of the address assigned to them by vpn pool or even the public address on the linksys. This is not affecting any of my other users.

Anybody have any ideas?

 

[captaintuba]

Loyalist - did you figure out what was going on?

We have a similar problem with unreliable VPN client connections. Our site-to-site connections always stay up. But when the PIX gets a little busy the client VPNs can drop out after any time.

Cheers C.T.

 

[loyalist]

the problem was a linksys wireless router only supporting one ipsec connection at a time. As usual I was misinformed by the users in the office in that they were not all attempting to connect at the same time until I released the exchange server, then it hit the fan. Regarding my other vpn users, really have had no major problems, there have been intermittent connections dropping but for the most part it has been wan related issues and nothing to do with the pix. Have also experienced outlook hanging while using vpn (requesting data error) but feel that this is a bandwidth/mtu issue that we will resolve with a dedicated dsl for vpn. I would try having the individual users dropping their mtu down to say 800 and see if that clears things up, it could just be congestion at your entry point that causes them to drop.