Hi Experts,
i have been going thru the discussions threads of asa-checkpoint s2s vpn issues in cisco and still unable to find the curlprit for the problem...
initially i though supernet is creating the problem in cp, hence we removed one of the subnet 10.1.2.0 from both the devices acl...later on re-confirmed p1, p2 keylifetime values on both the devices.. later on we deleted the vpn in asa and freshly created it... it is hopeless to say that, issue still persists..
here we go the config part of cisco....
object-group network objgrp10
network-object 10.2.0.0 255.255.240.0
network-object 10.1.2.0 255.255.255.0
access-list nonacl extended permit ip object-group objgrp10 10.1.1.0 255.255.252.0
access-list cryptoacl extended permit ip object-group objgrp10 10.1.1.0 255.255.252.0
nat (inside) 0 access-list nonacl
phase-1
------------
lifetime 24hrs
phase-2
-----------
crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac
set security-association lifetime seconds 28800
set security-association lifetime kilobytes 3840000
crypto map OUTSIDE_ISP_map0 50 match address cryptoacl
set nat-t-disable
set reverse-route
group-policy GroupPolicy1 attributes
vpn-idle-timeout none
vpn-tunnel-protocol IPSec
tunnel-group 175.1.1.1 general-attributes
default-group-policy GroupPolicy1
tunnel-group 175.1.1.1 ipsec-attributes
pre-shared-key *****
isakmp keepalive threshold 15 retry 10
I do find a log in CP as, peer not responding which is cisco.... i have checked the vpn profile in CP for this tunnel and it is just the next-next button..Dont find much info over there.. Attached the logs WHEN THE TUNNEL IS UP, THE SAME IS THERE WHEN THE TUNNEL IS DOWN.
One more point which i have understood from the logs is that, the log " Failure during phase 1 rekeying attempt due to collision", indicates that
the ASA only supports two Phase-1 SAs at a time. If both the sides start a rekey at the same time then 3 SA will be present: (original plus two rekeys). As you can see this, when this occurs, the two direction collide and the rekey fails. And hence we get 3 different MM_roles in the "show crypto isakmp sa detail" out put of the Asa.
#sh cry isakmp sa
1 IKE Peer: 175.1.1.1
Type : L2L Role : responder
Rekey : yes State : MM_ACTIVE_REKEY
2 IKE Peer: 175.1.1.1
Type : L2L Role : responder
Rekey : no State : MM_REKEY_DONE_H2
3 IKE Peer: 175.1.1.1
Type : L2L Role : responder
Rekey : no State : MM_WAIT_MSG5
I dont know, why this is happening and how could we stop this?? Should we still reduce the p1 lifetime or should we change this to 0 ??
