- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
03-25-2020 04:54 AM - edited 03-25-2020 04:56 AM
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)
03-25-2020 07:24 AM
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.
03-25-2020 10:09 AM
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 10.250.1.56
(T19360) 03/25/20 16:43:23:581 Debug(1835): host prxweb.yourdomain.co.uk
(T19360) 03/25/20 16:43:23:581 Debug(1852): DnsQuery returns 0
(T19360) 03/25/20 16:43:23:581 Debug(1867): Resolved 56.1.250.10.in-addr.arpa for internal host detection with return value 0
(T19360) 03/25/20 16:43:23:581 Debug(1891): The host name is prxweb.yourdomain.co.uk
(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.
08-20-2020 08:57 AM
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?
Thanks
08-06-2021 05:40 AM
Is this an Always-ON conn? or On-Demand?
Internal detection doesn't not work with OD
09-03-2021 06:54 AM
Maybe a simple security rule not allowing this traffic to get out to the gateway from your internal network?
09-03-2021 02:10 PM
Hello,
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.
Cheers!
12-03-2021 01:17 PM - edited 12-03-2021 01:17 PM
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).
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!