IKEv2 keepalive tuning

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

IKEv2 keepalive tuning

L3 Networker

IKEv2 on PA has built in keepalive mechanism, but it can only act if the communication is lost for more than 5 minutes: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClgcCAC

After testing it out, about 7-8 minutes passed until Palo Alto detected lost peer and did reset of the tunnel.

That's happening due to built in algorithm:

The default interval of liveness checking is every 5 seconds when SA is idle. Upon losing connection, the firewall will do 10 liveness retries with increasing timeout (seconds) for each retry as follows:

 

1 + 2 + 4 + 8 + 16 + 32 + 64 + 64 + 64 + 64 = 319 seconds (about 5 minutes)

 

.. meaning it is not configurable in any way? Is there a way to speed it up?

Tunnel monitoring didn't seem to be an option, because tunnel is proxyID based and there are 4 proxyIDs configured - tunnel monitoring was working properly for one of them (source/destination pair), but at the same time concluded that other 3 of them are down and did the reset every 10 seconds or so which is not acceptable.

 

Basically, what are your options to detect the IPSec tunnel peer down condition and act as soon as possible, meaning, tear down the tunnel and start re-negotiation.

1 REPLY 1

Cyber Elite
Cyber Elite

@nikoo,


@nikoo wrote:

Basically, what are your options to detect the IPSec tunnel peer down condition and act as soon as possible, meaning, tear down the tunnel and start re-negotiation.


Scripting and the API. 

The best way that I've found to deal with something like this is having something on each end (can be as dumb as a raspberry pi) which is simply performing a basic ICMP check via a scheduled script. If the script notices a tunnel is down, then it goes out and clears the connection and starts a test to bring things back online and make it functional in the shortest timeframe possible.

The benefit of this type of solution is that the ICMP check itself in a lot of cases will cause enough traffic to keep all of the tunnels online baring an actual connectivity issue. 

  • 5020 Views
  • 1 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!