GP prompts for internal gw connectivity

[Arne-VDH]

Hi all,

I've deployed a GlobalProtect installation solely for the purpose of User-ID. The GP agent connects to the internal portal/GW (one box) upon login with Kerberos SSO. However, when the internal gateway is not reachable (user has no network, user isn't on-prem), the GlobalProtect Agent notifies the user about this (no network / can't reach GW). Does anyone know how I can supress this warning?

[Mick_Ball]

Hmm.... i don't use internal gateways but don't you need internal host detection to prevent this from happening.

or have you already set this...

[Arne-VDH]

Internal host detection IPv4 is set to an internal on-prem IP and the hostname for it does not publicly resolve, plus internal gateways are configured..

[Mick_Ball]

Have you tried making the portal external, the gateway internal with host detection and allowing access to the portal from internal network.

[Arne-VDH]

No, if possible we highly prefer not to have the portal externally available.

[Mick_Ball]

Sure, i understand, but how is the client going to know about the internal host detection if they cant get to the portal.

Portal info is cached but it does not include internal host detection. I know this much because we use it to prevent users connecting to gateways when on the LAN but if the portal cannot be contacted the internal host detection does not kick in and user attempts to connect to a cached portal.

So...   I dont think you have much choice here...

[Arne-VDH]

I actually don't mind if it can't get to the portal, I just don't want users to see the message -so it's more, can I suppress the message on the client itself or not?

[Mick_Ball]

Yep, got it...   it does say that in the first post.

I am not aware of message suppression.

[OwenFuller]

I'm not quite sure on this, as I have not tried doing solely an internal gateway.  However, why not try configuring the gateway as an internal gateway, and use the internal host detection, and list no external gateways?

[Arne-VDH]

That is pretty much exactly the configuration at the moment.. 😞

[OwenFuller]

Gotcha.  You could change the connection method to on-demand, but I'm guessing that will mess with things when the users are on network.

While I know you said you prefer not to run the portal on a public interface, I'll offer this as one option to consider.  You could configure the portal w/ a different authentication method (LDAP, local, SAML, whatever), and set a long cookie timeout (365 days for example).  This would essentially let your machines authenticate with the portal once, and be done with it for a year (or longer, if you also allow the gateway logins to generate a cookie).  If you wish, you could further secure this accdss using a certificate profile, and requiring machines to have a cert trusted by the firewall.  Then, you could run your internal gateway on an internal interface w/ the kerberos SSO authentication.  Then the machines will only attempt kerberos auth via SSO to the gateway when they detect that they are inside your corporate network using internal host detection.

Sorry, I know that isn't quite what you're looking for, but I don't know of a way to suppress the notifications other than these two suggestions.  If GlobalProtect doesn't meet your needs in this area, captive portal might be a good way to capture user-id.  We do this for some of our Mac users.

[Arne-VDH]

Well the whole idea is to keep it transparant and not have users authenticate to anything. I do suppose that if I were to use cookies it wouldn't pick up users logging in or out, and on-demand is exactly what we're trying to avoid (with captive portals on top of the list :-)). The agent should be invisible to the end users, but if no one knows an alternative I'm guessing it will be support to confirm or a feature request...

[OwenFuller]

---

@Arne-VDH wrote:

Well the whole idea is to keep it transparant and not have users authenticate to anything. I do suppose that if I were to use cookies it wouldn't pick up users logging in or out

---

Yes, definitely don't want it more complicated than needing.  In my experience, it's not the connection to the portal which registers user-id, but the gateway.  If you accepted cookies for portal auth, but only accepted Kerberos SSO for the gateway, I wonder if this would still give you what you need.  Again, your deployment is a bit different than the ones I've done, so just trying to throw ideas out there.