How to force GlobalProtect user to always connect to portal

[aleksandar.astardzhiev]

Hi Guys,

For couple of reasons, recently I started to think - Is there a way to force the users to always connect to the GP portal first and don't use saved gateway config?

I have noticed that we have lots of users connecting straight to the GP gateway and haven't been connected to GP Portal for days. I am trying to figure out a way to force the users to always connect to portal first, get the latest config and after that to connect to gateway, and I am not able think of anything.

I will appreciate any ideas!

[Sarc845]

Hi Alexander,

Did you make sure to disable your portal/gateway cookie authentication?

Network > GlobalProtect > Portals > Portal Profile (your profile name) > Agent tab > Agent config > Disable "Generate cookie for authentication override" or set the timer to 8 hours or so

Once the users authenticates to the Portal it should pull the new gpconfig file and use that to connect to the Gateway

Let me know if you have this setup already?

[aleksandar.astardzhiev]

Hi @Sarc845 ,

Thank you for the suggestion, but it doesn't seems to be related to the auth cookie...

Yes we do use auth cookie, but from the below log (all of the logs are related to one user - my filter is "description contains 'name: <user>'") you can see:

- that first agant is trying to authenticate with the cookie, but it has already expired.

- So the gp agent will follow the authentication process (the authentication profile) configured under GP portal:

[BPry]

@aleksandar.astardzhiev,

What's the reason to try and force them to connect to the Portal at every connection? They'll already be doing an app config refresh at a whatever interval you've configured, and if the cached gateway can't be connected they'll go back through the complete authentication process. 

[aleksandar.astardzhiev]

Hey @BPry ,

We recently switched allow agent upgrade from disallow to allow transparently, meanwhile the config refresh is set to four hours. I was looking at the logs to see how many users have already been upgraded and noticed that lots of users are still not upgraded, because they haven't updated their config from the portal.

I was looking at some logs and I am staring to believe that the timer for the config refresh is restarted on each reconnect. A user connects directly the gateway in the morning, after few hours (less then four) it has reconnect (laptop sleep or wifi switch or something similar) again directly to the gateway. And this could happend one or twice a day and that way user will never reach the config refresh interval.

I actually noticed few users still using 4.1 version and looking at the logs for one of them it seems because he haven't contacted the portal for the last few months.

[BPry]

@aleksandar.astardzhiev,

I would look at your PanGPS.log and see if your agents are actually communicating to the portal or not. You don't have to have an authentication event on the portal for the agent to actually be refreshing the configuration. To the best of my knowledge you can't disable the configuration refresh outright, so if you aren't seeing that communication something is broke. 

You should be seeing periodic msg type = refresh-configuration in the logs according to your configured configuration refresh interval anytime your agent is connected to the gateway. You don't necessarily see an authentication event with update. The downside to you being on a release pre-9.1 is that GlobalProtect logging on the firewall leaves a bit to be desired, like the portal-getconfig events. 

[aleksandar.astardzhiev]

Hey @BPry ,

GlobalProtect logs are the main reason I want to upgrade to 9.1, but we were not sure if it stable enough yet.

I am interested in what you say - "You don't necessarily see an authentication event with update". So far from the firewall logs I see actually the oposite. See below screenshot. These are system logs filtered with "(description contains '<username>') or (description contains '<user-public-ip>') , showing connected user that is updating its portal config every four hours (as per portal config).

These are logs from user that has been already upgraded to 5.1, I just wanted to point out that from all the logs I have seen so far every portal config refresh is led by portal authentication (in this case with auth cookie, that is why no logs from auth profile).

Going back to the users that are refusing to upgrade - I started looking at the PanGPS logs and something very strange got my attention - there is a entry saying "--Set state to OnDemand mode." . Our configuration is Pre-logon (Always On) and I can see in the registy the connection method is set to pre-logon. However at this exact moment the machine is online, but no GP was connection attempt was on 10th.

[BPry]

@aleksandar.astardzhiev,

Interesting. That could simply be that you're using cookie authentication where my deployments authenticate via certificate. I've got far more refresh-configuration events than I do authentication attempts on the portal via my firewall logs. 

As for the state issue on the old 4.1 clients, I don't think that's really worth putting a lost of investigation into. The release of 4.1 that you have displayed in your logs is extremely old, and 4.1 is EoL. You'll need to have these users manually upgrade if they aren't contacting the portal to grab the new configuration that allows transparent updates and get them on a current version.