We are on version 4.1.11. Palo suggested upgrading to at least version 5.0.8. This raises a few questions:
We can only activate one version at a time, right?
If I download and activate 5.0.8, the users will still be able to operate on 4.1.11?
2a. For now, I only want a few people to test 5.0.8
I do not want anyone to be prompted to download the new version when connecting to the VPN. Is that the setting located in Network → GlobalProtect → Portals → “PortalName” → Agent → “ConfigName” → App → “Allow User to Upgrade GlobalProtect App” and choosing “Disallow”?
What troubles are you expecting? I have 4500 vpn clients and i auto upgrade to latest version every August for 8 years without issue. It might actually be the only upgrade we dont actually test much more than on our own devices.
For long term success, I typically encourage to do things a little differently. I encourage people to break up their portal config by department/area. Even if it’s the same gateway.
Then I can disable the upgrade for the different configs.
I can install the update on a few test edges from SCCM/whatever.
Then I start slowly enable the upgrade via the portal config per department/area.
That way I get my testing in and the upgrades are slow to not overwhelm the help desk.
Every software deployment follows the 80/20 rule. 80% of them will upgrade with zero issues. 20% will fall on their face.
My response - for whatever it’s worth - is that you need to look at the differences between the two clients and weigh the security changes between them. 5.x includes a lot of better security features than the 4.x version. We moved to 5.0.2 first for everyone, then went to 5.0.4 after about 6 months. We JUST pushed 5.0.8 to a few people (granted, we did this through SCCM and not through the FW) and all seems well so far. I would say that if you use SAML for any 2FA that you test test test 5.1.x before going to it. We tried it, and it messed up our DUO authentication via SAML. People were in an endless DUO push loop. Not pretty. I’ve tested 5.0.8 with DUO SAML and it works, so in a real-world situation, if you go to that version, it “should” be ok. Another thought is to just keep 4.1.11 active on your firewall and have a few clients manually download and install 5.0.8 on their machines. It keeps the 4.1.11 active, but the FW allows the other clients to connect. Test it out that way, and if they work for you, then make 5.0.8 active and people will get the notice to DL.
At least, that’s how it has worked for me. Hope that helps.
I have around seventy thousand users across eight geographic co-location facilities with a single portal and eight gateways.
yes, per portal
yes, you can install any version for testing as long as you have “Allow User to Upgrade GlobalProtect App” set to disallow.
yes, that is the setting
We use SCCM/JAMF for upgrades but will use auto-update if there is a CyberSec vulnerability. I have found it is easier to let the linux/mac/windows groups manage software installed instead of forking an update path outside of the normal approvals. Granted, this is my opinion and by using traditional software management processes and having the auto-update available we have never had any issues that others have described over the years.
I don’t have an answer for you, but hoping someone else does. We are running an older client and I’d like to get a little more current but I’m unsure how it will interact with users. With everyone at home and mostly lacking permissions to install their own software, it seems like a recipe for disaster.
What kind of headaches have you had? I’ve been allowing clients to auto upgrade on connection for the past 6 years and have had absolutely zero problems.
I can speak from experience that using shit like SCCM/WUSA to upgrade the PA GP client will fuck up. Distributing it from the firewall is the preferred choice - ask TAC.
We can only activate one version at a time, right?
Yes.
If I download and activate 5.0.8, the users will still be able to operate on 4.1.11? 2a. For now, I only want a few people to test 5.0.8
If you’re wanting to test GP 5.0.8 on a few users, I’d advise grabbing that version from the support portal, and distributing it to your test folks.
I do not want anyone to be prompted to download the new version when connecting to the VPN. Is that the setting located in Network → GlobalProtect → Portals → “PortalName” → Agent → “ConfigName” → App → “Allow User to Upgrade GlobalProtect App” and choosing “Disallow”?
That is the correct setting to prevent upgrading- the issue will actually lie with the parameter in “GlobalProtect App Config Refresh Interval (hours)” since your users do not check in for an updated config for that time. So if you were to activate the 5.0.8, and disallow, they may get prompted anyway.
Also, GP 5.0 has reached end of engineering. It will only be updated for security vulnerabilities, nothing else. It is supported til 2/2021, but 5.1 will likely be advised.
We initially deployed by GPO software assignment from a network share. If the agent updates from the PA, the installer stops GPA service killing the VPN, then uninstalls then looks for the original installer on the network share. If off network and obviously off vpn, the update install halts asking for the file location of the original installer. User hits cancel and install fails. Our users don’t have local admin so they can’t just download from the portal and install for themselves.
We disallowed self updating for now. We are just going to let the GPO update them when they get back on network.
I set up a work around so that at least some techs can remote in with teamviewer and complete the install while off-network without waiting to download the GP client from the portal, I had the same GPO copy the installer files to the c:\users\public\downloads folder. (Some users have 3 meg DSL, satt, or cellular hotspot)
Next I’m planning on testing redeploying the app pointing to the local copy for the software assignment. I need to test if that works for us first.
I was honestly unaware you could download versions of the VPN client from the support portal. I will test 5.0.8 this way and go from there. Thank you
Edit: I installed 5.0.8 on my PC and the client will ‘connect’ but I can’t access anything on the network and after about 15-20 seconds it will automatically disconnect.
Ive seen the same thing on plenty of other software packages deployed via GP, always wanting to get to the original package located on the share to remove it.
- is that you need to look at the differences between the two clients and weigh the security changes between them. 5.x includes a lot of better security features than the 4.x version. We moved to 5.0.2 first for everyone, then went to 5.0.4 after about 6 months. We JUST pushed 5.0.8 to a few people (granted, we did this through SCCM and not through the FW) and all seems well so far. I would say that if you use SAML for any 2FA that you test test test 5.1.x before going to it. We tried it, and it messed up our DUO authentication via SAML. People were in an endless DUO push loop. Not pretty. I’ve tested 5.0.8 with DUO SAML and it works, so in a real-world situation, if you go to that version, it “should” be ok. Another thought is to just keep 4.1.11 active on your firewall and have a few clients manually download and install 5.0.8 on their machines. It keeps the 4.1.11 active, but the FW allows the other clients to connect. Test it out that way, and if they work for you, then make 5.0.8 active and people will get the notice to DL.