Site2site VPN disconnect issue

Unanswered Question
Aug 18th, 2009

We have ASA5505 site2site IPSec VPN, here is the version

central site 8.04

remote1 8.03

remote2 7.24

I found the two VPNs always disconnect in every morning, I tried to clear the isa sa and ipsec sa, but they could not come back up. I tried to set the time out of IPSec and isa to the max value, but it doesn't work. The solution is reset the two remote ASAs.

Following is the log info on remote site's ASA when the VPN could not come back, two remote ASA have similiar info. Anyone has ideas?

Thanks. Leo

-----------------------------------------

Aug 18 2009 21:28:31: %ASA-3-713119: Group = 2.2.2.2, IP = 2.2.2.2, PHASE 1 COMPLETED

Aug 18 2009 21:28:31: %ASA-3-713061: Group = 2.2.2.2, IP = 2.2.2.2, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 10.157.96.0/255.255.224.0/0/0 on interface outside

Aug 18 2009 21:28:31: %ASA-3-713902: Group = 2.2.2.2, IP = 2.2.2.2, QM FSM error (P2 struct &0x41c5960, mess id 0x9f02f748)!

Aug 18 2009 21:28:31: %ASA-3-713902: Group = 2.2.2.2, IP = 2.2.2.2, Removing peer from correlator table failed, no match!

Aug 18 2009 21:28:31: %ASA-4-113019: Group = 2.2.2.2, Username = 2.2.2.2, IP = 2.2.2.2, Session disconnected. Session Type: IPSecLAN2LAN, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: crypto map policy not found

-----------------------------------------

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
smahbub Mon, 08/24/2009 - 05:27

If the users are frequently disconnected across the L2L tunnel, the problem can be the lesser lifetime configured in ISAKMP SA. If any discrepancy occurs in the ISAKMP lifetime, you can recieve the %PIX-5-713092: Group = x.x.x.x, IP = x.x.x.x, Failure during phase 1 rekeying attempt due to collision error message. Configure the same value in both the peers in order to fix it.

The default is 86,400 seconds or 24 hours. As a general rule, a shorter lifetime provides more secure ISAKMP negotiations (up to a point), but, with shorter lifetimes, the security appliance sets up future IPsec SAs more quickly.

A match is made when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the policy of the remote peer specifies a lifetime less than or equal to the lifetime in the compared policy. If the lifetimes are not identical, the shorter lifetime-from the policy of the remote peer-is used. If no acceptable match is found, the IKE refuses negotiation, and the IKE SA is not established.

xzjleo2005 Mon, 08/24/2009 - 14:20

Thanks for your reply.

I tried to set the longer timeout for ISA and IPsec, but the problem was still exist. My temp solution is, keep pinging the remote site, then the VPN tunnle can stay up.

I'm having almost the same problem but to a Checkpoint and not an ASA both devices say the tunnel is up but no traffic seems to get the the requested destination and yes a constant ping from one side appears to keep the tunnel going. Any ideas would be great. Also sh isakmp sa and sh ipsec sa seem to match what the checkpoint knows and expects for the tunnel.

naveen_b81 Thu, 09/24/2009 - 01:44

The log says that the access-list is not matching for the VPN tunnel. Not sure how it works after a restart though. Will be helpful if you post the complete config.

On the Checkpoint and Cisco VPN, please ensure that you set the phase 2 SA lifetime and size similar at both ends as the default values of these two vendors dont match.

PIX command is "crypto map rtpmap 10 set security-association lifetime seconds

3600 kilobytes 4608000"

Actions

This Discussion