- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
10-31-2024 10:41 AM
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
11-01-2024 08:19 AM
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.
11-01-2024 01:36 PM
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.
11-08-2024 10:53 AM
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.
11-08-2024 11:16 AM
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.
11-08-2024 11:38 AM
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.
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!