- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
09-24-2025 09:38 AM
We have two on-premises GlobalProtect Portals on two different HA systems in different locations in the state, we would like a simple process to handle when/if a site goes down for the end-users.
Both portals are named different:
East-Portal
West-Portal
Is it possible to have an AWS Application Load Balancer send traffic to the portals? Has anyone done this and would we have to use a SAN cert on the portals, since the names are different?
09-24-2025 10:12 AM
Hello @LeifAlire
While AWS LB could help you to effectively manages GlobalPortal portal selection, but if you already have a Panorama, the NGFW support for Prisma Access Agent provides a more integrated, feature-rich, and centrally managed solution that extends beyond basic connectivity to offer enhanced security, user experience, and operational efficiency across diverse deployment scenarios.
NGFW support for Prisma Access Agent offers several advantages over a traditional portal load balancer by providing a more unified, comprehensive, and streamlined security and management solution. While a a load balancer primarily focuses on directing clients to the optimal portal, Prisma Access Agent integrates a broader set of advanced capabilities and operational efficiencies.
Here are the key reasons why NGFW support for Prisma Access Agent is considered beneficial:
NGFW Support for Prisma Access Agent
09-26-2025 06:29 AM
My company doesn't use AWS, but azure. Azure doesn't allow you to use external ips that aren't associated with your tenant. I would check and see if AWS cares where its pointed to our not first. The certificate type doesn't seem to matter, as we use a wildcard cert. We have dedicate url for the web gp portals(the main urls), and then use a different hostnames for the actual gateways(where the clients actually connect too). Then on both devices you setup all the different urls and weights on the gp portals->gp portal configuration->agent(you have to set each you have defines)->external->external gateways. On both devices list out all the direct gp portal ip based urls(not the load balancer), that are vpn connectable. Your main web gp url will be different ip since its going to be pointed to a load balancer. Your web port is where your gp clients get the list of portal urls to connect to and configuration. Basically all you care about ha'ing is the web gp portal part, not the ipsec/ssl vpn ports.
On azure if you are multiple regional its complicated because you have two regional app gateways, and they have there own urls and public ips, and then you have a global app gateway, that load balances between the two regions, and it has its own ips and urls. You can't skip the regional step. If its a single region then you just need the one regional app gateway url.
Its neat to watch stuff failover. I don't believe you actually need to do this. If you clients have already download there configuration, then it knows about all the external gateways urls, and can handle that part on its own. I believe this is really needed for initial connection and configuration.
Disclaimer, I don't use clientless vpn or satellite, and I'm not sure how that would play in. Would you use the load balancer or not.
09-28-2025 03:25 PM
Hello @LeifAlire @JustinWoodman
sorry to step into this discussion.
Similar discussion came up in this post: Advice on dual isp, getting dns to work. In Azure, Traffic Manager can be used for health check + failover of VPN portals. Although, I do not have real world experience with the same deployment in AWS, Route 53 can serve the same purpose.
Kind Regards
Pavel
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!