IKE Phase 1 Timeout

[palomed]

IKE is failing to negoriate phase 1.  I get this timeout and then a delete. Any thoughts on the possible cause? I'm thinking

the peer is perhaps not permitting the traffic from this device perhaps at a security device in front of their tunneling firewall (ASA). ?

May 11th 2017, 10:39:04.000 <14>May 11 10:39:04 172.19.5.38 prdfw100-pri.internal.foodahoo.com 1,2017/05/11 10:39:04,002201003116,SYSTEM,vpn,0,2017/05/11 10:39:04,,ike-nego-p1-fail,IKE-CostaRice-Scooby-GATEWAY,0,0,general,informational,"IKE phase-1 negotiation is failed as responder, main mode. Failed SA: 10.10.179.237.54[500]-100.100.102.52[500] cookie:1e341d416839:075a2865154b8d40. Due to timeout.",4906344,0x8000000000000000

[TranceforLife]

You are a responder, so IKE P1 traffic is initiated by the other side. When you responding back to the peer, traffic is matching already created session. Are you able to post the following commands output? :

> debug ike global on debug

> tail lines 50 mp-log ikemgr.log

> debug ike global on normal

[palomed]

I need to schedule another window for the setup. 😞 

Are you saying that it sounds like a three way handshake has occured such that my replies are getting back to the peer?

I'll definitely do the debug next go-around.

[TranceforLife]

IKE phase 1 (main mode/aggressive mode) is UDP src and dst port 500, so no 3-way handshake. 

 Failed SA: 10.10.179.237.54[500]-100.100.102.52[500]

What is your correct peer ip?  Are you behind the NAT?

[Ammar]

i am having the same issue since two days !!!

[palomed]

The peers are actually public IP's non-natted at each end. I do see that from the current ASA that I can ping the peer and from the PAN I can not. That could just be a red herring or perhaps there is a permission missing. Thanks for reminding me that the UDP 500 is what's coming in my direction initially so it's not a sign of a three way handshake.

[BPry]

@palomed,

This is likely not setup correctly because of the whole '10.10.179.237.54' issue. It looks like one of your devices is passing it's private address instead of it's public; your tunnel is likely setup with the peer being the public address and not '10.10.179.237.54'. If I would take a guess I would assume that the 10.10.179.237.54 address is your ASA correct? 

[palomed]

I'm just masking our address space by putting 10.x into one of the peers. It's actually a valid public IP.

[TranceforLife]

Correct. Ping simply could be disabled on the ASA external interface. Please provide more logs from the responder side (in our case it is Palo) and then we can go from there.