Global Protect Gateway unreachable

[jeff.anderson]

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.

Weve tried:

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.

[BPry]

@jeff.anderson,

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. 

[jeff.anderson]

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.

[jeff.anderson · Accepted solution]

Last update for resolution in our case there was a memory leak on the portal server and it needed to be rebooted. The error was not enough to cause an alarm and thus was missed initially for some time. The engineer rebooted our portal server and it resolved our issue.

[MarnusLombaard]

Hi @jeff.anderson 

Can you maybe recall what command the TAC engineer ran to reboot the portal server/services on the box? or maybe any indication on how they came around the memory leak? 

[jeff.anderson]

I am not sure of the command that was run. It was completely done by palo on there servers. As for the memory leak, this was indicated to us later that there was one but it had not reached a level to cause an alarm. Again this was all information that only Palo has access to in management of prisma.