Best practices for preventing GlobalProtect connections internally

[dfrancis]

We currently have GP configured as connect on demand and currently have both an internal and external gateway.  I'm finding that several of our users are connecting to GlobalProtect even when they are in the office, which is causing extra overhead and perceived slowness as their Internet traffic is piped out through our corporate data center.

In a test environment I found that I can enable internal host detection and not have an internal gateway setup, which will prevent the user from connecting to GlobalProtect, but they will receive a "Portal not found" message when doing so.  Wanted to confirm that this was normal behavior, or if there were a way to either customize this error message at all.

Thanks!

[OwenFuller]

You actually need to allow clients on your internal network to reach the portal, even though they won't initiate a tunnel connection to the gateway.  This will prevent the error, and will also let users log into the portal initially to pull down configs from inside the network if desired.  Try the following:

- Create a security policy allowing traffic from your Trust zone to your the public IP/FQDN of your GP portal in your Untrust zone allowing panos-global-protect as the application.
- If normally NATing traffic from your Untrust to Trust zone, create a NAT policy which excludes traffic from your Untrust zone to your GP portal from being NATed.
- Make sure your DNS server has a PTR record for the IP address you are using in the Internal Host Detection section
of the portal config (i.e. you must be able to do nslookup 10.0.0.1 and get gpcheck.domain.local, or whatever internal record you are using).
- Under Your Portal > Agent > Your Agent Config > Internal, make sure you check "Internal Host Detection IPv4" and put in the IP address and domain name for the PTR record you are using to determine that the client is on the local network.

EDIT:  I actually just considered that you could try connecting externally the first time you connect.  Once the client has the portal config with the proper IP/hostname for the internal host check, it might not error out anymore.  If you want to avoid the hassles though, do as I suggested above.

[dfrancis]

I realized part of my problem was that I didn't have a DNS entry on my internal DNS servers for the GP portal, which explains why I got the error when trying to connect internally.

As a temporary workaround I added that entry to the local hosts file on my computer (i.e. vpnx.example.com).  I have the DNS name / IP address of a server on our network listed in the Internal Host Detection section (servername.mydomain.local 10.0.0.1) and I can do an nslookup on my machine of both the address and the DNS name and they match up.  Shouldn't GP see that as part of the connection process and stop the connection vs. letting it connect?

[OwenFuller]

"Shouldn't GP see that as part of the connection process and stop the connection vs. letting it connect?"

Well, if the client can't reach the portal from inside the network, and the client connects from inside the network initially, it's not even going to get the portal config to tell it what the internal host check address is in the first place.  You could also trigger this error if a users switches from an external to internal network (e.g. from mobile hotspot to corporate WiFi), and the client is configured to try to reconnect.  This is also particularly problematic if you're using and "always on" connection method, as the client will attempt to reach the portal anytime.  Rather than getting an error, you want it to connect to the portal to check for config updates, and then not connect to a gateway, at which point the client will say "Connected - Internal" instead of connected to a particular gateway.

It's been awhile since I've done a new portal setup, so I don't recall the exact behavior, but I'm not sure you'll avoid getting the connection error if the portal isn't accessible.  You should be able to experiment a little to determine what works though.  Having setup portals a few different times now, I still suggest making them accessible from your internal network to avoid the most hangups and confusion to users.  If you're not doing desktop SSO to pass the user's credentials to the client when they log into the OS, you can use cookies, and set the portal cookie timeout to a really high time (like a year), and use a much shorter time (like a few hours) on your gateway which is the more important thing to secure since it actually terminates the VPN tunnel.  This will keep users from being prompted to authenticate to the portal when if GP tries to connect while on the corporate network.

[dfrancis]

Well crap.  I finally ran across the "GlobalProtect Not Detecting Internal Network With Interal Host Detection Enabled" article and saw this footnote:

" Note: Internal Host Detection is not supported when the  Connect Method is On-Demand"

...which is exactly what we're using.

I think the only way I can tackle this is to create an ACL to drop any connections using the panos-global-protect app from the internal network to the portal/gateway (since they both reside on the same firewall).  That would still allow internal clients to hit the portal, just not establish the connection to the gateway, yeah?

[OwenFuller]

The KB you referenced is over two years old.  I do not see that stipulation about not working w/ the on-demand connection method in the actual documentation for 9.0 nor 8.1, so I can't say for sure.  It's been a couple of years since I worked with on-demand mode, but I was thinking the internal host detection still worked.  I could be wrong though.  I would still suggest opening up the access from your inside zone to your portal as I explained in my first reply, and testing out the internal host detection for yourself that way.

If you simply drop panos-global-protect to the portal, I think you'll still be stuck with the the "portal not found" error, because I don't think the client will be unable to reach it at all.  Since this is an on-demand connection, maybe that's acceptable, since users shouldn't see it unless they try to connect internally.