<?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: Firewall migration, testing rules in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/firewall-migration-testing-rules/m-p/249761#M71023</link>
    <description>&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;One&amp;nbsp;way would be a VirtualWire with the last policy set as ANY/ANY. This way you can see if any traffic hits the last policy and if a policy needs to be rewritten.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hope that helps.&lt;/P&gt;</description>
    <pubDate>Mon, 11 Feb 2019 21:48:28 GMT</pubDate>
    <dc:creator>OtakarKlier</dc:creator>
    <dc:date>2019-02-11T21:48:28Z</dc:date>
    <item>
      <title>Firewall migration, testing rules</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/firewall-migration-testing-rules/m-p/249753#M71021</link>
      <description>&lt;P&gt;Is there a way to test the rules on a new Palo alto vs the existing firewall it will be replacing without affecting traffic? Something like TAP mode but that can block traffic like an in production firewall?&lt;/P&gt;</description>
      <pubDate>Mon, 11 Feb 2019 21:33:46 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/firewall-migration-testing-rules/m-p/249753#M71021</guid>
      <dc:creator>gonzox98</dc:creator>
      <dc:date>2019-02-11T21:33:46Z</dc:date>
    </item>
    <item>
      <title>Re: Firewall migration, testing rules</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/firewall-migration-testing-rules/m-p/249761#M71023</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;One&amp;nbsp;way would be a VirtualWire with the last policy set as ANY/ANY. This way you can see if any traffic hits the last policy and if a policy needs to be rewritten.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hope that helps.&lt;/P&gt;</description>
      <pubDate>Mon, 11 Feb 2019 21:48:28 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/firewall-migration-testing-rules/m-p/249761#M71023</guid>
      <dc:creator>OtakarKlier</dc:creator>
      <dc:date>2019-02-11T21:48:28Z</dc:date>
    </item>
    <item>
      <title>Re: Firewall migration, testing rules</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/firewall-migration-testing-rules/m-p/249783#M71030</link>
      <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/106758"&gt;@gonzox98&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;Generally, during migration, a vwire configuration would be utilized as&amp;nbsp;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/27580"&gt;@OtakarKlier&lt;/a&gt;&amp;nbsp;already mentioned. I'm personally not a huge fan of this method as it leaves a bit of cleanup work when moving to l2 or l3 routing in the final implementation. You could implement the firewall as you want to in your final design, and then simply enable 'temp' allow policies that you can monitor in the logs and build out policies as you identify additional traffic you need to allow.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 12 Feb 2019 03:57:22 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/firewall-migration-testing-rules/m-p/249783#M71030</guid>
      <dc:creator>BPry</dc:creator>
      <dc:date>2019-02-12T03:57:22Z</dc:date>
    </item>
  </channel>
</rss>

