<?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 problems after RMA of an active-passive pair in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/problems-after-rma-of-an-active-passive-pair/m-p/524841#M108567</link>
    <description>&lt;P&gt;just to give a baseline - hardware are pa-5220, running 10.1.6-h6, HA (active/passive), device managed by Panorama.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Long story short - one of the firewalls got stuck on a reboot cycle where the firewall would reboot every 85 minutes. The data plane would not come up during this time and support processed a RMA.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;For the fun part:&lt;/P&gt;
&lt;P&gt;our initial attempt to restore, after upgrading the same software level as working firewall, we used a device state backup, everything sync up properly, when we tried to pass traffic through the new firewall we saw the following strange behavior:&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;source zone and destination zone was not showing up in the logs&lt;/LI&gt;
&lt;LI&gt;some zones were being identified but was incorrect, for instance DMZ, is showing up as Trust&lt;/LI&gt;
&lt;LI&gt;destination country was reporting incorrectly, for instance traffic for United States is showing up for Uruguay&lt;/LI&gt;
&lt;LI&gt;traffic seems to be flowing properly even though rules were not being identified in the logs&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;2nd restore attempt we used a back from a day before the firewall failed, we had no issues with synching up in this case as well. this gave us a better experience.&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;all traffic flows looks good on the log, zones and rules were being identified properly&lt;/LI&gt;
&lt;LI&gt;destination country looks good as well&lt;/LI&gt;
&lt;LI&gt;the one problem we noticed was that the IPSEC tunnels would not come up - after troubleshooting with support even a simple command "ping source x.x.x.x host y.y.y.y" where x.x.x.x is one of the firewall interface ip results in "bind: Cannot assign requested address". &amp;nbsp; We checked for "untagged sub interface" like suggested by others but none found.&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;Any feedback, suggestions would be appreciated. A TAC support is currently open and waiting feedback as well.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Thu, 22 Dec 2022 07:08:51 GMT</pubDate>
    <dc:creator>RREALICA</dc:creator>
    <dc:date>2022-12-22T07:08:51Z</dc:date>
    <item>
      <title>problems after RMA of an active-passive pair</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/problems-after-rma-of-an-active-passive-pair/m-p/524841#M108567</link>
      <description>&lt;P&gt;just to give a baseline - hardware are pa-5220, running 10.1.6-h6, HA (active/passive), device managed by Panorama.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Long story short - one of the firewalls got stuck on a reboot cycle where the firewall would reboot every 85 minutes. The data plane would not come up during this time and support processed a RMA.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;For the fun part:&lt;/P&gt;
&lt;P&gt;our initial attempt to restore, after upgrading the same software level as working firewall, we used a device state backup, everything sync up properly, when we tried to pass traffic through the new firewall we saw the following strange behavior:&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;source zone and destination zone was not showing up in the logs&lt;/LI&gt;
&lt;LI&gt;some zones were being identified but was incorrect, for instance DMZ, is showing up as Trust&lt;/LI&gt;
&lt;LI&gt;destination country was reporting incorrectly, for instance traffic for United States is showing up for Uruguay&lt;/LI&gt;
&lt;LI&gt;traffic seems to be flowing properly even though rules were not being identified in the logs&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;2nd restore attempt we used a back from a day before the firewall failed, we had no issues with synching up in this case as well. this gave us a better experience.&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;all traffic flows looks good on the log, zones and rules were being identified properly&lt;/LI&gt;
&lt;LI&gt;destination country looks good as well&lt;/LI&gt;
&lt;LI&gt;the one problem we noticed was that the IPSEC tunnels would not come up - after troubleshooting with support even a simple command "ping source x.x.x.x host y.y.y.y" where x.x.x.x is one of the firewall interface ip results in "bind: Cannot assign requested address". &amp;nbsp; We checked for "untagged sub interface" like suggested by others but none found.&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;Any feedback, suggestions would be appreciated. A TAC support is currently open and waiting feedback as well.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 22 Dec 2022 07:08:51 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/problems-after-rma-of-an-active-passive-pair/m-p/524841#M108567</guid>
      <dc:creator>RREALICA</dc:creator>
      <dc:date>2022-12-22T07:08:51Z</dc:date>
    </item>
    <item>
      <title>Re: problems after RMA of an active-passive pair</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/problems-after-rma-of-an-active-passive-pair/m-p/525205#M108623</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/87287"&gt;@RREALICA&lt;/a&gt;&amp;nbsp;,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Have you received any feedback from TAC yet?&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 27 Dec 2022 16:24:55 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/problems-after-rma-of-an-active-passive-pair/m-p/525205#M108623</guid>
      <dc:creator>JayGolf</dc:creator>
      <dc:date>2022-12-27T16:24:55Z</dc:date>
    </item>
    <item>
      <title>Re: problems after RMA of an active-passive pair</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/problems-after-rma-of-an-active-passive-pair/m-p/525382#M108652</link>
      <description>&lt;P&gt;Issues has been resolved - that's the good news. We are going to push to get a RCA in this case since the problems encountered does not seem normal.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;1. To fix the error "&lt;SPAN&gt;bind: Cannot assign requested address"- create a dummy/temporary L3 interface, commit, test and then remove&amp;nbsp;the dummy/temporary L3 interface. &amp;nbsp;No amount of reboots, "commit force" by different levels of TAC did not make a difference. Also TAC mentioned there's a cli command to refresh the interface and zones but we did not try this.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;2. Another problem came about where the IPSEC VPNs were not coming - this turns out&amp;nbsp;the ISAKMP process is not properly starting up or not listening for IPSEC traffic. &amp;nbsp;Check for ISAKMP via "show netstat listening yes | match isakmp" to see if the firewall is listening for&amp;nbsp;the traffic - restart of ISAKMP process resolved the issue - a reboot of the firewall also may have been best after fixing the interface related issues.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks.&lt;/P&gt;</description>
      <pubDate>Wed, 28 Dec 2022 16:57:51 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/problems-after-rma-of-an-active-passive-pair/m-p/525382#M108652</guid>
      <dc:creator>RREALICA</dc:creator>
      <dc:date>2022-12-28T16:57:51Z</dc:date>
    </item>
  </channel>
</rss>

