Internal Host detection - Needed refresh connections in some devices

[BigPalo]

Hi,

We enabled "Host internal detection" because user in company complanining about GP was taking the cursor. After configurin "Internal host detection" the GP stop taking the cursor but there are some users which its necessary to  "Refresh connection" in GP to be efective. Any idea? why some users can need to "refresh connection" in GP?

[S.Cantwell]

HI there

The first presumption is that you are configuring your GP as Always On, 7x24x365, right?

This way, GP will know that your machine is either external or internal in the network.

It uses the Internal Host detection to determine what GW to connect to.

It is not expected (based on my understanding) that being internal is automatically discovered.

Sometimes, it is needed to have the end user "refresh" their connection, especially, if they initially connected to the external Gateway.

How are you using this feature?

[BigPalo]

Connect method is "user logon (always on)".

So when users are in the office is workign fine. But customer detected that some users need to "refresh connection" to work. 

[aleksandar.astardzhiev]

Hi @BigPalo ,

As you already know "Host Internal Detection" is part for GlobalProtect Portal configuration.

When user successfully authenticate and connect to GP Portal it will pull the configuration and cache it for configrable amount of time.

If you made any changes to the portal config, users will receive only when they refresh their portal config

- If the refresh interval is reached

- if user use "refresh connection" - which will force the GP to clear the cached config and pull fresh from the FW.

In our environment I have noticed something very interesting - previously our refresh interval was 8 hours, but we had some users that never connected to gp portal, not refreshed their portal config for more than an year! My conclusion was that - because the GP Gateway is reachable and it is using the same authentication GP client will use the cached gateway config and try to connect straight to the gateway (skipping portal), once successfull user will work normally, but with laptops sleeping or user being idle, they have never been connect for complete 8 hours, so refresh interval never triggred config refresh.

So I believe that your portal config refresh it quite long and some users still haven't triggred portal connect or portal config refresh to receive the new config for host detection. The catch 22 is that if you decide to use shorter refresh interval, users still need to connect to portal to receive this information, so you will end up with some users still needing to manually refresh connection.