<?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: Internal NAT failover in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7298#M5406</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;But the issue is you'll have only one destination NAT rule to be matched no matter which server is the active one. That's why I suggest methods in "option 1" to have two routes to the Public IP (via Routing Protocols or PBF) with the goal of having a destination zone change that would allow us to match two different destination NAT rules&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 19 Sep 2014 04:52:14 GMT</pubDate>
    <dc:creator>xhoms</dc:creator>
    <dc:date>2014-09-19T04:52:14Z</dc:date>
    <item>
      <title>Internal NAT failover</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7293#M5401</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello all,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I was wondering if a certain scenario is possible through a Palo Alto PA-3020.&amp;nbsp; Say we have a single ISP with an internal NAT rule pointing to internal server A that is accessible by anyone in the outside world.&amp;nbsp; If server A ever goes down (or we take it offline), the internal NAT rule will failover to another internal NAT rule pointing to server B.&amp;nbsp; These two servers are not load balanced nor are they accessed at the same time by the outside world.&amp;nbsp; The same external IP address will be used to access whichever server is online but again never both at the same time and of course both servers have different internal IP addresses in the same subnet.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I'm thinking this would be accomplished with two NAT rules and one or two PBF rules.&amp;nbsp; What I am trying to figure out is how the Palo would know to use the other internal NAT rule if server A goes down.&amp;nbsp; Is something like this possible?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 18 Sep 2014 20:13:39 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7293#M5401</guid>
      <dc:creator>ClintL</dc:creator>
      <dc:date>2014-09-18T20:13:39Z</dc:date>
    </item>
    <item>
      <title>Re: Internal NAT failover</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7294#M5402</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I only see two options:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;If you could manage to have the public IP used by the outside world to reach the servers being dynamicaly learned by the PA-3020 using a routing protocol (i.e. RIP) from the servers, then you could put each server in a different security zone and use two destination NAT rules. But I guess the public IP you're using will have to be directly attached to the ISP facing interface, blocking this option.&lt;/LI&gt;&lt;LI&gt;To implement an external monitor that signals a configuration change using the PANOS Config API when any server becomes unreachable.&lt;/LI&gt;&lt;/OL&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 18 Sep 2014 20:31:43 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7294#M5402</guid>
      <dc:creator>xhoms</dc:creator>
      <dc:date>2014-09-18T20:31:43Z</dc:date>
    </item>
    <item>
      <title>Re: Internal NAT failover</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7295#M5403</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;There is the PBF+PathMonitoring alternative to routing protocols for option 1. But you still need the Public IP not to be directly connected to any PA-3020 interface.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 18 Sep 2014 23:28:52 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7295#M5403</guid>
      <dc:creator>xhoms</dc:creator>
      <dc:date>2014-09-18T23:28:52Z</dc:date>
    </item>
    <item>
      <title>Re: Internal NAT failover</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7296#M5404</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;A href="https://live.paloaltonetworks.com/u1/27897"&gt;ClintL&lt;/A&gt; You can look into clustering service on windows as an option.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 19 Sep 2014 00:00:36 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7296#M5404</guid>
      <dc:creator>bat</dc:creator>
      <dc:date>2014-09-19T00:00:36Z</dc:date>
    </item>
    <item>
      <title>Re: Internal NAT failover</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7297#M5405</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello Clint,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I think we can achieve this through a&amp;nbsp; PBF policy. We can configure a PBF policy for Primary Server with a monitor profile, pointing towards Primary servers IP address &lt;SPAN class="GINGER_SOFTWARE_mark"&gt;( &lt;/SPAN&gt;Since PBF will take precedence over routing)&amp;nbsp; and the backup server will be reachable through normal routing.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Once PBF will fail &lt;SPAN class="GINGER_SOFTWARE_mark"&gt;( &lt;/SPAN&gt;monitor IP not reachable), the traffic will start flowing through routing toward backup server.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 19 Sep 2014 00:10:08 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7297#M5405</guid>
      <dc:creator>HULK</dc:creator>
      <dc:date>2014-09-19T00:10:08Z</dc:date>
    </item>
    <item>
      <title>Re: Internal NAT failover</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7298#M5406</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;But the issue is you'll have only one destination NAT rule to be matched no matter which server is the active one. That's why I suggest methods in "option 1" to have two routes to the Public IP (via Routing Protocols or PBF) with the goal of having a destination zone change that would allow us to match two different destination NAT rules&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 19 Sep 2014 04:52:14 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7298#M5406</guid>
      <dc:creator>xhoms</dc:creator>
      <dc:date>2014-09-19T04:52:14Z</dc:date>
    </item>
    <item>
      <title>Re: Internal NAT failover</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7299#M5407</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi ClintL, &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Since the requirement is&amp;nbsp; to use only One public IP, (as far as I know) from configuration perspective on the PA 3020, I don't think this can be achieved unless you use different destination ports to identify the internal servers A and B that share the same public IP, say 1.1.1.1. In that case, the external hosts need to know that if server A is unreachable over the socket 1.1.1.1:xx, then use server B's socket 1.1.1.1:yy. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;As of now, fail-over or redundant NAT rules cannot be configured (meaning you cannot have two D-NAT rules pointing to the same public IP with different internal destination IP transalations unless you want to use destinaion IP and port translation)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Also, refer &lt;A href="https://live.paloaltonetworks.com/docs/DOC-1517"&gt;Understanding PAN-OS NAT&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks &lt;/P&gt;&lt;P&gt;Gayathri&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 19 Sep 2014 09:17:27 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7299#M5407</guid>
      <dc:creator>gchandrasekaran</dc:creator>
      <dc:date>2014-09-19T09:17:27Z</dc:date>
    </item>
    <item>
      <title>Re: Internal NAT failover</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7300#M5408</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;The functionality you're looking for is commonly found in load balancers.&amp;nbsp; Even if you can find a way to get this working with PBF+NAT+Monitoring+API+whatever, you'll ultimately be better served by using the right tool for the job.&amp;nbsp; &lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 19 Sep 2014 14:14:24 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7300#M5408</guid>
      <dc:creator>jvalentine</dc:creator>
      <dc:date>2014-09-19T14:14:24Z</dc:date>
    </item>
    <item>
      <title>Re: Internal NAT failover</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7301#M5409</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I appreciate the responses, guys.&amp;nbsp; Yeah this was one of those "figure out how the Palo can do this" by the higher ups but like it was mentioned the Palo isn't the best solution.&amp;nbsp; Thanks again and have a great weekend.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 19 Sep 2014 14:54:12 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7301#M5409</guid>
      <dc:creator>ClintL</dc:creator>
      <dc:date>2014-09-19T14:54:12Z</dc:date>
    </item>
    <item>
      <title>Re: Internal NAT failover</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7302#M5410</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;If budget is the problem there is a basic open source load balancer in the Zen project on source forge.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A href="http://sourceforge.net/projects/zenloadbalancer/" title="http://sourceforge.net/projects/zenloadbalancer/"&gt;Zen Load Balancer | SourceForge.net&lt;/A&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 20 Sep 2014 14:10:37 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7302#M5410</guid>
      <dc:creator>pulukas</dc:creator>
      <dc:date>2014-09-20T14:10:37Z</dc:date>
    </item>
    <item>
      <title>Re: Internal NAT failover</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7303#M5411</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Clintl,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You can also opt for F5, its one of the best load balancer in industry. A10 load balancere is cheaper one.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Hardik Shah&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 20 Sep 2014 14:27:58 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/internal-nat-failover/m-p/7303#M5411</guid>
      <dc:creator>hshah</dc:creator>
      <dc:date>2014-09-20T14:27:58Z</dc:date>
    </item>
  </channel>
</rss>

