Cisco ASA VPN phase 2 down

Jay Joshi · ‎01-19-2017

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"

MANI .P · ‎01-19-2017

Hi ,

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

thanks,

Mani.P

Jay Joshi · ‎01-19-2017

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

Jay Joshi · ‎03-17-2017

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.