<?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: PA1420 IKE packet disappear between receive (ingress) and firewall session state in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/pa1420-ike-packet-disappear-between-receive-ingress-and-firewall/m-p/1249365#M126083</link>
    <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/23308"&gt;@LJenne&lt;/a&gt;&amp;nbsp;,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-end="379" data-start="164"&gt;Which panos are you running? &lt;BR /&gt;&lt;BR /&gt;Based on what you shared, it looks like you’ve already covered the right troubleshooting steps (session lookup, dataplane capture stages, verifying ISP connectivity), so you’re definitely looking in the right areas&lt;/P&gt;
&lt;P data-end="379" data-start="164"&gt;.&lt;/P&gt;
&lt;P data-end="669" data-start="328"&gt;Packets showing up in rx but never reaching the fw stage, and not appearing in drop, makes me suspect something may be hiccuping in the dataplane processing stage. Since the issue cleared after rebooting the cluster, that makes me think even more of being state-related vs a config issue.&lt;/P&gt;
&lt;P data-end="669" data-start="328"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-is-only-node="" data-is-last-node="" data-end="1012" data-start="671"&gt;In this situation I’d recommend opening a TAC case, especially given the previous UDP drop issue you referenced. If it happens again, collecting a tech support file, dataplane pcaps, global counters, and timestamps while the issue is active will give TAC the best chance of identifying where the packets are being dropped internally.&lt;/P&gt;
&lt;P data-is-only-node="" data-is-last-node="" data-end="1012" data-start="671"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-is-only-node="" data-is-last-node="" data-end="1012" data-start="671"&gt;Please keep us updated as your case progresses!&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Wed, 04 Mar 2026 03:07:54 GMT</pubDate>
    <dc:creator>JayGolf</dc:creator>
    <dc:date>2026-03-04T03:07:54Z</dc:date>
    <item>
      <title>PA1420 IKE packet disappear between receive (ingress) and firewall session state</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/pa1420-ike-packet-disappear-between-receive-ingress-and-firewall/m-p/1249126#M126067</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;we have an PA-1420 Active/Passive HA-Cluster. Behind that Cluster we also use a Cisco FirePower 1150 as our VPN-Gateway, so IKE traffic (udp-500 and udp-4500) is passing our PA-1420. Our PA-1420 has to ISP connections for failover, both are dedicated interfaces eth1/1 ISP1 (primary) and eth1/2 ISP2 (backup).&lt;/P&gt;
&lt;P&gt;Our VPN-Tunnels on the Cisco FirePower are configured with failover, so if ISP1 is down, the VPN-Gateways doing failover for their VPN-Tunnels over ISP2.&lt;/P&gt;
&lt;P&gt;We installed and configured the PA-1420 Cluster about half a year ago. When switching to the new PA-1420 from our old PA-3220 we got issues with our VPN-Tunnels that did not work any more. We figured out that we were running in the "firewall starts to drop UDP packets bug" mentioned here:&lt;/P&gt;
&lt;P&gt;&lt;A href="https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVHCA0&amp;amp;" target="_blank"&gt;https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVHCA0&amp;amp;&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;Our solution was to reboot both firewalls at the same time. After that the VPN-Tunnel came up and everything worked fine since yesterday.&lt;/P&gt;
&lt;P&gt;Yesterday suddenly nearly all our VPN-Tunnels lost connection over ISP1 and switched their tunnels to ISP2 (backup). Everything else (internet proxy, client-vpn-connections, public webservers) was still working over ISP1, so there was no ISP issue. The switched VPN-Tunnels over ISP2 were working without any problems.&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;&lt;SPAN class="richTextArea slds-text-longform tile__title red-txt"&gt;We could not see any IKE sessions over ISP1 in our Traffic or unified logs altough we log them on session start.&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;&lt;SPAN class="richTextArea slds-text-longform tile__title red-txt"&gt;The command "show session all filter source &amp;lt;&amp;lt;public-ip-isp1&amp;gt;&amp;gt; destination &amp;lt;&amp;lt;public-ip-vpn-gateway-partner&amp;gt;&amp;gt; did show an active session between the 2 public ip addresses for the IKE protocol.&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;We then took some packet captures on the PA-1420 and figured out, that the IKE packets to the public ip address of ISP1 were visible at the packet capture stage "receive".&lt;/P&gt;
&lt;P&gt;At the stage "firewall" they seem to disappear and never show up. But this time, they were also not visible at the stage "drop" (in contrast to the problem we had half a year ago, were the drops were visible at the "drop stage"). Also this time we did not have any sessions in "discard state" as mentioned in the KB article above.&lt;/P&gt;
&lt;P&gt;We have tried a few things but only the reboot of the whole firewall-cluster at the same time helped to resolve the problem and got the VPN-Tunnel over ISP1 (eth1/1) back to work.&lt;/P&gt;
&lt;P&gt;Did anybody else have any similar problems? For us it seemed that the problem only appeared on interface eth1/1 for ISP1.&amp;nbsp;This behaviour did not feel good to us because we did not see any issues in the pcaps except that the packets completely disappeared. We did not do any change to our zone protection settings.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Do you recommend to open a case with Palo Alto? Our fear is, that this problem will come back again and rebooting the whole palo alto cluster at office times is a big problem for us.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks,&lt;/P&gt;
&lt;P&gt;Lukas&lt;/P&gt;</description>
      <pubDate>Fri, 27 Feb 2026 10:59:08 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/pa1420-ike-packet-disappear-between-receive-ingress-and-firewall/m-p/1249126#M126067</guid>
      <dc:creator>LJenne</dc:creator>
      <dc:date>2026-02-27T10:59:08Z</dc:date>
    </item>
    <item>
      <title>Re: PA1420 IKE packet disappear between receive (ingress) and firewall session state</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/pa1420-ike-packet-disappear-between-receive-ingress-and-firewall/m-p/1249365#M126083</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/23308"&gt;@LJenne&lt;/a&gt;&amp;nbsp;,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-end="379" data-start="164"&gt;Which panos are you running? &lt;BR /&gt;&lt;BR /&gt;Based on what you shared, it looks like you’ve already covered the right troubleshooting steps (session lookup, dataplane capture stages, verifying ISP connectivity), so you’re definitely looking in the right areas&lt;/P&gt;
&lt;P data-end="379" data-start="164"&gt;.&lt;/P&gt;
&lt;P data-end="669" data-start="328"&gt;Packets showing up in rx but never reaching the fw stage, and not appearing in drop, makes me suspect something may be hiccuping in the dataplane processing stage. Since the issue cleared after rebooting the cluster, that makes me think even more of being state-related vs a config issue.&lt;/P&gt;
&lt;P data-end="669" data-start="328"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-is-only-node="" data-is-last-node="" data-end="1012" data-start="671"&gt;In this situation I’d recommend opening a TAC case, especially given the previous UDP drop issue you referenced. If it happens again, collecting a tech support file, dataplane pcaps, global counters, and timestamps while the issue is active will give TAC the best chance of identifying where the packets are being dropped internally.&lt;/P&gt;
&lt;P data-is-only-node="" data-is-last-node="" data-end="1012" data-start="671"&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-is-only-node="" data-is-last-node="" data-end="1012" data-start="671"&gt;Please keep us updated as your case progresses!&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 04 Mar 2026 03:07:54 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/pa1420-ike-packet-disappear-between-receive-ingress-and-firewall/m-p/1249365#M126083</guid>
      <dc:creator>JayGolf</dc:creator>
      <dc:date>2026-03-04T03:07:54Z</dc:date>
    </item>
  </channel>
</rss>

