<?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: Rekey causes VPN tunnel to stop sending network traffic in VM-Series in the Public Cloud</title>
    <link>https://live.paloaltonetworks.com/t5/vm-series-in-the-public-cloud/rekey-causes-vpn-tunnel-to-stop-sending-network-traffic/m-p/564809#M2025</link>
    <description>&lt;P&gt;Thought I'd reach out to see if you resolved this issue.&amp;nbsp; We are encountering something similar between a Palo VM500 running 10.2.6 and a Juniper SRX.&amp;nbsp; It appears on soft ipsec rekey that the Palo renews the SA and the Palo continues to use it, but the Juniper also creates a new SA (which the Palo sees and accepts) the Juniper uses this ipsec SA.&amp;nbsp; Hence dropping network traffic.&amp;nbsp; Would appreciate any thoughts you have.&lt;/P&gt;</description>
    <pubDate>Wed, 08 Nov 2023 14:11:25 GMT</pubDate>
    <dc:creator>JakeHarris</dc:creator>
    <dc:date>2023-11-08T14:11:25Z</dc:date>
    <item>
      <title>Rekey causes VPN tunnel to stop sending network traffic</title>
      <link>https://live.paloaltonetworks.com/t5/vm-series-in-the-public-cloud/rekey-causes-vpn-tunnel-to-stop-sending-network-traffic/m-p/427708#M1303</link>
      <description>&lt;DIV&gt;&lt;DIV class=""&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&lt;SPAN&gt;Hello everybody, I'm having a weird issue with VPNs between a Palo Alto Cloud Firewall (PanOS9.1.3h) and Cisco Meraki Z3.All VPN Tunnels are established propely, but after a random period of time during the rekey step, a tunnel stays online, but network traffic can't be send anymore. We are currently having 5 of these connections with the same issues.&amp;nbsp;&lt;/SPAN&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&lt;SPAN&gt;I was able to capture a log, but I'm not able to troubleshoot it. Did some anonymization, see link attached.&amp;nbsp;&lt;A title="LOG" href="https://easyupload.io/cknv6v" target="_self"&gt;LOG&lt;/A&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&lt;SPAN&gt;On the Meraki site/log, you can see the there are two steps happening repeatedly on a working tunnel.&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&amp;nbsp;&lt;/DIV&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;inbound CHILD_SA&lt;/DIV&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;outbound CHILD_SA&lt;/DIV&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&amp;nbsp;&lt;/DIV&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&lt;SPAN&gt;At the time the error occurs, the outbound step is missing.&lt;/SPAN&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&lt;SPAN&gt;Any ideas?&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&lt;SPAN&gt;Here are the tunnel settings IKEv2&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;On Palo side&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;&amp;nbsp;&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;IPSec Crypto profile&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;IPSec Protocol ESP&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;DH group 2&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;LT 1h&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Encryption aes-256-gcm/cbc&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Authentication&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;sha256&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;&amp;nbsp;&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;IKW Crypto profile&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;DH Group&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;group2&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Encryption&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;aes-256-cbc&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Authentication&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;sha 256&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Key LT 8h&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;IKEv2 Authentication Multiple 5&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;&amp;nbsp;&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;On Meraki side&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;&amp;nbsp;&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Phase1&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Encryption&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;AES 256&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Authentication&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;SHA256&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Pseudo-random Function&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Defaults to Authentication&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Diffie-Hellman group&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;2&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Lifetime (sec)&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;28800&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;&amp;nbsp;&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Phase2&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Encryption&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;AES 256&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Authentication&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;SHA256&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;PFS group&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;2&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Liftime (sec)&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;3600&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;&amp;nbsp;&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Palo Alto IKE GW Options&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Passive mode Enabled&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;NAT-T Enabled&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Advanced Option&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Strict Cookie Validation turned off&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Liveness Check&lt;/P&gt;&lt;P class="_1qeIAgB0cPwnLhDF9XSiJM"&gt;Interval (sec) 5&lt;/P&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;</description>
      <pubDate>Fri, 20 Aug 2021 10:33:45 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/vm-series-in-the-public-cloud/rekey-causes-vpn-tunnel-to-stop-sending-network-traffic/m-p/427708#M1303</guid>
      <dc:creator>JoschkaKruse</dc:creator>
      <dc:date>2021-08-20T10:33:45Z</dc:date>
    </item>
    <item>
      <title>Re: Rekey causes VPN tunnel to stop sending network traffic</title>
      <link>https://live.paloaltonetworks.com/t5/vm-series-in-the-public-cloud/rekey-causes-vpn-tunnel-to-stop-sending-network-traffic/m-p/564809#M2025</link>
      <description>&lt;P&gt;Thought I'd reach out to see if you resolved this issue.&amp;nbsp; We are encountering something similar between a Palo VM500 running 10.2.6 and a Juniper SRX.&amp;nbsp; It appears on soft ipsec rekey that the Palo renews the SA and the Palo continues to use it, but the Juniper also creates a new SA (which the Palo sees and accepts) the Juniper uses this ipsec SA.&amp;nbsp; Hence dropping network traffic.&amp;nbsp; Would appreciate any thoughts you have.&lt;/P&gt;</description>
      <pubDate>Wed, 08 Nov 2023 14:11:25 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/vm-series-in-the-public-cloud/rekey-causes-vpn-tunnel-to-stop-sending-network-traffic/m-p/564809#M2025</guid>
      <dc:creator>JakeHarris</dc:creator>
      <dc:date>2023-11-08T14:11:25Z</dc:date>
    </item>
    <item>
      <title>Re: Rekey causes VPN tunnel to stop sending network traffic</title>
      <link>https://live.paloaltonetworks.com/t5/vm-series-in-the-public-cloud/rekey-causes-vpn-tunnel-to-stop-sending-network-traffic/m-p/565816#M2035</link>
      <description>&lt;P&gt;Hi Jake,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;we ended up applying the latest firmware to both sides which stabilized the traffic. After updating we got rid off the hanging tunnels.&lt;/P&gt;</description>
      <pubDate>Wed, 15 Nov 2023 12:11:01 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/vm-series-in-the-public-cloud/rekey-causes-vpn-tunnel-to-stop-sending-network-traffic/m-p/565816#M2035</guid>
      <dc:creator>JoschkaKruse</dc:creator>
      <dc:date>2023-11-15T12:11:01Z</dc:date>
    </item>
  </channel>
</rss>

