cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
306
Views
0
Helpful
3
Replies

Site to site VPN down have debug file

Andy White
Level 3
Level 3

Hello,

A site of ours has gone down and I think it is the other side as the other VPNs we have are fine, this is part of the debug from our ASA, can't see a reason, but phase 1 is down and can't contact the remote peer?

Feb 03 14:26:04 [IKEv1]IP = 82.141.21.123, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Feb 03 14:26:11 [IKEv1]IP = 82.141.21.123, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324
Feb 03 14:26:19 [IKEv1]IP = 82.141.21.123, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324
Feb 03 14:26:27 [IKEv1]IP = 82.141.21.123, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324
Feb 03 14:26:35 [IKEv1 DEBUG]IP = 82.141.21.123, IKE MM Initiator FSM error history (struct &0x77b81a28) <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
Feb 03 14:26:35 [IKEv1 DEBUG]IP = 82.141.21.123, IKE SA MM:b016bca4 terminating: flags 0x01000022, refcnt 0, tuncnt 0
Feb 03 14:26:35 [IKEv1 DEBUG]IP = 82.141.21.123, sending delete/delete with reason message
Feb 03 14:26:35 [IKEv1]IP = 82.141.21.123, IKE Initiator: New Phase 1, Intf rion_VLAN, IKE Peer 82.141.21.123 local Proxy Address 172.23.1.0, remote Proxy Address 10.102.16.0, Crypto map (outside_map)
Feb 03 14:26:35 [IKEv1 DEBUG]IP = 82.141.21.123, constructing ISAKMP SA payload
Feb 03 14:26:35 [IKEv1 DEBUG]IP = 82.141.21.123, constructing NAT-Traversal VID ver 02 payload
Feb 03 14:26:35 [IKEv1 DEBUG]IP = 82.141.21.123, constructing NAT-Traversal VID ver 03 payload
Feb 03 14:26:35 [IKEv1 DEBUG]IP = 82.141.21.123, constructing NAT-Traversal VID ver RFC payload
Feb 03 14:26:35 [IKEv1 DEBUG]IP = 82.141.21.123, constructing Fragmentation VID + extended capabilities payload
Feb 03 14:26:35 [IKEv1]IP = 82.141.21.123, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 324

Thanks

3 Replies 3

JP Miranda Z
Cisco Employee
Cisco Employee

Hi Andy,

Considering the tunnel is staying on WAIT_MSG2 i will recommend you to place a capture on the outside interface from public o public ip in order to find out if traffic in udp 500 or udp 4500 is flowing fine.

-JP-

Will do, thing is I have nearly 30 other VPNs and they are all fine plus client connections, it must be the other end, but the logs don't really show this do they?

Andy,

The logs are only showing the WAIT_MSG2 that normally means a problem to communicate with the peer on udp 500/4500, even if you have several tunnel when placing the capture you are only going to use the public ip of your device and the public ip of the remote end so you should only get captures of this specific traffic, is really important to place the captures on both sides but normally this happens because of a problem on the middle of the path(ISP or devices in front of the ASA or Router).