GlobalProtect Gateway Weight: What It Is and How It's Calculated

If you've ever watched a GlobalProtect client connect to an unexpected gateway and wondered why, this post is for you. Palo Alto's documentation describes the selection process in broad strokes — lowest latency wins — but the real calculation involves a weighted score that combines measured latency with configured gateway priority. Understanding how that score is built makes gateway behavior a lot more predictable, and gives you meaningful control over how traffic is steered across your environment.

GlobalProtect Best Gateway Selection: What the Documentation Doesn't Tell You

The best gateway selection process for GlobalProtect can be a little confusing at first. Part of that confusion stems from the fact that Palo Alto Networks has been somewhat opaque about the exact calculation used to identify the best gateway.

On the surface, gateway selection relies on choosing the lowest-latency option — but there's more to it than the documentation lets on. If you dig into the PANGPS logs, you may find references to something called weight. This metric isn't defined anywhere in the official docs, and tracking down an explanation takes some effort. After a lot of searching, I was able to find a presentation that appears to have originated from an internal Palo Alto resource that finally defines how weight is calculated.

Priority and Latency

Each gateway in a GlobalProtect portal can be assigned a priority of Highest, High, Medium, Low, or Lowest, which map to numeric values of 1 through 5 respectively. When a GlobalProtect client first connects, it attempts a connection over SSL and measures the latency of each gateway, which the documentation refers to as “duration”. It also calculates the minimum latency, maximum latency, and the range (max minus min) across all gateways. These values feed directly into the weight formula.

Configuring gateway priority

Gateway priority is set on the portal configuration, not on the gateway itself. In Panorama or the firewall UI, navigate to Network > GlobalProtect > Portals, open your portal, and go to the Agent tab. Under the gateway configuration for each entry in the gateway list, you'll find a Priority dropdown. This is where the Highest through Lowest values are assigned on a per-gateway basis, and they can differ across agent configurations if you're serving different user populations from the same portal.

One thing worth calling out: priority is specific to each agent config within the portal. If you have multiple agent configs — say, one for corporate-managed devices and one for BYOD — you can assign different priorities to the same gateway across those configs, which gives you a clean way to prefer different gateways for different user groups without needing separate portals.

Response time vs. load and response time

The Best Gateway Selection Criteria setting lives in the same agent config, just above the gateway list. It has two options: Response Time and Load and Response Time. The distinction matters more than it might look at first glance.

Response Time is what the weight formula described below uses. The client measures SSL connection latency to each gateway, feeds that into the weight calculation alongside priority, and connects to the lowest-weight result. The decision is made entirely on the client side using data the client collected itself.

Load and Response Time changes the dynamic. With this option enabled, gateways periodically report their current load back to the portal, and that load information is factored into the selection alongside latency. The intent is to prevent a large number of clients from piling onto a single low-latency gateway when other gateways have available capacity. In environments with multiple gateways that are geographically close — or where latency differences between gateways are small — this option can produce more even distribution across your gateway infrastructure.

The tradeoff is that Load and Response Time introduces a dependency on the gateways actively reporting load data. If a gateway isn't reporting, the portal falls back to latency-only behavior for that gateway. For most smaller deployments with clearly differentiated gateway locations, Response Time is simpler and entirely predictable. Load and Response Time starts earning its complexity in larger deployments where you're actively trying to manage capacity across multiple gateways serving similar geographic areas.

The Weight Calculation

For gateways with a priority of Highest, High, or Medium (values 1–3):

weight = (duration − minduration) × 100 range + (priority × pri_factor)

For gateways with a priority of Low or Lowest (values 4–5), an additional 100 is added:

weight = (duration − minduration) × 100 range + (priority × pri_factor) + 100

The priority factor is hard-coded at 20 and the resulting weight is always rounded down to a whole number.

The gateway with the lowest weight wins. A few things fall out of this formula worth calling out explicitly.

First, the gateway with the lowest measured latency will always produce a latency term of zero — (duration - min_duration) 100 / range — leaving its weight as purely priority 20. That means a Highest priority gateway at minimum latency carries a weight of 20, while a High priority gateway at minimum latency carries 40.

Second, the +100 penalty applied to Low and Lowest priority gateways is significant. It means that even a Low priority gateway at minimum latency starts with a weight of 180 (4 * 20 + 100). For that gateway to ever be selected over a Medium priority gateway, all Medium priority gateways would need to have accumulated enough latency-based weight to exceed 180 — which in practice means they'd need to be performing very badly.

