IKE Phase 1 Timeout

Reply
L3 Networker

IKE Phase 1 Timeout

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

L6 Presenter

Re: IKE Phase 1 Timeout

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

L3 Networker

Re: IKE Phase 1 Timeout

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.

L6 Presenter

Re: IKE Phase 1 Timeout

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?

Highlighted
L2 Linker

Re: IKE Phase 1 Timeout

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

L3 Networker

Re: IKE Phase 1 Timeout

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.

L7 Applicator

Re: IKE Phase 1 Timeout

@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? 

L3 Networker

Re: IKE Phase 1 Timeout

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

L6 Presenter

Re: IKE Phase 1 Timeout

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.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!