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.
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.
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?
"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.
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?
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!