<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: IKEv2 keepalive tuning in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/ikev2-keepalive-tuning/m-p/342674#M85856</link>
    <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/42773"&gt;@nikoo&lt;/a&gt;,&lt;/P&gt;
&lt;BLOCKQUOTE&gt;&lt;HR /&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/42773"&gt;@nikoo&lt;/a&gt;&amp;nbsp;wrote:
&lt;P&gt;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.&lt;/P&gt;
&lt;HR /&gt;&lt;/BLOCKQUOTE&gt;
&lt;P&gt;Scripting and the API.&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;
&lt;P&gt;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.&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Fri, 07 Aug 2020 12:46:41 GMT</pubDate>
    <dc:creator>BPry</dc:creator>
    <dc:date>2020-08-07T12:46:41Z</dc:date>
    <item>
      <title>IKEv2 keepalive tuning</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ikev2-keepalive-tuning/m-p/342647#M85854</link>
      <description>&lt;P&gt;IKEv2 on PA has built in keepalive mechanism, but it can only act if the communication is lost for more than 5 minutes:&amp;nbsp;&lt;A href="https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClgcCAC" target="_blank"&gt;https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClgcCAC&lt;/A&gt;&lt;/P&gt;&lt;P&gt;After testing it out, about 7-8 minutes passed until Palo Alto detected lost peer and did reset of the tunnel.&lt;/P&gt;&lt;P&gt;That's happening due to built in algorithm:&lt;/P&gt;&lt;P&gt;&lt;EM&gt;The default interval of liveness checking is every 5 seconds when SA is idle.&amp;nbsp;Upon losing connection, the firewall will do 10 liveness retries with increasing timeout (seconds) for each retry as follows:&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;1 + 2 + 4 + 8 + 16 + 32 + 64 + 64 + 64 + 64 = 319 seconds (about 5 minutes)&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;.. meaning it is not configurable in any way? Is there a way to speed it up?&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;</description>
      <pubDate>Fri, 07 Aug 2020 11:05:56 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ikev2-keepalive-tuning/m-p/342647#M85854</guid>
      <dc:creator>nikoo</dc:creator>
      <dc:date>2020-08-07T11:05:56Z</dc:date>
    </item>
    <item>
      <title>Re: IKEv2 keepalive tuning</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ikev2-keepalive-tuning/m-p/342674#M85856</link>
      <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/42773"&gt;@nikoo&lt;/a&gt;,&lt;/P&gt;
&lt;BLOCKQUOTE&gt;&lt;HR /&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/42773"&gt;@nikoo&lt;/a&gt;&amp;nbsp;wrote:
&lt;P&gt;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.&lt;/P&gt;
&lt;HR /&gt;&lt;/BLOCKQUOTE&gt;
&lt;P&gt;Scripting and the API.&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;
&lt;P&gt;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.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 07 Aug 2020 12:46:41 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ikev2-keepalive-tuning/m-p/342674#M85856</guid>
      <dc:creator>BPry</dc:creator>
      <dc:date>2020-08-07T12:46:41Z</dc:date>
    </item>
  </channel>
</rss>

