Force GlobalProtect Portal refresh of connected clients?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Force GlobalProtect Portal refresh of connected clients?

L6 Presenter

Is there a way to force the refresh of the portal agent config on connected clients? We have multiple portals and multiple gateways for VPN load distribution and fail-over capabilities. When developing/testing changes to the GP VPN I will often take a gateway out of rotation by deleting it from the portal external gateway config. The following day, when clients authenticate to the portal, they get the updated portal config and stop using the gateway to be used for testing (default 24 hour portal app config refresh timeout, custom 18 hour gateway timeout).

 

However, we have a small number of clients that for some reason will go multiple days to a week without authenticating against/refreshing their portal config (instead using a cached copy). This is even though they are actively authenticating to the gateway every morning/disconnecting every night. Does anyone know why this is happening or how to force the client to refresh its portal config?

3 REPLIES 3

Cyber Elite
Cyber Elite

@Adrian_Jensen 

You can also disconnect the user from GUI or CLI.

Once they connect again they should get new config.

 

Regards

MP

Help the community: Like helpful comments and mark solutions.

Hi @Adrian_Jensen 

 

I had similar battle a while back - https://live.paloaltonetworks.com/t5/general-topics/how-to-force-globalprotect-user-to-always-connec...

I don't have official statement, but I am completely sure that portal refresh timer is reset on every gateway login. I could be wrong, but based on my personal observation I believe the following is happening:

- GP user connect to GP portal, grabs config along with gateways list and cache it

- GP user establish connection to GP gateway and live happy life

- Upon next connection GP will try to connect straight to the last known good gateways and used the cased config. If the connection to the gateways fail only then it will connect to GP portal and get the latest config

- Once connected to GP gateway it will wait until the portal refresh timeout run outs. Then it will authenticate and get the latest portal config

- However in some cases the user disconnect the gateway before the portal refresh timer run out. On the next connect it will again use the cased config and since the gateway is till alive it will connect straight to the gateway, skipping the portal. On this  connect it will start the clock again, but if the user reconnects again before it run out, it will never connect to the portal.

 

My only solution and suggestion is to use shorter portal config refresh timer. We previously used 4hours, which still causing several users to skipping portal refresh for months. I am only guessing that user connect in the morning, around the 3rd hour went to lunch or just go to a meeting putting his laptop to sleep. After lunch he connects but again little before the 4th hour he disconnect and go home.

 

One way is to tell the user to open the GP agent GUI --> go to setting -> Refresh connection. This will force the client to reach out to the portal authenticate and get fresh pair of config and gateway list, and of course run the gateway selection again and connect to gateway. Refreshing connection from GUI is sure way to refresh client portal config instantly, unfortunately it requires the user to do it manually. I am not aware (and I am almost certain it does not exist) of a way to do it remotely or via command prompt.

 

Unfortunately I cannot agree with @MP18 . Kicking the users from GP gateway from the firewall doesn't seems to force them to refresh portal config. I just tested with my own connection:

- I kicked my connection from firewall GUI: Network -> GP Gatewa -> Remote Users

- It seems FW immediately have closed the tunnel, because the GUI didn't even manage to refresh. Although my GP agant was still saying I am connected

- Few seconds later GP agent when to disconnected status and said something like"restoring last VPN connection"

- After GP connect again I checked the firewall logs and shows only GP gateway logs. It is very clear that agent connected straight to the gateway and not requesting portal config.

 

 

L6 Presenter

@aleksandar.astardzhiev Yes, that has been my experience, kicking users from the portal did not result in the GP client refreshing the portal config, just reconnected to the same gateway. Looking at my own config, with a 24 hour portal refresh timer and 7 day gateway timeout, It has been nearly 48 hours without refreshing the portal config:

9/17 13:18 - portal A - portal-auth and portal-config

9/17 13:18 - gateway 3 - gateway-auth and gateway-register

9/18 19:29 - gateway 3 - gateway-preauth (internet died briefly, auto-reconnect)

9/18 21:49 - gateway 3 - gateway-auth and gateway-register (internet died for ~20min, manual reconnect)

9/18 22:07 - gateway 3 - gateway-preauth (internet died briefly, auto-reconnect)

9/18 22:15 - gateway 3 - multiple gateway-auth -register -logout (internet flaky, reconnecting)

9/19 00:06 - gateway 3 - gateway-auth and gateway-register (internet died for ~20min, manual reconnect)

 

So ran ~30 hours connected without refreshing portal config, went thru multiple gateway reconnects and then into following day, almost 48 hours and still hadn't refreshed. I logged out the gateway connection from the PA and reconnected, still no portal refresh. I did a "Refresh Connection" from the user GP client and it did a portal config refresh... Frustrating.

  • 8135 Views
  • 3 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!