Good morning! First time posting here. We are seeing an issue with our GP users in that some cannot connect while other can with out issue. The error that we are seeing is that the agent is unable to establish a connection to the gateways. We several gateways that we use (only US based ones) that are pretty evenly distributed with users that are working and others that are not. We have only one portal that is shared across all users.
In a nutshell we are seeing prelogin connect to the portal and then fail to convert to user login.
Upping time outs in the registry
Change certificates and allow it to check user store as well as machine (this was reverted to machine only)
Something that we are possibly thinking about is copying our GP config and standing up a second portal
Sorry if this seems a bit short on information at the moment.
Prior to troubleshooting the GlobalProtect Gateway/Portal and making any sort of agent configuration changes, I always like to see people looking at the endpoint logs when you have some connections working and some failing. Have you looked at the PanGPS.log file on a machine that is failing to connect? That's the first spot I would go with an inconsistent issue like this.
Since you've stated that you have some users working on any one of the gateways and some failing, we can assume that it isn't an actual configuration issue on the gateway in question. The one thing that may be different is the assigned client settings depending on what each user is assigned, so that's one thing to verify that could potentially be misconfigured. As long as you have working users in each though, it's far more likely to be an issue specific to the endpoints in question.
Hello BPry. I am sorry I did not not include that previously. We looked at the pangps logs on several of the machines and were getting the same issue of timeouts, fail to convert prelogin - userlogin. We also checked the configs as well to make sure it was the same as we could get as some of the systems could not connect to gather the new ones with our modifications. The problem was manifesting very differently on systems but the logs looked the same
As a side note from troubleshooting with TAC, they found a memory leak on the routing table of the system that hosts our portal and have rebooted it. We are still in progress at the moment following this track.
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!