Prevent Globalprotect from connecting when user on internal network

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

Prevent Globalprotect from connecting when user on internal network

L0 Member

We want to prevent Globalprotect from connecting when user is on the internal network. We have the client set to manual connect/disconnect but users can be stupid and connect anyway.

We don't have an internal gateway, and dont want any ssl tunnel when user is on internal network.

We tried putting in an ip address  of a reachable lan server in the "internal host detection" box and left the "internal gateways" list blank but didnt seem to work.

We also tried removing the DNS entry of the gateway from internal DNS zone (we have split-horizon DNS) but that was more trouble than it was worth due to caching of NX records leaving users unable to connect to VPN until zone TTL expiry when they jumped off the LAN network and tried to connect shortly after.

What is the correct way (by correct I mean best practice) to prevent clients from connecting to GP from internal network (keeping in mind we do not have internal GP gateway and do not want any VPN running when users are on LAN)


L1 Bithead

From what I understand, the only thing needed is that internal detection IP and name. I would check and make sure your reverse lookup is working to whatever you have set for DNS for your clients. Make sure it's responding with the hostname you specified in the internal host detection section in your portal configuration. I think I read something about it having to be all lowecase (can't seem to find that info again so it may be irrelevant). The biggest thing I think is that it's a reverse lookup IP>name, so if you don't have a PTR record it's not going to work properly.


Zach Biles -

L7 Applicator

yes as per @ZachBiles .


check the GlobalProtect logs.


this is how it looks when working correctly.  (Albeit "Always On") in this case...    but the process will be similar.


(T19360) 03/25/20 16:43:23:581 Debug(11593): GetNetworkTypeDS

(T19360) 03/25/20 16:43:23:581 Debug(11596): No ipv6 internal host detection.

(T19360) 03/25/20 16:43:23:581 Debug(1816): IP

(T19360) 03/25/20 16:43:23:581 Debug(1835): host

(T19360) 03/25/20 16:43:23:581 Debug(1852): DnsQuery returns 0

(T19360) 03/25/20 16:43:23:581 Debug(1867): Resolved for internal host detection with return value 0

(T19360) 03/25/20 16:43:23:581 Debug(1891): The host name is

(T19360) 03/25/20 16:43:23:581 Debug(5932): --Set state to Discovery complete

(T19360) 03/25/20 16:43:23:581 Debug(9839): SetVpnStatus called with new status=1, Previous Status=1

(T19360) 03/25/20 16:43:23:581 Debug(4112): UpdatePrelogonStateForSSO() - User-logon tunnel state = Connected

(T19360) 03/25/20 16:43:23:581 Debug(4797): NetworkDiscoverThread: network type is internal.

(T19360) 03/25/20 16:43:23:581 Debug(4803): NetworkDiscoverThread: Discover internal network.

(T19360) 03/25/20 16:43:23:581 Info ( 360): Gateway count is 0 for internal network.

Has anyone been able to figure this out? We have internal detection working with the PTR record but users can still manually connect to the gateways. Is there a way to prevent the users from connecting to the gateways manually when they are internal?



Is this an Always-ON conn? or On-Demand?


Internal detection doesn't not work with OD

Maybe a simple security rule not allowing this traffic to get out to the gateway from your internal network? 

Zach Biles -

Cyber Elite
Cyber Elite


Another thought would be, why disable it? Let the internal clients connect to an internat GP Portal/Gateway so that way you have zero trust between hosts on the LAN.


Just a thought, I know there are other factors.



Because when on site it says in the lower right Gateway External-Gateways
The network connection is unreliable and GlobalProtect reconnected using an... (then it's cut off and not fit on the screen).



  • 7 replies
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!