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.
Some Guy
/ December 9, 2019Nope, that is incorrect – the client most definitely *does* get other DHCP options besides just IP and netmask. That is the advantage to using DHCP! For example, I push DNS settings, classless static routes, and WPAD proxy config to clients via DHCP. The static routes is nice to have, for sure.
Actually, you can still use DHCP to push options even when assigning IPs from a RAS static pool. I have a DHCP scope that covers RAS’s static pool but with all the IPs excluded from the DHCP scope’s pool. RAS assigns IP from its static pool and then the client does DHCP request to look for additional options.
Richard M. Hicks
/ December 15, 2019That would be news to me. Everything I’ve read from Microsoft indicates VPN clients receive only the IP address and subnet mask from DHCP and that all other options are dropped. How is your environment configured? Is DHCP running on the RRAS server? Same subnet as the RRAS server?
Some Guy
/ December 15, 2019The RRAS client address pool is on its own subnet (static pool 0 to 255). The network routes this subnet to the RRAS server’s LAN NIC. The RRAS server has a persistent static null route for this subnet. On the DHCP server there is a scope for this subnet.
In RRAS server Properties IPv4 tab, “Use the following adapter to obtain DHCP…” is set to the LAN NIC. (IIRC the DNS servers configured on this NIC override any Option 6 set in DHCP.) The DHCP Relay Agent in RRAS is configured to forward to the IP of the DHCP server and is enabled on the “Internal” interface.
On the RRAS server, a Windows Firewall rule for RemoteAccess service allows to local port UDP 67 on local address 255.255.255.255. Any filtering on clients (e.g. IP Filters defined in NPS policy) has rules to explicitly allow DHCP (e.g. any/any–>any/udp67).
In the DHCP scope, all the IPs for the entire address pool are allowed but also excluded. Options are defined on this scope.
Richard M. Hicks
/ December 15, 2019Is the DHCP server on a separate server then? And is that DHCP server on the same subnet as the VPN server’s internal interface? Or is it on a remote subnet?
Some Guy
/ December 15, 2019Separate server, yes. Used to be on the same subnet as RRAS but now have RRAS in a separate VLAN for unrelated reasons. Either works.
Some Guy
/ December 15, 2019Also just to clarify since you used the term “internal interface” – I call that the LAN interface. When I say “Internal” interface I am referring to the built-in interface in RRAS that is named Internal and isn’t actually a real interface on the machine.
Richard M. Hicks
/ December 15, 2019Thanks for the clarification. Again, this goes against everything I’ve read from Microsoft on this topic. They have always stated that DHCP options are ignored. I will certainly do some testing though and see how it works. 🙂