GP prompts for internal gw connectivity

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

GP prompts for internal gw connectivity

L3 Networker

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?

 

GP GW Prompt.png

12 REPLIES 12

L7 Applicator

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...

 

 

int gateway.jpg

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..

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

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

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...

 

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?

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

I am not aware of message suppression.

L4 Transporter

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?

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

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.

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...


@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.

  • 6339 Views
  • 12 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!