We deny DNS outbound except for domain controllers. I noticed a lot of denied DNS entries on the firewalls for users coming through globalprotect. Looking at the packet captures, the traffic is destined to the domain name's public name server ip address. The payload are "dynamic updates SOA <domain name>"
This is a DNS split-brain environment, where our corporate machines are on a domain name that is also publicly hosted.
What does not make sense to me is why is the traffic going to the public nameserver for our domain? It should be sending those updates to the internal DNS.
I should add that the ip address the clients are sending in their update is their home private IP address, not their globalprotect ip address
So this is actually being caused by SfB and the way that the application functions. SfB will utilize the GlobalProtect interface along with the local interface for the device to attempt to resolve the external access URL to see if the client is internal or external to the network; it it can't find that external access URL it will try and resolve the internal access URL for registration. You can verify this behavior in the Lync-UccApi-o.UccApilog file present within AppData\Local\Microsoft\Office\version\Tracing\ directory.
If I would have to guess, your devices are setup to utilize your external DNS servers regardless of where they are connected. So when it is utilizing the local interface it'll hit your external DNS servers instead of the internal services assigned to the GlobalProtect interface.
Thanks for reply. Interesting but I'm still a little confused. All of our clients are configured to use our internal DNS servers regardless of where they are connecting from, since we use always on VPN.
The other part is these are not dns query requests...these are dynamic updates (where the client sends the update to tell the dns server what IP address their machine is using)
Right. In my experience Skype doesn't respect the always-on VPN however and will utilize both interface (GlobalProtect and the local WAN/LAN interface) to fulfill some functionality. My assumption is that your corporate issued devices are set to utilize your public DNS servers regardless of where they are connecting instead of inheriting the connections DNS servers (for example, when your corporate issued device is connected to the users home WAN connection, it'll still send all DNS request to your public DNS servers). In that scenario if your client is sending a dynamic-update it's doing so properly, because the IP address of the client has been modified from it's last update (It's using the local interface instead of the GlobalProtect interface).
Understood on the skype part. However, our clients are configured to use internal DNS servers (DNS that runs on our Domain Controllers, which are part of RFC 1918 addresses) not public facing dns servers. We never provide clients public DNS servers, as we only allow DNS requests from our domain controllers
I don't believe while they are on VPN, they should constantly be sending their dynamic update to a public DNS server that their system is not configured to use. It's sending these dynamic updates multiple times an hour
I should also add, that some of these users are no longer using Skype. They have switched to Microsoft Teams.
I did a further test on my machine. I don't think this particular issue has anything to do with Skype.
On my machine, I started a packet capture on both my wifi interface and the GP interface. While connected to GlobalProtect, I ran command "ipconfig /registerdns".
I see two standard query SOA requests. One of them is destined to my corporate internal DNS server (active directory) and the other one is sent to my home wifi local connection. I then receive the proper responses from both.
However, when the dynamic update is sent, it uses my GP interface instead of sending to our internal servers
Here's an example. 192.168.1.139 is my home IP.
172.16.x.x is my GP IP and 192.168.x.x is our internal DNS server
68.x.x.x is the Name Server IP for the domain name. The clients should not be sending the dynamic update to this IP.
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!