Upgrading GlobalProtect while on corp network

[ce1028]

Hi everyone,

I have a client who said every time they try to upgrade globalprotect, they have mixed results. The issue seems to be that they'll set the GP App to "Allow with prompt". However, the users will never get the prompt while they are on the corporate network. It seems possibly, when the users go home, they'll get the prompt to download and then install, but maybe they shutdown or restart their machines while the install is happening, which then causes issues.  This is an assumption of what might possibly be happening.

The real question is, what is the best way to allow the upgrade to happen in the office? 

Public DNS record -  gp.domainname.com pointing to public IP of firewall e1/1 interface  (ex 2.2.2.2)

e1/1 - untrust zone  IP 2.2.2.2/24

e1/2 - trust zone  IP 10.10.10.1/24

Client on corp network 10.10.10.100/24

[vsys_remo]

@ce1028

What about configuring the setting "Allow users to upgrade global protect app" to "Internal"?

This will update the agent transparently but only when the client is in the internal network and not connected by VPN.

[ce1028]

@vsys_remo I believe an Internal gateway is required for this option?  I'd also have to consider the remote workers who are never in the office

[vsys_remo]

No, internal gateway isn't required. Only internal host detection. But yes when you have remote workers who are never in the office then this option does not work. Maybe if it is clear who always works from remote, then you could put them into a group and give them another portal config than your default configuration which then would be to allow the update only internally.

[ce1028]

@vsys_remo That's a good suggestion, as an alternative.  Is there anyway for transparent or allow with prompt to work, while on the corporate LAN?

[vsys_remo]

@ce1028 so far I am not aware of problems that the upgrade does not work from internal. Did you test it yourself? Are there any specific version updates that did fail or is the problem in general? Are the clients able to successfully connect to the portal from internal? Is TLS decryption enabled that may be breaks this connection? There could be multiple reasons causing this to fail... the client logs are probably a good place to start the search for a reason.

[ce1028]

@vsys_remo I'm going to spin up a lab soon to try it. I did see the problem at their site. This has always been an issue for them.  When internal host detection detects they are internal, they will never receive the prompt.

They do have TLS Decryption enabled.  That's a good suggestion to check.  I wasn't sure if it was the outbound NATrule causing the issue. Their internet outbound nat rule translates their internal IP to the same public IP of the GP Portal

I also noticed it takes well over 1 minute before GP detects that it's on an internal network.

[vsys_remo · Accepted solution]

@ce1028

In this case it is more likely the NAT rule which causes this problem. After you configure a no NAT rule above the existing one it probably looks better, but TLS decryption might still be the next step to check.

From what time do you count this minute and more? Start of computer, loginscreen, after successful login when the desktop is shown? And what is the connection method: always-on pre-logon, always-on user-logon, ...?

[ce1028]

@vsys_remo I was able to reproduce in my test lab. It was the NAT rule causing the issue!

GP is set to always on. I start counting once GP starts spinning.  They have not reported this problem, just something I noticed on all of their machines. 

[vsys_remo]

@ce1028

I noticed that the icon sometimes is way behind the actual status of global protect. But as long as you don't configure the setting "enforce global protect for network access" this isn't a problem, when exactly the internal host detection happens.