- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
09-18-2014 01:13 PM
Hello all,
I was wondering if a certain scenario is possible through a Palo Alto PA-3020. 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. 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. These two servers are not load balanced nor are they accessed at the same time by the outside world. 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.
I'm thinking this would be accomplished with two NAT rules and one or two PBF rules. 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. Is something like this possible?
09-19-2014 07:14 AM
The functionality you're looking for is commonly found in load balancers. 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.
09-18-2014 01:31 PM
I only see two options:
09-18-2014 04:28 PM
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.
09-18-2014 05:00 PM
ClintL You can look into clustering service on windows as an option.
09-18-2014 05:10 PM
Hello Clint,
I think we can achieve this through a PBF policy. We can configure a PBF policy for Primary Server with a monitor profile, pointing towards Primary servers IP address ( Since PBF will take precedence over routing) and the backup server will be reachable through normal routing.
Once PBF will fail ( monitor IP not reachable), the traffic will start flowing through routing toward backup server.
Thanks
09-18-2014 09:52 PM
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
09-19-2014 02:17 AM
Hi ClintL,
Since the requirement is 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.
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)
Also, refer Understanding PAN-OS NAT
Thanks
Gayathri
09-19-2014 07:14 AM
The functionality you're looking for is commonly found in load balancers. 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.
09-19-2014 07:54 AM
I appreciate the responses, guys. 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. Thanks again and have a great weekend.
09-20-2014 07:10 AM
If budget is the problem there is a basic open source load balancer in the Zen project on source forge.
Zen Load Balancer | SourceForge.net
09-20-2014 07:27 AM
Hi Clintl,
You can also opt for F5, its one of the best load balancer in industry. A10 load balancere is cheaper one.
Regards,
Hardik Shah
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!