The internal DNS server replies with the correct A record (eg. When resolving an internal resource the client sends the DNS request simultaneously to the internal DNS server and the external DNS server. I used Wireshark a lot to troubleshoot what was happening on the wires (both on the physical NIC(s) and the VPN adapter), and I could confirm the following: Especially if the domain name in question is also registered in public DNS (the latter zone obviously not containing all the internal resource records only reachable by internal DNS servers behind the VPN). Worth mentioning is that the OS always prefers IPv6 over IPv4 (because IPv6 is the standard/current IPv6 protocol on the Internet, IPv4 is legacy - let that sink in for now :))īesides the DNS leaking (which could be a privacy issue), it causes problems resolving internal resources (but only if the physical/LAN NIC has an IPv6 address). LLMNR and NetBT) and also dual-stack preferences. Of course there are way more complicated algorithms behind, which takes a lot of factors into consideration (ie. Simply explained: Windows sends every DNS request to all servers defined on connected NIC's simultaniously and uses the reply from whichever server responds fastest.
While this behavior calls for a WTF?!, I found and believe this is actually by design, because of the "Smart Multi-Homed Name Resolution" introduced back in Windows 8, and refined in Windows 10. The symptom is that DNS requests to internal resouces fail (read: resources held by DNS zones served by the internal DNS servers defined on the virtual Checkpoint NIC).Īll DNS requests are made to the external DNS server(s), besides the internal DNS servers. Endpoint Security VPN client connects successfully to security gateway.Client has one or more IPv6 DNS server addresses defined.Internet facing NIC(s) on client has an IPv6 address (besides IPv4 because it is dual-stacked).It seems related, but then again not, so while I have your attention, here goes: FWIW, I can share another finding, but the issue below is also present in earlier clients (like E83.20) and still is.
0 kommentar(er)
