cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
760
Views
5
Helpful
3
Replies
Beginner

Cisco ASA VPN phase 2 down

Hello,

I have a site to site VPN in working condition however when one of the two network object was removed on each ends, the VPN is non-functional. The subnet was removed on both ends and currently I am seeing phase 1 up but phase 2 is down.

When I type show crypto ipsec sa peer , I do not find any ipsec sa formation. Phase 1 is still up.


Please see logs below :


"IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=1, saddr=172.16.XX.XX, sport=5376, daddr=10.176.255.254, dport=5376

IPSEC(crypto_map_check)-3: Checking crypto map mymap 127: matched.

Jan 19 10:20:37 [IKEv1 DEBUG]Pitcher: received a key acquire message, spi 0x0

IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=1, saddr=172.16.28.162, sport=5376, daddr=10.176.255.254, dport=5376

IPSEC(crypto_map_check)-3: Checking crypto map mymap 127: matched.

 [IKEv1]IP = 8.39.XX.XX, IKE Initiator: New Phase 1, Intf inside, IKE Peer 8.39.XX.XX local Proxy Address 172.16.28.0, remote Proxy Address 10.176.0.0, Crypto map (mymap)

 [IKEv1 DEBUG]IP = 8.39.XX.XX, constructing ISAKMP SA payload

 [IKEv1 DEBUG]IP = 8.39.XX.XX, constructing NAT-Traversal VID ver 02 payload

 [IKEv1 DEBUG]IP = 8.39.XX.XX, constructing NAT-Traversal VID ver 03 payload

 [IKEv1 DEBUG]IP = 8.39.XX.XX, constructing NAT-Traversal VID ver RFC payload

 [IKEv1 DEBUG]IP = 8.39.XX.XX, constructing Fragmentation VID + extended capabilities payload

 [IKEv1]IP = 8.39.XX.XX, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 552

 [IKEv1]IKE Receiver: Packet received on 10.230.1.123:500 from 8.39.XX.XX:500

 [IKEv1]IP = 8.39.XX.XX, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 108

 [IKEv1 DEBUG]IP = 8.39.XX.XX, processing SA payload
 [IKEv1 DEBUG]IP = 8.39.XX.XX, Oakley proposal is acceptable
 [IKEv1 DEBUG]IP = 8.39.XX.XX, processing VID payload

 [IKEv1 DEBUG]IP = 8.39.XX.XX, Received NAT-Traversal RFC VID

[IKEv1 DEBUG]IP = 8.39.XX.XX, constructing ke payload

 [IKEv1 DEBUG]IP = 8.39.XX.XX, constructing nonce payload
 [IKEv1 DEBUG]IP = 8.39.XX.XX, constructing Cisco Unity VID payload

 [IKEv1 DEBUG]IP = 8.39.XX.XX, constructing xauth V6 VID payload
 [IKEv1 DEBUG]IP = 8.39.XX.XX, Send IOS VID

 [IKEv1 DEBUG]IP = 8.39.XX.XX, Constructing ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)

[IKEv1 DEBUG]IP = 8.39.XX.XX, constructing VID payload

 [IKEv1 DEBUG]IP = 8.39.XX.XX, Send Altiga/Cisco VPN3000/Cisco ASA GW VID

 [IKEv1 DEBUG]IP = 8.39.XX.XX, constructing NAT-Discovery payload

 [IKEv1 DEBUG]IP = 8.39.XX.XX, computing NAT Discovery hash

 [IKEv1 DEBUG]IP = 8.39.XX.XX, constructing NAT-Discovery payload

 [IKEv1 DEBUG]IP = 8.39.XX.XX, computing NAT Discovery hash

[IKEv1]IP = 8.39.XX.XX, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (20) + NAT-D (20) + NONE (0) total length : 304

[IKEv1]IKE Receiver: Packet received on 10.230.1.123:500 from 8.39.XX.XX:500

 [IKEv1]IP = 8.39.XX.XX, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (20) + NAT-D (20) + NONE (0) total length : 304

 [IKEv1 DEBUG]IP = 8.39.XX.XX, processing ke payload"

Everyone's tags (1)
3 REPLIES 3
Highlighted
Beginner

Hi ,

Hi ,

i think this will be up till the lifetime as you mentioned on Phase 1. 

thanks,

Mani.P

Beginner

Hello Mani,

Hello Mani,

Thanks for your reply.
Phase 1 of VPN is constant. I do not see any impact of lifetime. Phase 2 never came up once the ACL/Network object was changed on either ends.

Regards,

Jay Joshi

Beginner

This VPN is configured

This VPN is configured between a router and a firewall (ASAv). The reason why phase two did not come up because ASAv was not able to initiate the VPN because of NAT rule configured on ASAv - this created a mismatch of IP addresses.

When the VPN was initiated from router, VPN came up. As a permanent solution to this, match identity address 0.0.0.0 had to be added on router.