on 11-03-2022 10:23 AM - edited on 11-03-2022 10:24 AM by jforsythe
This article is based on a discussion, Dual ISP Global Protect Redundancy, posted by @DonohoeRobert. Thank you for the insight!
Hi Team,
I hope ye all are well. We recently worked a case for a customer that had dual ISP configuration and wanted the Palo Alto Networks device to provide redundancy for the Global Protect Portal and Gateways in the event one ISP went down. We came up with a handy way of providing this using NAT rules and a loopback and I am posting this to share with the community.
There are some screenshots from the lab below. Eth1/1 & Eth1/2 represent ISP-A and ISP-B.
We popped the Global Protect Portal and Gateway on a loopback interface.
We created two NAT rules to bounce the incoming traffic whether its from ISP-A or ISP-B to the loopback address.
The system has two Virtual Routers for both ISP's. VR-A and VR-B. VR-A has the loopback interface added.
Virtual Router B has a static route to VR-A which has a route to the loopback interface with the Portal and Gateway.
This simple setup allows access to the portal and gateway from either ISP interfaces. We simulated one ISP failing and changed the A record of the portal fqdn to resolve to the other interface and the users could connect without any input or changes from the end user. There are a number of ways to automate dns integrity and failover to resolve to a different ip address if it can't resolve to another. Beyond the scope of Palo Alto. Infoblox and Route 53 can provide these features. If you just have an MS server, changing the A record from one IP to another isn't a massive task.
Hope this helps few others and is nice way to provide an extra layer of redundancy for networks to big to fail.
Best regards,
Robert D
Hi Robert,
GP redundancy is something I am fighting with for a while with no success. In my case with this design applied, GP is reachable only through ISP-A - the one, which is connected to VR-A , where loopback is connected as well. Accessibility over ISP-B does not work, which I assume it is caused by asymmetric routing, where the VR-A dominant route is taking place for reply traffic. I tried to solve it by PBF rule: Source: Interface eth1/2 + IP any --> Destination: IP address ISP-B --> Action: No PBF + Enforce symmetric return to ISP-B GW. This PBF rule however does not match any traffic.
I have alto one personal notion about your design: It might work only in lab conditions because of fact, that you assigned IP for both ISP lines from same subnet 172.25.4.0/23. In real world with different public IP ranges you would observe same behavior as I do.
Regards
Igor
Hi @Igor_Bartak ,
Try ECMP with Symmetric Return instead. Also, this can be done with one VR. With regard to your failover, is DNS changing as well?
I've done scenarios like this many times. Feel free to DM is you want.
Thanks,
Tom
