GlobalProtect Transparent Upgrade not working for all users

[Jpergolizzi]

Hey folks, this is my first time posting so apologies if it's a little clunky. We are running a pair of PA-850's in HA mode. Our users have been connecting with GP for years with no real issues. I always keep up on the new GP client versions, right now the most recent is 6.3.1-c383. A few weeks ago, I had noticed that we still have quite a few users running older versions of the GP client, anywhere from 4.1.6 to 6.3.0 and many versions in between. The initial config option on the agent was set to "Allow with Prompt" which basically gave the user the option to delay the upgrade until a later time (have no clue exactly what that timeframe is). 

I made the change to "Allow Transparently". This was when we upgraded to 6.3.1. Since then, I installed 6.3.1-c383. I tested this from my computer and it worked exactly like it should. But, it doesn't seem to be working for a variety of other users.

Internal DNS does resolve the public ip of the gateway/portal. So, I'm at a loss as to why this isn't working for all users. I've been searching the web and haven't really found anything helpful.

Has anyone run into this and, if so, was able to solve it?

Thanks,

Jim

[Claw4609]

Hello,

If you have an example client, do a manually refresh on the clients GP, does it work then? The client may just not have grabbed the new client config yet.

If it still fails after that. Grab the debug logs from a clients GP application and look at the panGPS and panGPA files, itll show in there if it checked for a new version and if it failed or not.

[BPry]

@Jpergolizzi,

Even when everything is configured correctly I've personally noticed this across many different networks and many different client networks, so much so that I just kind of expect it at this point. I've traced it back in a lot of cases to just the user not downloaded the client successfully before encountering some sort of connection issue (or disconnecting) which causes the client to get in an endless verification loop.

What you can do to help detect the issue is just create HIP objects for the different agent versions and create a HIP notification that alerts the user when something is outdated. I try to get everyone to go a step further and say that connecting clients need to be N+2 versions or they don't get to connect. Setup HIP notifications to display when a user is a version behind current after a bit telling them that they may need to manually update or contact helpdesk to assist. Then setup a HIP notification for your last group that specifically says that they're running and EoL version and they will lose access if they don't take action. Finally if they get too far behind they just actually are restricted the same that we would for an outdated machine from a security update aspect.