When configuring Always On VPN, administrators have the option to enable DNS registration for VPN clients. When this option is set, VPN clients will register the IP address assigned to their VPN interface in the internal DNS. This allows client devices to be managed using their hostname from the internal network whenever they are connected remotely.
DNS Registration
DNS registration is enabled in one of two ways, depending on how Always On VPN client devices are managed.
Intune
When using the native Microsoft Intune UI to manage Always On VPN profiles, DNS registration can be configured by selecting Enabled next to Register IP addresses with internal DNS in the Base VPN settings section.
ProfileXML
When using custom ProfileXML with PowerShell, SCCM, or Intune, the administrator will define the RegisterDNS element to enable DNS registration.
Known Issues
Some users have reported unexpected behavior when DNS registration is enabled. Specifically, under some circumstances the VPN client will register the IP address of the VPN network interface along with the IP address of its public network interface (Wi-Fi, Ethernet, etc.). However, the VPN client can only be managed using the VPN interface. If the VPN client’s hostname resolves to its public IP address, manage out will fail.
This appears to happen only when Name Resolution Policy Table (NRPT) rules are defined in Intune DNS settings, or if the DomainNameInformation element is defined in ProfileXML.
Resolution
Microsoft recently released fixes for this DNS registration issue for Windows 10. The fix for this issue is included in the following updates.
Windows 10 1803 – KB4507466
Windows 10 1809 – KB4505658
Windows 10 1903 – KB4505903
Additional Configuration
After installing the update, the following registry entry must be defined on each VPN client.
HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DisableNRPTForAdapterRegistration DWORD = 1
To enable this setting, open an elevated PowerShell window and run the following command.
New-ItemProperty -Path ‘HKLM:SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\’ -Name DisableNRPTForAdapterRegistration -PropertyType DWORD -Value 1 -Force
Once complete, restart the client device for the changes to take effect. After validation testing is complete, the registry entry can be deployed to Always On VPN clients using Active Directory group policy preferences or Intune.
Additional Information
Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML
Windows 10 Always On VPN Updates to Improve Connection Reliability
Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune
Colin
/ August 5, 2019Awesome. Thanks for the news! Does manage out work yet?
Richard M. Hicks
/ August 5, 2019Manage out should work as long as you haven’t configured any traffic filters. 🙂
Colin
/ August 5, 2019Oh that’s right! I forgot about that. I can’t imagine using it without filters so I wait for the day they fix it. I think the official doc page said they would be fixing it at a later time. I’m not sure when that is though.
Gary
/ August 5, 2019Great read, thanks for the heads up.
Scott
/ August 5, 2019Thank you for posting this! Funny thing is that we are experiencing this issue with every client at every connection. However we are still on 1709, don’t have InTune, and there is no entry for “DomainNameInformation” in our AOVPN profile. Any thoughts?
Richard M. Hicks
/ August 5, 2019You’ll have definitely have to upgrade to at least 1803 to get this fix. Microsoft won’t backport to 1709. Also, the fix seems to indicate it is related to the use of the NRPT, but I’m pretty sure people have reported issues who didn’t have the NRPT enabled. If you test this out, please provide feedback. Perhaps all that’s needed is the update and that fixes the issue if you don’t have NRPT enabled, but if you are using the NRPT then you need the additional registry key? Let me know what you find out!
Scott
/ September 6, 2019Microsoft case was just closed as “known bug” with refund but without resolution. Even after upgrading clients to 1809 and fully patching Server 2016 AOVPN servers to August19, issue of all local adapter addresses being registered in my corporate DNS still remains. I am told to try with a 2019 AOVPN server instead.
Richard M. Hicks
/ September 10, 2019The update listed in this post didn’t resolve the issue then?
scott
/ September 10, 2019No it didn’t resolve it. Msft seems to think there is more to patch. Again we have 1709 and 1809 clients authing to server 2016 fully patched AOVPN servers. All still register all of their local addresses to the Enterprise DNS along with their AOVPN IPs. When they disconnect the AOVPN IPs are auto deleted but their local addresses remain in DNS
Richard M. Hicks
/ September 12, 2019That’s definitely not good news.
Justin Goodwin
/ August 13, 2019Hi, having problems with RegisterDNS setting in a device profile. Currently using build 1903 Windows 10 Enterprise with KB4505903. If you then enumerate the CIM using WMI-to-CSP bridge and read the ProfileXML the setting is not there yet others are e.g. TrustedNetworkDetection. Does there need to be a specific place to put the setting in the XML profile? looking at the specs as longs as its a branch off of VPNProfile it should be good. Have Microsoft messed up in this release or am I doing something daft?. If I run get-dnscache the setting comes back false for registerthisconnectionsaddress for the VPN Device Tunnel. Any thoughts? Thanks Justin
Richard M. Hicks
/ August 13, 2019RegisterDNS should be nested between the VPNProfile tags. The specific tag should be RegisterDNS. Be sure it is set to “true” and not “True”. Boolean values in ProfileXML must always be lower case. 🙂 As for viewing the ProfileXML on the client, in my experience not all settings are displayed there so that’s not the definitive answer for Always On VPN settings being applied unfortunately.
Ben De Cock
/ August 19, 2019Hi Richard,
Just a quick issue i’ve been seeing in my environment:
Everything in my environment is relying quite heavelly on dhcp (LAN).
The problem I’m seeing is the way rras reserves the dhcp blobs for aovpn.
The problem I’m seeing is that every aovpn client reserves it’s dns record (a + ptr) with an ownership of the client, instead of our dhcp service account.
Resulting in the dhcp not being able to update the record in question when they move from vpn to local, and thus stale records that can’t be updated through dhcp.
Do you know of any way RRAS could register client records with a service account as owner instead of the client as owner?
Richard M. Hicks
/ August 19, 2019Interesting. I’ve not run in to this issue myself, but I don’t often use DHCP for VPN client IP address configuration. There might be a way to accomplish what you wish, but I’m not familiar with it. Perhaps others might have a suggestion here?
Colin
/ August 19, 2019Why not use static pools for the vpn clients?
Richard M. Hicks
/ August 20, 2019That’s my preference. There’s little advantage to using DHCP, honestly. The client really only gets the IP address and subnet mask from DHCP. All other DHCP options are ignored. Also, DHCP really only works for single server deployments. If you have more than one VPN server you’ll need unique IP subnets for each VPN server, which isn’t possible using DHCP.