<?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 Problem with IPSec tunnel monitor in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/problem-with-ipsec-tunnel-monitor/m-p/24647#M17949</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;We have an issue with one IPSec site-to-site tunnel. The PAN usually doesn't recognize when a tunnel is down. We can correct this by setting up monitors on all tunnels with a "wait-recover" action after 3 subsequent failures. This works for all tunnels except one:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;please see tunnel config in attachments - for an unknown reason I cannot embed images with Google Chrome&amp;gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The special thing about this tunnel is the Proxy ID containing two public IP subnets. In order for communication to work correctly, we had to add a Source-NAT rule so that all traffic destined for 222.222.222.248/30 would be source-NATed to 111.111.111.214 before sent out of tunnel.8000 interface.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;With this setup, we can ping the IP address 222.222.222.249 without any problem. But it looks like the firewall itself can not. We assume that self-generated pings might use a different processing chain than other packets and might not get source-NATed. Anyhow, the problem is that the tunnel monitor pinging 222.222.222.249 times out after x subsequent failures and re-initializes the tunnel. This is pretty annoying.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Does anyone have an idea what we could do to setup a proper monitor for such a tunnel? Your help is much appreciated.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;Oliver&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 04 Dec 2012 17:36:13 GMT</pubDate>
    <dc:creator>oschuler</dc:creator>
    <dc:date>2012-12-04T17:36:13Z</dc:date>
    <item>
      <title>Problem with IPSec tunnel monitor</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/problem-with-ipsec-tunnel-monitor/m-p/24647#M17949</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;We have an issue with one IPSec site-to-site tunnel. The PAN usually doesn't recognize when a tunnel is down. We can correct this by setting up monitors on all tunnels with a "wait-recover" action after 3 subsequent failures. This works for all tunnels except one:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;please see tunnel config in attachments - for an unknown reason I cannot embed images with Google Chrome&amp;gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The special thing about this tunnel is the Proxy ID containing two public IP subnets. In order for communication to work correctly, we had to add a Source-NAT rule so that all traffic destined for 222.222.222.248/30 would be source-NATed to 111.111.111.214 before sent out of tunnel.8000 interface.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;With this setup, we can ping the IP address 222.222.222.249 without any problem. But it looks like the firewall itself can not. We assume that self-generated pings might use a different processing chain than other packets and might not get source-NATed. Anyhow, the problem is that the tunnel monitor pinging 222.222.222.249 times out after x subsequent failures and re-initializes the tunnel. This is pretty annoying.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Does anyone have an idea what we could do to setup a proper monitor for such a tunnel? Your help is much appreciated.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;Oliver&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 04 Dec 2012 17:36:13 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/problem-with-ipsec-tunnel-monitor/m-p/24647#M17949</guid>
      <dc:creator>oschuler</dc:creator>
      <dc:date>2012-12-04T17:36:13Z</dc:date>
    </item>
    <item>
      <title>Re: Problem with IPSec tunnel monitor</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/problem-with-ipsec-tunnel-monitor/m-p/24648#M17950</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Anyone any idea?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 10 Dec 2012 20:10:31 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/problem-with-ipsec-tunnel-monitor/m-p/24648#M17950</guid>
      <dc:creator>oschuler</dc:creator>
      <dc:date>2012-12-10T20:10:31Z</dc:date>
    </item>
    <item>
      <title>Re: Problem with IPSec tunnel monitor</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/problem-with-ipsec-tunnel-monitor/m-p/24649#M17951</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Place IP address on the tunnel interfaces on both end (i.e. 192.168.1.0/30, 192.168.1.1 on one side and 192.168.1.2 on the other side) and monitor the IP address on the other tunnel interface (i.e. 192.168.1.1 would monitor 192.168.1.2 and visa versa).&amp;nbsp; The 192.168.1.0/30 is a directly connected route.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 01 Nov 2013 14:26:38 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/problem-with-ipsec-tunnel-monitor/m-p/24649#M17951</guid>
      <dc:creator>JimS2</dc:creator>
      <dc:date>2013-11-01T14:26:38Z</dc:date>
    </item>
  </channel>
</rss>

