We have an URL (for exp. sharepoint.mydonain.com) directly reachable on our internal network, with a Private-IP, but also reachable from the internet, with a Public-IP (of course, the public-IP is not reachable from the internal network 🙂 ).
It happens sometimes, with some users who are in home-office, and connected with the GlobalProtect VPN, that they don't access these URL on the Private-IP address, so through the VPN, but access the it on the public address. All this without any interruption or cut of the VPN.
On the application settings of GlobalProtect we implemented all possible features to force the DNS resolution on our internal network DNS. There is also nothing that would make this site or this IP be in one of the Split Tunnel or local breakout rules in the GP-Gateway or Portal Settings... However, it seems that for some home-office users, the DNS resolutions is still made, some times only, through the local network adapter.
Am sure is not a GlobalProtect problem, but more a problem with the local computer (Windows) network settings and management? I'm thinking especially about IPv6 which is enabled by default. Let me explain my thinking: I have never been affected by this problem because I have an FW that blocks all IPv6 traffic IN and OUT on my home network.
I know that some ISP's, most of them, don't filter anything from this IPv6 on their Internet Box (modem/router)
Is it possible that Windows, for latency problem reason in IPv4 (for example), quickly switches to IPv6-DNS resolution (that isn't active in GP), for performance reasons, and this is the reason why the connection to the URL is made on the public IP instead of the private IP ?
Any Idea, solutions, workaround or comments ?
Windows smart multi-homed name resolution can interfere with this. It will send DNS queries on all adapters:
It's also true that IPv6 can be used freely if you only have IPv4 GP configured. I don't know why this doc is only available for mobile users/Prisma Access, but the same thing applies to non-mobile users and it is basically about sinkholing the IPv6 traffic towards your GW (Note that this may need a GP GW license, but I assume you have this if you are using Split-DNS).
Read the first section and then go to 'Set Up an IPv6 Sinkhole On the On-Premise Gateway'.
Probably best if you just disable IPv6 on a client that's having the issue first, just to be sure whether it is IPv6 or not, or just running a pcap on all client interfaces to see if you are getting this from an IPv6 DNS server.
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!