Finally, there's one last adjustment: the weight of the previously connected gateway is reduced by 2. This creates a slight but deliberate preference for the last successful gateway, avoiding unnecessary churn without permanently locking the client to it.

PANGPS Sample Output

(P6652-T40420)Debug(1261): 10/28/25 08:49:59:046 minduration=116, maxduration=779, range=663
(P6652-T40420)Debug(1274): 10/28/25 08:49:59:046 CPanGatewayList::PickGatewayBaseOnWeight, total 4301 ms used, 9 gateway(s) successfully returned , average reach time is 477 ms
(P6652-T40420)Debug(1374): 10/28/25 08:49:59:046 gateway Los Angeles, CA, US (lax.thisbridgeistheroot.com), priority=1, duration=283 ms, assign 45 as its weight
(P6652-T40420)Debug(1374): 10/28/25 08:49:59:046 gateway Baltimore, MD, US (bal.thisbridgeistheroot.com), priority=1, duration=575 ms, assign 89 as its weight
(P6652-T40420)Debug(1374): 10/28/25 08:49:59:046 gateway Berlin, DE (ber.thisbridgeistheroot.com), priority=2, duration=662 ms, assign 122 as its weight
(P6652-T40420)Debug(1374): 10/28/25 08:49:59:046 gateway Sydney, AU (syd.thisbridgeistheroot.com), priority=3, duration=779 ms, assign 160 as its weight
(P6652-T40420)Debug(1374): 10/28/25 08:49:59:046 gateway Austin, TX, US (aus.thisbridgeistheroot.com), priority=1, duration=589 ms, assign 91 as its weight
(P6652-T40420)Debug(1374): 10/28/25 08:49:59:046 gateway Chicago, IL, US (chi.thisbridgeistheroot.com), priority=1, duration=351 ms, assign 55 as its weight
(P6652-T40420)Debug(1374): 10/28/25 08:49:59:046 gateway Mumbai, India (mum.thisbridgeistheroot.com), priority=2, duration=547 ms, assign 105 as its weight
(P6652-T40420)Debug(1374): 10/28/25 08:49:59:046 gateway Portland, OR, US (por.thisbridgeistheroot.com), priority=1, duration=399 ms, assign 62 as its weight
(P6652-T40420)Debug(1374): 10/28/25 08:49:59:046 gateway Raleigh, NC, US (ral.thisbridgeistheroot.com), priority=1, duration=116 ms, assign 20 as its weight
(P6652-T40420)Info (1413): 10/28/25 08:49:59:046 CPanGatewayList::PickGatewayBaseOnWeight, PAN_NEW_GATEWAY_SELECTOR, chose prefered gateway index =8, gateway is Raleigh, NC, US

Worked Example

The minimum latency is 116ms, the maximum is 779ms, and the range is 663ms.

Gateway Name	Latency (Duration)	Priority	Weight
Raleigh, NC	116	1	20
Portland, OR	339	1	62
Baltimore, MD	575	1	89
Chicago, IL	351	1	55
Austin, TX	589	1	91
Los Angeles, CA	283	1	45
Berlin, DE	662	2	122
Sydney, AU	779	3	160
Mumbai, IN	547	2	105

Raleigh, NC wins with a weight of 20. Now assume the client was previously connected to Los Angeles, CA — its weight drops to 43, but Raleigh still wins comfortably.

Now swap Raleigh's priority to Medium:

Raleigh (Medium): ((116 - 116)*100 / 663) + (3 * 20) = 0 + 60 = 60

Despite having the lowest latency, Raleigh now loses to Los Angeles (45) and Chicago (55). This is where the priority has made a large difference to the end result. Geographical spread of the gateways and over-subscription of circuits are going to determine your best course of action in terms of gateway priority marking.

Understanding the weight calculation changes how you think about gateway priority configuration. Highest and High priority gateways carry a meaningful structural advantage just from their priority multiplier — even at worse latency, they can still outcompete lower-priority gateways. The +100 penalty for Low and Lowest effectively removes those gateways from contention under normal conditions, making them useful as true last-resort options rather than just soft preferences. And the −2 bonus for the previously connected gateway is subtle enough that it won't override a meaningful latency difference, but it does add a small stabilizing force that prevents unnecessary reconnections when conditions are close.

If you're troubleshooting unexpected gateway selection, start with the PANGPS logs from the client and look for the weight values. Once you can see the numbers, the behavior stops being mysterious