• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 4601
  • Last Modified:

VPN Tunnel Between 2 ASA 5520

Hi,

We have created VPN Tunnel between two ASA 5520 and it worked perfectly until we changed Peer IP.

Now we are getting this in debug

 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
 [IKEv1]: IP = XX.XXX.XXX.XXX, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
 [IKEv1]: IP = XX.XXX.XXX.XXX, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
 [IKEv1]: IP = XX.XXX.XXX.XXX, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 220
 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
 [IKEv1]: IP = XX.XXX.XXX.XXX, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
 [IKEv1 DEBUG]: IP = XX.XXX.XXX.XXX, IKE MM Initiator FSM error history (struct &0x100cce60)  <state>, <event>:  MM_DONE, EV_ERROR-->MM_WAIT_MSG2, EV_RETRY-->MM_WAIT_MSG2, EV_TIMEOUT-->MM_WAIT_MSG2, NullEvent-->MM_SND_MSG1, EV_SND_MSG-->MM_SND_MSG1, EV_START_TMR-->MM_SND_MSG1, EV_RESEND_MSG-->MM_WAIT_MSG2, EV_RETRY
 [IKEv1 DEBUG]: IP = XX.XXX.XXX.XXX, IKE SA MM:0d95302b terminating:  flags 0x01000022, refcnt 0, tuncnt 0
 [IKEv1 DEBUG]: IP = XX.XXX.XXX.XXX, sending delete/delete with reason message
 [IKEv1]: IP = XX.XXX.XXX.XXX, Removing peer from peer table failed, no match!
 [IKEv1]: IP = XX.XXX.XXX.XXX, Error: Unable to remove PeerTblEntry
 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
 [IKEv1]: IP = XX.XXX.XXX.XXX, IKE Initiator: New Phase 1, Intf inside, IKE Peer XX.XXX.XXX.XXX  local Proxy Address 10.1.68.0, remote Proxy Address 192.168.100.0,  Crypto map (outside_map)
 [IKEv1 DEBUG]: IP = XX.XXX.XXX.XXX, constructing ISAKMP SA payload
 [IKEv1 DEBUG]: IP = XX.XXX.XXX.XXX, constructing Fragmentation VID + extended capabilities payload
 [IKEv1]: IP = XX.XXX.XXX.XXX, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 220
 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0

some one please help to resolve this as quickly as possible.
0
amitabhg
Asked:
amitabhg
  • 12
  • 4
  • 2
  • +1
1 Solution
 
MultipathCommented:
Sounds like an SA issue.  You will need to wait for the SA to timeout or reboot both vpn peers and hope it resets the SA.  Otherwise you will have ot wait for hte timeout to hit.
0
 
MikeKaneCommented:
You can manually clear the existing SAs using:

      clear crypto isakmp saClears the Phase 1 SAs

      clear crypto ipsec saClears the Phase 2 SAs.

Then just let the tunnel re-establish with interesting traffic.
0
 
MikeKaneCommented:
BTW, you need to do that on both sides of the tunnel....   or just wait for the SA to timeout as mentioned.
0
Who's Defending Your Organization from Threats?

Protecting against advanced threats requires an IT dream team – a well-oiled machine of people and solutions working together to defend your organization. Download our resource kit today to learn more about the tools you need to build you IT Dream Team!

 
amitabhgAuthor Commented:
from last 12hrs  its in the same state  

can i do it tunnel wise...becuse we have nearly 12 vpn tunnels
0
 
amitabhgAuthor Commented:
Hi Mike,

ThanQ for your commands

no i am able to see

9   IKE Peer: XX.XXX.XXX.XXX
    Type    : L2L             Role    : responder
    Rekey   : no              State   : MM_ACTIVE

but still i am not able to communicate with other end IP's

i am getting this in debug crypto isakmp sa 127

[IKEv1]: IP = XX.XXX.XXX.XXX, IKE_DECODE RECEIVED Message (msgid=8c99557) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 84
[IKEv1 DEBUG]: Group = XX.XXX.XXX.XXX, IP = XX.XXX.XXX.XXX, processing hash payload
[IKEv1 DEBUG]: Group = XX.XXX.XXX.XXX, IP = XX.XXX.XXX.XXX, processing notify payload
[IKEv1 DEBUG]: Group = XX.XXX.XXX.XXX, IP = XX.XXX.XXX.XXX, Received keep-alive of type DPD R-U-THERE (seq number 0x3c480828)
[IKEv1 DEBUG]: Group = XX.XXX.XXX.XXX, IP = XX.XXX.XXX.XXX, Sending keep-alive of type DPD R-U-THERE-ACK (seq number 0x3c480828)
[IKEv1 DEBUG]: Group = XX.XXX.XXX.XXX, IP = XX.XXX.XXX.XXX, constructing blank hash payload
[IKEv1 DEBUG]: Group = XX.XXX.XXX.XXX, IP = XX.XXX.XXX.XXX, constructing qm hash payload
[IKEv1]: IP = XX.XXX.XXX.XXX, IKE_DECODE SENDING Message (msgid=199f6218) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 84


0
 
amitabhgAuthor Commented:
This is the config at both ends

