GlobalProtect Always On Issue

[rossm]

I am currently testing GlobalProtect Always on, I have configured to operate at user logon. The issue I am having is that on start-up of my laptop, on my corporate network I am prevented from any network access. If I connect to my public WIFI and connect GlobalProtect and can access my network ok. Reverting back to my corporate network and it then detects I am on my internal network and allows access to the network ok.

If I restart my laptop I faced with the same problem. If the laptop starts on the corporate network GlobalProtect fails to detect its on internal network.

I have configured Internal Host Detection (which is working if GP has connected previously.

It's not usable in this form, am I missing something?

[rossm]

And to follow on, if I can check the PANGPS.log after start up of the laptop there is no attempt to look at the internal host detection? Does this only work after globalprotect has connected to an endpoint first?

Also on my last restart I am not getting blocked to network access, GlobalProtect has a connection failed message!!!!! 

[Adrian_Jensen]

Yes... I had this same problem. So the GP client says it caches the previous configuration, including the internal host detect, but that only seems to work on network switches and it does not work reliably after long disconnects or rebooting the PC. Instead the GP client always tries to connect back to the portal to get an updated client config before it will attempt to do internal host detection. This make the user have to log into the portal, even when internally connected.

So in order to make it useable in an always-on scenario, where you want internal corporate/Wifi networks to just work without user interaction, you need to make the portal login automatic (the gateway login, where you actually pass VPN traffic through, can remain with required user-supplied credentials). There are a couple ways to do this. You could make the external portal not require any authentication, though that isn't ideal for obvious reasons. You could also make a separate internal portal without auth and set your internal DNS to point to it instead of the external portal (which remains with auth required).

The solution I chose was to use certificate-based authentication on the external portal, instead of user-based. The GP client connects to the portal address and uses an internal CA signed certificate (user or machine) to log into the portal and download the GP config without any user interaction. This means only corporate assets can connect to the portal, download GP client updates and configs. The GP client can then run the internal host detection in the config and if found it goes directly to "Internally Connected" without user interaction. If the internal host detection fails then the GP client goes to the gateways listed in the config (which required user/pass/MFA credentials).

Note: If you do use certificate authentication on the portal and user authentication on the gateway, the portal and gateway must be on different IPs, otherwise the gateway authentication config partially overwrites the portal config on the TCP/443, resulting in the portal cert-only authentication not working...

[rossm]

Thanks for tips Adrian,

Quick question though, how do you configure a portal for no authentication. I have setup an internal portal however i still get prompted for username and password. If i configure a client authentication on the portal i can then login ok.

But I need to to just not prompt for username and just detect its on an internal network.

[BPry]

@rossm,

When going for an always-on connection, I'd highly recommend using certificate authentication on at least the portal.