<?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 Migration from Cisco ASA to PAN: Outbound rules in Expedition Discussions</title>
    <link>https://live.paloaltonetworks.com/t5/expedition-discussions/migration-from-cisco-asa-to-pan-outbound-rules/m-p/518211#M4225</link>
    <description>&lt;P&gt;Hey everyone,&lt;/P&gt;
&lt;P&gt;I am currently trying to migrate a configuration of a Cisco ASA to PAN using Expedition.&lt;/P&gt;
&lt;P&gt;Unfortunately the customer is not only using the "normal" inbound rules on ASA but also outbound rules.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;ASA rule processing is a bit different from PAN:&lt;/P&gt;
&lt;P&gt;Packet arrives from source (maybe 10.1.1.1) on interface 1/1 -&amp;gt; Packet is send through inbound rules of ingress interface -&amp;gt; Routing etc. -&amp;gt;&amp;nbsp;Packet is send through outbound rules of egress interface -&amp;gt; Packet is send to the destination (maybe 10.2.2.2) on interface 1/2.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;It could be that there is a inbound rule on interface 1/1 like that:&lt;/P&gt;
&lt;P&gt;Source 10.1.1.1&lt;/P&gt;
&lt;P&gt;Destination any&lt;/P&gt;
&lt;P&gt;Service any&lt;/P&gt;
&lt;P&gt;Action allow&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;On interface 1/2 there could be an outbound rule like:&lt;/P&gt;
&lt;P&gt;Source 10.1.1.1&lt;/P&gt;
&lt;P&gt;Destination 10.2.2.2&lt;/P&gt;
&lt;P&gt;Service tcp-22&lt;/P&gt;
&lt;P&gt;Action allow&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;And sometimes it is the other way around (inbound rule more specific than outbound rule).&lt;/P&gt;
&lt;P&gt;In some rare cases there are exact matches (same rule on one interface inbound and another one outbound).&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Expedition handles all inbound and outbound rules as security policies and writes them all into the PAN ruleset in a top-down-way.&lt;/P&gt;
&lt;P&gt;This results in a ruleset that is different from the one on the ASA.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;In the example above, if the inbound rule is matched first, the destination 10.1.1.1 would be allowed to communicate everywhere on the PAN.&lt;BR /&gt;But on the ASA the traffic would go the outbound rules later on and would eventually be blocked based on that.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Is there any way in Expedition to match the incoming and outgoing rules together in order to create rules for the PAN that would result in the same security level like the ASA ruleset with both type of rules?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Any hint is highly appreciated.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks,&lt;BR /&gt;Tim&lt;/P&gt;</description>
    <pubDate>Tue, 18 Oct 2022 11:26:26 GMT</pubDate>
    <dc:creator>Tim_Adelmann</dc:creator>
    <dc:date>2022-10-18T11:26:26Z</dc:date>
    <item>
      <title>Migration from Cisco ASA to PAN: Outbound rules</title>
      <link>https://live.paloaltonetworks.com/t5/expedition-discussions/migration-from-cisco-asa-to-pan-outbound-rules/m-p/518211#M4225</link>
      <description>&lt;P&gt;Hey everyone,&lt;/P&gt;
&lt;P&gt;I am currently trying to migrate a configuration of a Cisco ASA to PAN using Expedition.&lt;/P&gt;
&lt;P&gt;Unfortunately the customer is not only using the "normal" inbound rules on ASA but also outbound rules.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;ASA rule processing is a bit different from PAN:&lt;/P&gt;
&lt;P&gt;Packet arrives from source (maybe 10.1.1.1) on interface 1/1 -&amp;gt; Packet is send through inbound rules of ingress interface -&amp;gt; Routing etc. -&amp;gt;&amp;nbsp;Packet is send through outbound rules of egress interface -&amp;gt; Packet is send to the destination (maybe 10.2.2.2) on interface 1/2.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;It could be that there is a inbound rule on interface 1/1 like that:&lt;/P&gt;
&lt;P&gt;Source 10.1.1.1&lt;/P&gt;
&lt;P&gt;Destination any&lt;/P&gt;
&lt;P&gt;Service any&lt;/P&gt;
&lt;P&gt;Action allow&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;On interface 1/2 there could be an outbound rule like:&lt;/P&gt;
&lt;P&gt;Source 10.1.1.1&lt;/P&gt;
&lt;P&gt;Destination 10.2.2.2&lt;/P&gt;
&lt;P&gt;Service tcp-22&lt;/P&gt;
&lt;P&gt;Action allow&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;And sometimes it is the other way around (inbound rule more specific than outbound rule).&lt;/P&gt;
&lt;P&gt;In some rare cases there are exact matches (same rule on one interface inbound and another one outbound).&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Expedition handles all inbound and outbound rules as security policies and writes them all into the PAN ruleset in a top-down-way.&lt;/P&gt;
&lt;P&gt;This results in a ruleset that is different from the one on the ASA.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;In the example above, if the inbound rule is matched first, the destination 10.1.1.1 would be allowed to communicate everywhere on the PAN.&lt;BR /&gt;But on the ASA the traffic would go the outbound rules later on and would eventually be blocked based on that.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Is there any way in Expedition to match the incoming and outgoing rules together in order to create rules for the PAN that would result in the same security level like the ASA ruleset with both type of rules?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Any hint is highly appreciated.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks,&lt;BR /&gt;Tim&lt;/P&gt;</description>
      <pubDate>Tue, 18 Oct 2022 11:26:26 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/expedition-discussions/migration-from-cisco-asa-to-pan-outbound-rules/m-p/518211#M4225</guid>
      <dc:creator>Tim_Adelmann</dc:creator>
      <dc:date>2022-10-18T11:26:26Z</dc:date>
    </item>
  </channel>
</rss>

