06-24-2022 04:29 AM - edited 06-24-2022 04:38 AM
Hi,
I would like to set up Global Protect VPN on 2 sites, and have a round robin redundancy between them.
i.e. user1 logs on the GP VPN and connects to site A, then user2 connects to GP VPN and connects to site B, and so on...
Is this possible?
regards,
06-24-2022 12:02 PM
Yes and no. There is no true round robin, but you approximate it using DNS and/or multiple gateways. For the examples below I am assuming that both VPN sites are connected together on the back end and you can access all your internal resources from either VPN.
Remember that there are 2 login stages for the GlobalProtect VPN connection. The first is a connection to the GP Portal: the client connects, authenticates via certificate, user/pass, or SSO, and downloads the GP client configuration. The second is a connection to a GP Gateway specified in the configuration and authenticates via certificate, user/pass, SSO, or a cookie (where the encrypted tunnel actually terminates). The GP Portal and Gateway can exist on the same device, different interfaces, or completely different devices, and you can specify multiple Gateways per Portal.
Option 1) Use DNS to point to multiple Portals - You might currently have the GP client configured to use vpna.example.com for Site A and vpnb.example.com for Site B. Instead, create a vpn.example.com DNS A record and include both the Site A and B destination IPs and point the GP client at that instead. (Be sure you have the appropriate SSL certificate on both Site A and B with a Subject Alternative Name of DNS_Name=vpn.example.com.).
Depending on which IP the DNS returns first, the GP client will now connect to one or the other GP Portal. The balancing of this will depend on how the DNS server responds to the request from the PC... some servers may respond with the IPs in random order, some may always return the same ordering... I have not tested this (on my list of things to try), but I believe this should also allow the GP client to automatically go to an alternate Portal if the first IP is not reachable.
Option 2) Use multiple Gateways - Each Portal specifies one or more Gateways. On Site A and B, place the destination FQDN of both Gateways in each Portal config. So on Site A Portal set: Network -> GlobalProtect -> Portal -> [config] -> Agent -> [config] -> External:
External Gateways
Name=Site_A_Gateway, Gateway=gatewaya.example.com, Priority=Highest
Name=Site_B_Gateway, Gateway=gatewayb.example.com, Priority=Highest
Note: You can use your Portal FQDNs if that is where your Gateway resides (with appropriate certificate SANs), but there are some gotchas that using a different FQDN and/or IP address for your Gateway fixes. The Gateway priority calculation is also not quite what you may expect, so be sure to read up on how that is determined and the quirks it introduces as well.
I am currently using option #2 across 4 Portals and 4 Gateways. Connecting to any Portal, the client is roughly balanced across 3 Gateways (the 4th is set at lowest priority/last resort as it is busy with other traffic). With 200-220 VPN users, about 80% of which use Portal A, I typically see 2 Gateways with 60-70 connected users and the third Gateway with 80-100 users.
06-24-2022 02:06 PM
I would fully agree with @Adrian_Jensen that it will be very unlikely you will be able to achieve equal distribution of users...
You can achieve complete redundency, but not equal load sharing.
The sad think is that if you add always-on to the mix we are starting to talk about gateway caching - GP will cache the last available gateways and will try to connect directly to the gateway, without connecting to the portal. Which means if you use DNS round robin for the portals and each portal will list only its gateway, due the gateway caching user will not ask the portal to which gateway to connect, they will connect to the last gateway they were used before.
What @Adrian_Jensen mentioned about gateway priority and selection is described on this link - https://docs.paloaltonetworks.com/globalprotect/9-1/globalprotect-admin/globalprotect-gateways/globa... As you can see GP will use not only priority, but gateway response time as well.
What I would suggest is mix of the above two options:
- Use some kind of DNS load balancer for the GP portal FQDN. If you prefer you can use round robin to distribute users equally between the two site, or configure the DNS load balancer to monitor the availability of the two portals and use one of the as primary and the second one as backup.
- Configure both GP portals to assign both GP gateways with highest prioriry. This way gateway selections will always be down to the response time.
As mentioned if you use always-on VPN mode, upon starting GP client will use the latest cached config, test the response for the two gateways and again use the fastest, without connecting to the portal. If you use on-demand, I believe GP agent will always connect to the protal first, if you don't use clientless vpn, the connection the portal will be very short, only to grab fresh config.
06-24-2022 04:00 PM
@aleksandar.astardzhiev wrote:...
What @Adrian_Jensen mentioned about gateway priority and selection is described on this link - https://docs.paloaltonetworks.com/globalprotect/9-1/globalprotect-admin/globalprotect-gateways/globa... As you can see GP will use not only priority, but gateway response time as well.
Yeah, unfortunately Gateway priority is really secondary to response time, meaning that (unless you have a large number of diverse, latency wise, Gateways) there are effectively only 2 priority settings.
...As mentioned if you use always-on VPN mode, upon starting GP client will use the latest cached config, test the response for the two gateways and again use the fastest, without connecting to the portal. If you use on-demand, I believe GP agent will always connect to the protal first, if you don't use clientless vpn, the connection the portal will be very short, only to grab fresh config.
Is this true (use latest cached config)? I was unable to get this to work with always-on VPN and detection of Internal Network. Occasionally the GP client would use the cached configuration copy, but in most cases it would try to connect to the Portal first. It was hit-and-miss that cached config would work. This required me to setup certificate authentication on the Portal so the client could always authenticate there, without user interaction, to download the config and then use the defined internal host detection.
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!
