<?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: IPSec-ESP trough PA-7k only unidirectional best practice? Work around bug (ID:80950) in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/ipsec-esp-trough-pa-7k-only-unidirectional-best-practice-work/m-p/64317#M38586</link>
    <description>Hi Gerardo, thanks for your answer. Usual we do no NAT at all in the concerning environment. The IKE-part is not the problem. The PA-7k does IKE stateful but is not able to handle the ESP stateful. Most solutions I am aware of need either change the client to avoid using ESP and packing ESP in TCP or UDP. Allowing each ESP packet from outside is not a good option. Using a second Firewall like Juniper Netscreen or Juniper SRX to fix the PA-7k firewall is also a possible solution, but who can afford a second firewall to fix a PANW bug? Regards Winfried</description>
    <pubDate>Wed, 09 Sep 2015 08:05:59 GMT</pubDate>
    <dc:creator>Unibw</dc:creator>
    <dc:date>2015-09-09T08:05:59Z</dc:date>
    <item>
      <title>IPSec-ESP trough PA-7k only unidirectional best practice? Work around bug (ID:80950)</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ipsec-esp-trough-pa-7k-only-unidirectional-best-practice-work/m-p/63918#M38396</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;due to a bug (ID:80950), that PANW is not able to fix, it is necessary to create seperate IPSec-ESP policies for both directions trough the PA-7050.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;IPSec-ESP that comes in response to a opened session is being dropped if there is no separate policy for incomming ESP traffic.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Example:&lt;/P&gt;&lt;P&gt;-Client are allowed to open IPSec-Connections from "trust" to "untrust".&lt;/P&gt;&lt;P&gt;-You have to allow ESP also from "untrust" to "trust" for any adress a IPSec client might use&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;To avoid flooding, etc. from outside I am searching for solutions to avoid this.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Has any PA-7k admin found a valid approach?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;P&gt;Winfried&lt;/P&gt;</description>
      <pubDate>Tue, 01 Sep 2015 07:47:38 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ipsec-esp-trough-pa-7k-only-unidirectional-best-practice-work/m-p/63918#M38396</guid>
      <dc:creator>Unibw</dc:creator>
      <dc:date>2015-09-01T07:47:38Z</dc:date>
    </item>
    <item>
      <title>Re: IPSec-ESP trough PA-7k only unidirectional best practice? Work around bug (ID:80950)</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ipsec-esp-trough-pa-7k-only-unidirectional-best-practice-work/m-p/63957#M38420</link>
      <description>&lt;P&gt;Are you using hide-NAT to provide internet access?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Maybe using a Hide-NATfor the internal users you're allowing traffic to the untrust could workaround the issue, using NAT-transversal should encapsulate the traffic in UDP&amp;nbsp;instead of ESP and almost every vendor support it.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;You can find the NAT-transversal negotiation in the RFC&lt;/P&gt;&lt;P&gt;&lt;A href="https://tools.ietf.org/html/rfc3947#page-3" target="_blank"&gt;https://tools.ietf.org/html/rfc3947#page-3&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;so if you simply hide NAT the outgoing traffic from trust to untrust going to UDP port 500 should do the trick.&lt;/P&gt;&lt;P&gt;If you can control the client configuration use IKEv2 when possible, it's more resilent to DOS attacks.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Be careful because allowing outgoing ESP traffic gives the end user tha ability to bypass your company policy rules.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Gerardo.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 01 Sep 2015 17:27:51 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ipsec-esp-trough-pa-7k-only-unidirectional-best-practice-work/m-p/63957#M38420</guid>
      <dc:creator>glastra1</dc:creator>
      <dc:date>2015-09-01T17:27:51Z</dc:date>
    </item>
    <item>
      <title>Re: IPSec-ESP trough PA-7k only unidirectional best practice? Work around bug (ID:80950)</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ipsec-esp-trough-pa-7k-only-unidirectional-best-practice-work/m-p/64317#M38586</link>
      <description>Hi Gerardo, thanks for your answer. Usual we do no NAT at all in the concerning environment. The IKE-part is not the problem. The PA-7k does IKE stateful but is not able to handle the ESP stateful. Most solutions I am aware of need either change the client to avoid using ESP and packing ESP in TCP or UDP. Allowing each ESP packet from outside is not a good option. Using a second Firewall like Juniper Netscreen or Juniper SRX to fix the PA-7k firewall is also a possible solution, but who can afford a second firewall to fix a PANW bug? Regards Winfried</description>
      <pubDate>Wed, 09 Sep 2015 08:05:59 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ipsec-esp-trough-pa-7k-only-unidirectional-best-practice-work/m-p/64317#M38586</guid>
      <dc:creator>Unibw</dc:creator>
      <dc:date>2015-09-09T08:05:59Z</dc:date>
    </item>
  </channel>
</rss>

