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.

[Jpergolizzi]

Hi folks, thanks for all the replies. Apologies for the length of this. As I've continued to dig into this, I've actually found several different reasons for clients not upgrading. 

1. Users computer has the client installed, but they never used it. (ISSUE: NO CLIENT UPDATE TO NEW VERSION)

**Without logging in, the client will not check against the latest released version so won't attempt an upgrade. The login is required for this process to work. In this case, we would need a different way of upgrading the client such as PDQ, InTune, etc. Investigating this.

2. Users have not successfully logged in for some time so the client doesn't upgrade. (ISSUES: NO CLIENT UPDATE TO NEW VERSION / NO OKTA PUSH FOR GP AUTHENTICATION)

**I've already visited 3 users today who have their VPN client set to automatically connect. However, as they are on the internal network, they have not gone into Okta to manually get their code and Okta is not sending a push notification to their phone. In all 3 cases, once the user successfully logged in, the client did upgrade transparently. Again, a successful login is required for the update to work. It's likely that they have not successfully logged into GP since prior to the new client being pushed, some further back than that. We are dealing with these users as we find them and making sure Okta MFA does a push. My preference here is that no client tries to "automatically" start" and login.

3. Various users GP clients attempt to start and log in automatically every time they start their computer. (ISSUE: GP AUTO START WHETHER NEEDED OR NOT)

**I have found multiple user computers that appear to have their GP client set to automatically try to log in. Again, in cases where they are in the internal network, they aren't completing the GP authentication/login so the client is simply churning in the background trying to connect. I suspect this is because the GP client is in the startup programs on their computers. This is not set the same for all users across the City. In my opinion, a user should manually connect to GP when they need that connection. The client should not attempt to automatically start.

4. Users with GP client on IPads are not upgrading to the new version. (ISSUE: NO CLIENT UPDATE TO NEW VERSION)

**There appear to be various users running GP on IPads whos GP client will not upgrade. At this point I am not sure why.

All that said above, there are still City clients connecting from the internet successfully who's GP client does not appear to be upgrading. I am focusing my investigation now on those folks. I've been able to grab all logs from one test client so we're taking a look now.

[Claw4609]

Hello,

The GlobalProtect clients will only do a version check when checking in with the portal so clients would need to connect, or be currently connected and have the config refresh timeout trigger. I dont believe the update control through the portal will apply to Android/IOS devices, presumably because by default neither allow sideloading applications. This would be controls by the respective app stores or by an MDM.

To echo @BPry point, we do not usually rely on transparent upgrades either and instead push out updates/deliver content via a central platform. Like @BPry you could also enforce HIP checks to stop a version thats two old from basically having any access. 

[Jpergolizzi]

Claw4609, thanks for responding. Thats good to know about the IPads / Andriods. We don't have many thankfully so it looks like we will need to manage those separately. Not too painful.

While I am waiting for my clients approval, I do think he will agree with using a tool like MDM or something (they currently use PDQ Deploy and SmartDeploy) to install and push images. I believe, when a new computer is set up, it gets a standard image from SmartDeploy which includes a globalprotect client. PDQ Deploy currently does not push GP updates but they are using for many other apps and it monitors the GP version on the users computer, so I don't think it would be difficult to add GP to it.

As far as quarantining for older versions, I would need to get the ok from the client to do that but it certainly does sound reasonable.

Thanks! I think with PDQ, etc, most computers would be addressed. There are people running in from their home personal computers and I think thats where also having the firewall transparently update those would be helpful.