My End Config:
access-list cellectivity extended permit ip 10.1.68.0 255.255.254.0 192.168.100.0 255.255.255.0

Phase I
authentication pre-share
encryption aes
hash sha
group 5
lifetime 43200

Phase II
crypto ipsec transform-set Myset_AES128 esp-aes esp-sha-hmac

crypto map outside_map 150 match address cellectivity
crypto map outside_map 150 set peer XX.XXX.XXX.XXX
crypto map outside_map 150 set transform-set Myset_AES128
crypto map outside_map 150 set security-association lifetime seconds 43200

tunnel-group XX.XXX.XXX.XXX type ipsec-l2l
tunnel-group XX.XXX.XXX.XXX ipsec-attributes
 pre-shared-key *
 isakmp keepalive threshold 10 retry 3

Other End Config
access-list nonat extended permit ip 192.168.100.0 255.255.255.0 10.1.68.0 255.255.254.0
crypto ipsec transform-set hyderabad-vpn-transform-set esp-aes esp-sha-hmac
crypto map hyderabad-vpn-map 20 match address hyderabad-vpn-acl
crypto map hyderabad-vpn-map 20 set peer XXX.XXX.XXX.X
crypto map hyderabad-vpn-map 20 set transform-set hyderabad-vpn-transform-set
crypto map hyderabad-vpn-map 20 set security-association lifetime seconds 43200
crypto map hyderabad-vpn-map interface outside
crypto isakmp identity address                                                                                            
crypto isakmp enable outside
crypto isakmp policy 20                                                                                                  
 authentication pre-share                                                                                                
 encryption aes                                                                                                          
 hash sha                                                                                                                
 group 5                                                                                                                  
 lifetime 43200
 tunnel-group XXX.XXX.XXX.X type ipsec-l2l
 tunnel-group XXX.XXX.XXX.X ipsec-attributes
 pre-shared-key *
 isakmp keepalive threshold 10 retry 3
0
 
MultipathCommented:
looks like a 12 hour SA look at it and make sure you are over 12 hours now.
0
 
amitabhgAuthor Commented:
Again i am getting same....


IKE Peer: XX.XXX.XXX.XXX
    Type    : user            Role    : initiator
    Rekey   : no              State   : MM_WAIT_MSG2

0
 
amitabhgAuthor Commented:
We restarted both end ASA's also...??

is there any solution for this..??
0
 
amitabhgAuthor Commented:
sh crypto ipsec sa peer XX.XXX.XXX.XXX
peer address: XX.XXX.XXX.XXX
    Crypto map tag: outside_map, seq num: 150, local addr: XX.XXX.XXX.X

      access-list cellectivity permit ip 10.1.68.0 255.255.254.0 192.168.100.0 255.255.255.0
      local ident (addr/mask/prot/port): (10.1.68.0/255.255.254.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
      current_peer: XX.XXX.XXX.XXX

      #pkts encaps: 1362, #pkts encrypt: 1362, #pkts digest: 1362
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 1362, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: XX.XXX.XXX.X, remote crypto endpt.: XX.XXX.XXX.XXX

      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: 40B32ADF

    inbound esp sas:
      spi: 0x187C6F57 (410808151)
         transform: esp-aes esp-sha-hmac none
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 20, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4275000/42275)
         IV size: 16 bytes
         replay detection support: Y
    outbound esp sas:
      spi: 0x40B32ADF (1085483743)
         transform: esp-aes esp-sha-hmac none
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 20, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4274888/42275)
         IV size: 16 bytes
         replay detection support: Y
0
 
amitabhgAuthor Commented:
is any one can tell what wrong with our config....??
0
 
MikeKaneCommented:
You can clear the 1 entry by using:
clear [crypto] ipsec sa entry <destination-address> protocol spi


However if you restarted both peers then this is no longer an issue since the Tunnels have just attempted to re-establish.  


Here, in your config:
My End Config:
access-list cellectivity extended permit ip 10.1.68.0 255.255.254.0 192.168.100.0 255.255.255.0

Do you have a nonat to match this entry?  

0
 
amitabhgAuthor Commented:
Yes

access-list vpn  extended permit ip 10.1.68.0 255.255.254.0 192.168.100.0 255.255.255.0
0
 
amitabhgAuthor Commented:
immediate help please........i am going to increase points from 500 to 1000
0
 
yashinchaladCommented:
can u please check/provide policy details at your end?
we had faced this issue before and found pfs to be the problem(it was missing at one end)
 
0
 
amitabhgAuthor Commented:
we are not using PFS at both ends.
0
 
amitabhgAuthor Commented:
could you please check above our both ends config
0
 
MikeKaneCommented:
You mentioned  
>Yes
>
>access-list vpn  extended permit ip 10.1.68.0 255.255.254.0 192.168.100.0 255.255.255.0

However, you need to make sure this ACL is nonatted.    Perhaps if you posted your entire config we could a better picture.   Both yours and the remote side would be ideal.
0
 
amitabhgAuthor Commented:
ThanX for your help we raised TAC with cisco they found other end router is blocking esp protocol  thats the reason packets decaps was not happend.

after allowing the esp protocal tunnel is working perfectly.

0

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 12
  • 4
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now