My company is having an ongoing issue with Global Connect not moving past the connecting stage on Windows computers. We use OKTA for our authentication method. The users are able to authenticate past Okta but after that Global Protect will go no further.
We have found a few workarounds for this issue, but no permanent fix.
The easiest method is for the user to sign out of Global protect and then reconnect. This works 100% of the time
We have also noticed that we can delete the files in c:/users/(username)/appdata/local/palo alto networks/globalprotect or just the .pan and .dat files in that location
Lastly reinstalling Global Protect will work as well
the 2nd 2 aren’t really necessary but from learning that removing the files from the appdata folder I believe the issue may have something to do with a some sort of corrupted .pan or .dat file
Does this sound familiar to anybody?
thanks
We’ve had similar issues, but the taskbar would also freeze while it was stuck on connecting. In our case it was traced to IPV6 so I disable IPV6 on all network adapters. It will unfreeze and connect about 30 seconds after doing that.
What version of globalprotect are you using
I’m seeing the same behavior since we upgraded to 10.0.7 on GP 5.2.7.
Just migrated to 5.2.8, so we’ll see if it goes away.
Check the agent cache and cookies settings on the PA side (Global Protect > Gateways)
What do your pangps client logs say?
Make sure both Ike and ssl are allowed on the firewall policy
We have something very similar happening (intermittently and not for every user) since we moved to SSO thru Azure. Doesn’t seem to be limited to any specific version of GP.
User will log into windows, GP will open, browser launches prompting for authentication. User authenicates successfully, but the GP client remains stuck at Still Working. The only way to resolve this that’s worked every time is to reinstall the client.
I have noticed that when GP is stuck at still working, the sign in name is the users local AD username, whereas it should be their email address. After reinstalling the client, it goes back to using email address and works fine.
We’ve had this issue for over a year and I just found the solution (at least for us).
First start off by checking System Information. If it doesn’t reveal the systems info and instead says “Cannot access the Windows Management Instrumentation software. Windows Management files may be moved or missing.” then this should work for you.
- Open Services (open the Run box and type in services.msc)
- Find Windows Management Instrumentation and make sure the Startup type is set to Automatic.
- Then STOP the service (may have to Pause and then Stop).
- Delete the files under C:\Windows\System32\wbem\Repository
- Open regedit
- Go to HKEY_LOCAL_MACHINE > Software and HKEY_CURRENT_USER > Software and DELETE the Palo Alto Networks folder.
- Uninstall GlobalProtect
- Reboot the machine
- Reinstall GlobalProtect
- Confirm that WMI service is running by going to the Windows search bar and opening System Information. You should see all of the system’s information such as OS name, version, etc.
Global Protect Client Stinks… I would not recommend.
We’re at version 6.1.1-5. I was having trouble connecting from a particular PC and stumbled across your 2 1/2 year-old post. Turning off IPV6 worked within seconds. Thank you!
You are the GOAT, Thanks!
This ^ If the agent is working when you delete the appdata folder, probably cache settings on the machine.
We had similar problems in the past and we’ve found some miss configuration settings that solved it.
Further more, consider client update if possible
I cant read those things, I have no idea what I am looking at. I’m not the network engineer, I’m just the level 2 tech. The guys who should be doing this are to busy trying to get the networks set up on our latest merger.
What should I be looking for?
Try having the user sign out instead and se if that works for you. in the menu go to settings and jsut hit the sign out button, then have them authenticate and log in again. could be a time saver
Thanks for the insight about SSO through Azure though I’ll look into that
Same here, worked like charm. But I do not understand how this is an issue, since it was working just fine. Maybe some routing issue…
I’d start by searching for the word ‘error’ and see what the message is if there is anything.
Unsolicited advice. Step 1 of moving up in IT is taking the initiative to solving these types of things. If you don’t know how to read or do something, try to use all of the resources at your disposal and figure it out. Those logs are very readable, it’s not like a foreign language.
Not sure if you’re still having issues with this, but we seem to have found a fix for ours.
Under Network>GlobalProtect>Portals, then your GP Portal>Agent>Agent config>App tab, we had ‘Use default browser for SAML authentication’ set to Yes.
Changing that to No made the ‘still working’ issue go away, may be worth a try in your case.
There is only a list of portals and I can change addresses. Nothing about a browser