Do I Need More Than One Palo Alto GlobalProtect VPN Portal?
The Crucial Role of GlobalProtect
With an increased demand for GlobalProtect as an enterprise grade VPN client solution, a common question comes up: Is a secondary portal necessary? In many cases, the short answer is probably not. In this post, we will review some options to ensure high availability of GlobalProtect services now that it’s become a mission critical application for many organizations.
As a quick primer, GlobalProtect consists of three main components and each one plays an important role. If you are already familiar with these, feel free to skim down to the next section.
- The Agent. This component runs on the endpoint and handles the initiation of a VPN connection. The agent is initially configured with a portal address either manually by the end user, or by setting a registry key to pre-populate it. The agent operates at both the data plane and the control plane.
- The Portal. This component runs on the firewall and is essentially acting as the management plane for the agents. It’s where we configure behavioral settings that will instruct our agents on things like timeout parameters, on-demand vs. always-on, and a list of gateways they can connect to. The agent always connects to the portal as a first step when you initiate a VPN. After successful authentication to the portal, the agent will download its configuration file and then it will select a gateway to connect to based on a set of metrics.
- The Gateway. This component operates at the data plane and its job is to terminate the head-end VPN tunnel (IPSec or SSL) and provide the agents with access to resources. It’s usually a good idea to have a minimum of two gateways deployed for availability reasons. Gateways can be deployed on separate internet links on the same firewall, or on another firewall in a different location. Many organizations will align gateways with their data centers and/or regions in order to optimize performance for their end users. Each gateway has its own unique configuration for authentication, IP pool settings, split-tunneling, client DNS settings, etc.
So, let’s say we have a standard on-demand deployment with a single portal and two active gateways. What happens if that portal is down or unreachable?
Three Possible Solutions
Option 1: Agent Portal Caching
The good news is that the GlobalProtect agent will automatically cache the portal configuration. As long as one or more gateways are still online, the agent will connect to an available gateway. The only catch here is that the agent needs to have a saved username. To accomplish this we prefer to enable “save username only” in the portal configuration. Single Sign On (SSO) is another option, but we usually disable SSO with on-demand deployments. The agent will only cache the configuration when there is a unique combination of the portal and saved username. If your organization has a policy that does not allow for saved usernames in an application, then this option may not be a good fit. The password does not have to be saved on the agent (nor would we recommend it). If the agent has never connected prior to the portal being down, that would be a problem so this only applies to agents that have successfully connected at least once.
If the portal is down, can I still make changes? No, assuming you cannot reach the firewall running the portal, or that firewall has connectivity issues, then agents cannot connect and pull down configuration updates. However, I would argue that most organizations are not making frequent changes to the behavior of their GlobalProtect agents. Therefore a brief portal outage should have minimal impact. If your organization requires the ability to change agent behavior at all times, then agent portal caching may not work then.
Is multi-factor authentication supported with this? Absolutely, and we highly recommend it.
Option 2: Secondary Portal
In cases where we cannot enable “save username only,” a secondary portal can be deployed. Generally, the secondary portal would run on a firewall at a different location than the primary portal. The disadvantage to this method is that now two portal configurations must be maintained. Additionally, the users will need to select the secondary portal in the agent when the primary portal is unavailable. So it may also require a little more training and awareness for your users.
Option 3: Secondary Portal with Global Server Load Balancing (GSLB)
It’s also possible to front-end two portals with a DNS based GSLB solution. This basically involves health probes that monitor the availability of the portal services and responds to DNS queries accordingly. Once set up, this means users wouldn’t need to select between portals in the event the primary portal is down. The disadvantage is having to maintain even more infrastructure on top of maintaining the two portals.
At the end of the day, our preference would be to leverage the built in caching capabilities of the GlobalProtect agent. It’s the least amount of technical overhead to maintain and troubleshoot and it works quite well for production grade GlobalProtect deployments.
---
GlobalProtect is a powerful VPN client solution for organizations. However, with different industries requiring varying applications and configurations, it's helpful to leverage an expert to take full advantage of GlobalProtect's power. As one of Palo Alto Network's partners, WAN Dynamics is the go-to source for GlobalProtect integrations. Get in touch with our team today to discuss how we can deliver the performance and security your organization deserves.