IKE Phase 1 Timeout

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

IKE Phase 1 Timeout

L3 Networker

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

8 REPLIES 8

L6 Presenter

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

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.

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?

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

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.

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

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

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.

  • 6191 Views
  • 8 replies
  • 0 Likes
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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!