<?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 / returning ESP packets dropped when terminating interface is in a different zone in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/ipsec-returning-esp-packets-dropped-when-terminating-interface/m-p/277725#M75488</link>
    <description>&lt;P&gt;if you can set the loopback in an IP range that is not configured on the external interface, this issue will likely not happen&lt;/P&gt;

&lt;P&gt;I suspect there is a conflict when the packet is received, the destination zone will be determined by using the routing table, the external interface is the actual owner of the ip subnet&lt;/P&gt;

&lt;P&gt;if you split up the external subnet and set one segment on the DMZ interface and then set up the loopback in that subnet with the dmz zone, there should not be an issue&lt;/P&gt;</description>
    <pubDate>Fri, 19 Jul 2019 11:53:41 GMT</pubDate>
    <dc:creator>reaper</dc:creator>
    <dc:date>2019-07-19T11:53:41Z</dc:date>
    <item>
      <title>IPSec / returning ESP packets dropped when terminating interface is in a different zone</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ipsec-returning-esp-packets-dropped-when-terminating-interface/m-p/276296#M75351</link>
      <description>&lt;P&gt;Hi all,&lt;/P&gt;&lt;P&gt;I have an IPSec tunnel connecting to an old SSG. Tunnel came up successfully and SSG can see the traffic and is returning correctly into the tunnel. However PAN's decrypt counter remains 0. When i did a packet capture, the returning ESP packet is dropped shown below Frame 43 and 47:&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="dropped-ESP.png" style="width: 999px;"&gt;&lt;img src="https://live.paloaltonetworks.com/t5/image/serverpage/image-id/20637i980ADBFB7ECDB04A/image-size/large/is-moderation-mode/true?v=v2&amp;amp;px=999" role="button" title="dropped-ESP.png" alt="dropped-ESP.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;The setup i have is:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;eth1/1 - ISP WAN in zone "outside"&lt;/LI&gt;&lt;LI&gt;loopback.1 - Public IP advertised by ISP in zone "dmz"&lt;/LI&gt;&lt;LI&gt;IPSec create similar to&amp;nbsp;&lt;A href="https://blog.webernetz.net/ipsec-site-to-site-vpn-palo-alto-juniper-screenos/" target="_blank" rel="noopener"&gt;https://blog.webernetz.net/ipsec-site-to-site-vpn-palo-alto-juniper-screenos/&lt;/A&gt;&lt;/LI&gt;&lt;LI&gt;tunnel.1 - in zone "trust"&lt;/LI&gt;&lt;LI&gt;both ends of tunnel is in "trust"&lt;/LI&gt;&lt;LI&gt;IPSec statuses all showing green&lt;/LI&gt;&lt;LI&gt;has policy from "outside" to "dmz" allowing any any from the two terminating IPs&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;When i change loopback.1 to zone "outside", everything works. Any suggestion or help is very much appreciated. Thanks in advance.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;TABLE&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD&gt;Model&lt;/TD&gt;&lt;TD&gt;PA-820&lt;/TD&gt;&lt;/TR&gt;&lt;TR&gt;&lt;TD&gt;Software Version&lt;/TD&gt;&lt;TD&gt;9.0.2-h4&lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thank you,&lt;BR /&gt;Jason&lt;/P&gt;</description>
      <pubDate>Fri, 12 Jul 2019 10:20:13 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ipsec-returning-esp-packets-dropped-when-terminating-interface/m-p/276296#M75351</guid>
      <dc:creator>jason.chia</dc:creator>
      <dc:date>2019-07-12T10:20:13Z</dc:date>
    </item>
    <item>
      <title>Re: IPSec / returning ESP packets dropped when terminating interface is in a different zone</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ipsec-returning-esp-packets-dropped-when-terminating-interface/m-p/277354#M75449</link>
      <description>&lt;P&gt;I'd recommend leaving the loopback on the untrust as that's the actual place where you want to terminate tunnels&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Is there a specifc use case for having it in DMZ on a loopback (just curious)&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;have you captured any global counters? these could tell you what exactly is causing the drop&lt;/P&gt;
&lt;PRE&gt;&amp;gt; debug dataplane packet-diag set filter match source &amp;lt;src&amp;gt; destination &amp;lt;dst&amp;gt;
&amp;gt; debug dataplane packet-diag set filter match source &amp;lt;dst&amp;gt; destination &amp;lt;src&amp;gt;
&amp;gt; debug dataplane packet-diag set filter on
&amp;gt; show counter global filter delta yes packet-filter yes (establishes the delta start)
&amp;gt; show counter global filter delta yes packet-filter yes &lt;/PRE&gt;</description>
      <pubDate>Thu, 18 Jul 2019 09:51:04 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ipsec-returning-esp-packets-dropped-when-terminating-interface/m-p/277354#M75449</guid>
      <dc:creator>reaper</dc:creator>
      <dc:date>2019-07-18T09:51:04Z</dc:date>
    </item>
    <item>
      <title>Re: IPSec / returning ESP packets dropped when terminating interface is in a different zone</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ipsec-returning-esp-packets-dropped-when-terminating-interface/m-p/277655#M75477</link>
      <description>&lt;P&gt;Thanks&amp;nbsp;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/7608"&gt;@reaper&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;the only reason is that address (subnet) is supposed to be a DMZ range.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I just found this&amp;nbsp;&lt;A href="https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClsiCAC" target="_blank" rel="noopener"&gt;https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClsiCAC&lt;/A&gt;&amp;nbsp;&lt;/P&gt;&lt;BLOCKQUOTE&gt;Cause&lt;P&gt;The issue is the tunnel terminates on an interface in a zone different from where the ESP (Encapsulation Security Payloads) packets originate.&lt;/P&gt;&lt;BR /&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;HR /&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;i'm curious as to why it is design this way.&lt;/P&gt;&lt;P&gt;and correct me if i'm wrong all IPSec tunnels have to terminate on the same zone as the one on the Internet?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;i'll get those global counters just to confirm the exact drops and update later.&lt;/P&gt;</description>
      <pubDate>Fri, 19 Jul 2019 01:36:00 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ipsec-returning-esp-packets-dropped-when-terminating-interface/m-p/277655#M75477</guid>
      <dc:creator>jason.chia</dc:creator>
      <dc:date>2019-07-19T01:36:00Z</dc:date>
    </item>
    <item>
      <title>Re: IPSec / returning ESP packets dropped when terminating interface is in a different zone</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/ipsec-returning-esp-packets-dropped-when-terminating-interface/m-p/277725#M75488</link>
      <description>&lt;P&gt;if you can set the loopback in an IP range that is not configured on the external interface, this issue will likely not happen&lt;/P&gt;

&lt;P&gt;I suspect there is a conflict when the packet is received, the destination zone will be determined by using the routing table, the external interface is the actual owner of the ip subnet&lt;/P&gt;

&lt;P&gt;if you split up the external subnet and set one segment on the DMZ interface and then set up the loopback in that subnet with the dmz zone, there should not be an issue&lt;/P&gt;</description>
      <pubDate>Fri, 19 Jul 2019 11:53:41 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/ipsec-returning-esp-packets-dropped-when-terminating-interface/m-p/277725#M75488</guid>
      <dc:creator>reaper</dc:creator>
      <dc:date>2019-07-19T11:53:41Z</dc:date>
    </item>
  </channel>
</rss>

