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. 🙂
Bob
/ April 3, 2020I have tested on 1903 and 1909 both with the latest updates. With the reg key set to 1 nothing gets updated in AD DNS, with it set to 0 the same behaviour of storing the local interface still occurs. I have tried re-configuring the XML to remove NRPT, and trying all the options re DNS registration I can find and I think this is still broken. L2TP VPN, no problems, registers correct interface IP in AD DNS everytime.
Did anyone get this working yet?
Richard M. Hicks
/ April 3, 2020I’ve had administrators report success when changing the VPN interface metric to a lower value than the Wi-Fi or Ethernet interface. Try doing that and let me know how it goes.
Robert Meany
/ April 8, 2020The issue I seem to be having, is that if I apply the registry change mentioned in the article, the remote device completely stops registering with DNS.. Without the registry entry enabled, it goes back to registering both the VPN IP and the local adapter IP…
Robert Meany
/ April 9, 2020I was thinking as a workaround that perhaps I could disable DNS registration on the client and enable the Windows DHCP feature for automatic registration of clients that do not request registration on our DNS.. The issue I ran into with that is that RRAS seems to act as a broker for the DHCP assignments, even when DHCP passthrough is used, so the VPN client is not actually requesting the IP from the DHCP server directly. The only way I can think to work around that, unless there is some feature of RAS that I am unaware of that makes the server completely transparent to client DHCP communication, is to use something other than RRAS for hosting the VPN connections. I have a Cisco ASA firewall which could be used… Not sure I can be bothered with that at this point just to address this one issue.
scoot
/ April 10, 2020The DNS servers are passed by the AOVPN server statically set DNS in the interface config. Set them statically and remove DNS servers from the xml. If you use Umbrella Roaming client the metric set to 4 or lower will force DNS over VPN. If split tunneling the metric will not break it if your xml is correct.
Richard M. Hicks
/ April 11, 2020Thanks Scott! I know this definitely solved the problem in your environment. 🙂
Richard M. Hicks
/ April 10, 2020Odd. When the VPN is connected have a look at the interface metric and make sure it is lower than your Ethernet connection. If it isn’t, try changing it and see if that does anything different. You can temporarily change this by using the Set-NetIpInterface PowerShell command. You can change it permanently by updating the setting in rasphone.pbk. A script to do that for you can be found here.
Robert Meany
/ April 11, 2020Thanks for getting back.. Unfortunately I won’t be able to test – I ended up deploying DirectAccess because we needed a quick solution on this. I’ll keep it in mind if I revisit in future.
Speaking of which – I had posted a dumb question about being unable to manage-out, for which ISATAP was the answer, I don’t remember what post I commented on.. You can ignore that question as I figured it out..
Dean
/ April 24, 2020We also have the same issue – once we apply the registry change, devices stop registering themselves into DNS completely. We also have the Cisco Umbrella Roaming Client deployed; can you please provide more info on what is causing the conflict and what you’ve done to fix it as the brief details provided by Scot don’t seem clear enough?
Thanks in advance!
Richard M. Hicks
/ April 24, 2020I’ll see if I can get Scott to provide more detail. 🙂
Scott
/ April 24, 2020RESOLVED: Our environment is 2016 AOVPN servers, 1709, 1809 and 1909 clients, all with Cisco Umbrella Roaming clients. I have 2 Umbrella virtual appliances in each office. We use the User based AOVPN profiles, no computer based tunnels. We do split tunneling. I deployed the NRPT change NOT via registry but by GPO to all computers (Specify Global DNS>Ebanled>Checked Use global DNS) and noticed no change in the issue where both the local (home) ip v4 address was registered in corporate DNS along with the desired local client VPN address. I even opened a ticket with Microsoft and they could not resolve. We still have this setting enabled. However I did not have the same behavior you mention that no DNS was registered.
I had given up on resolving the NRPT issue, however it was resolved when we had other issues with VPN clients not using internal DNS servers.
I was able to provide Umbrella with documentation to update (hopefully) on their website (https://support.umbrella.com/hc/en-us/articles/230561147-Umbrella-Roaming-Client-Compatibility-Guide-for-Software-and-VPNs) about their stated non-compatibility with Windows VPN. Basically I never set the DNS servers in the AOVPN profile. Instead I set the 2 site local Umbrella VA addresses as static DNS on each AOVPN server in their NICs. The reason is that once the Umbrella Roaming Client sees the internal VA’s it basically turns off and stops using the loopback address 127.0.0.1 for DNS servers. That is the stated incompatibility for Windows VPN and Umbrella.
Issues we faced: We had clients who would resolve the external FQDN for internal resources when we had matching internal and external DNS names. We also had FiOS and Cox home users who had DNS helpers which would resolve an IP address for any DNS name regardless if it was real which caused those end users home routers to give internal FQDN to resolve to their advertising landing pages.
So how did I get all this to finally work? I forced all traffic initially over VPN interface by setting the IPv4 metric to 1, which is now being deployed across my company. It needs to be below 5 since that is the lowest metric that Windows will auto set (rare cases if you have a 10Gbps connection at home). Because the DNS servers are passed from the AOVPN server to each client as mentioned in the third paragraph, and the metric forces all traffic to use the gateway of the lowest metric interface, now the VPN adapter, we saw all DNS traffic go to the internal VA’s. The Roaming client deactivates. The VPN adapter knows it cannot resolve IPs that are not local and sends all split public traffic to the next lowest metric’ed adapter.
In the end we saw the issues with double DNS registration cease, in that we only see the VPN provided IP in DNS now!!!! We also saw that all DNS is still protected by Umbrella, just not via the “incompatible” roaming client. Internal addresses are always hit first even when the same FQDN exists externally. And finally home users with DNS hijacking providers were able to use all private and public services without issue anymore.
Hope this helps Dean and Richard!
Richard M. Hicks
/ April 25, 2020Thanks for the detailed response Scott. No doubt this will help many others. Thanks again!
Scott
/ April 25, 2020To reiterate – Set your VPN interface metric to less than 5 – I did 1. Do not leave it on auto. Richard has scripts available to do this with a .pbk file. Powershell changes are not sticky following a reboot.
Just to clarify – when you set the static DNS server addresses on the NIC of the AOVPN server, and you don’t have DNS servers set in the AOVPN profile, then the server passes its DNS servers to the client. This action disables the Umbrella Roaming Client and therefore removes the local loopback 127.0.0.1 address from any DNS server list. All DNS traffic is resolved by the internal Umbrella Virtual Appliance but split tunneling for other protocols still remains.
Richard M. Hicks
/ April 27, 2020The PowerShell script I created to edit the rasphone.pbk file can be found here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.
Example:
.\Update-Rasphone.pbk -ProfileName ‘Always On VPN’ -InterfaceMetric 1
Dean
/ April 28, 2020Thank you both so much for your detailed response. Unfortunately we only have the Umbrella Roaming Client on all devices, no Virtual Appliances, and I think the organisation would be loathe to deploy them just to solve a management issue.
We could remove the DNS config from our AOVPN profile, but I would rather split-DNS resolution with NRPT rather than tunnelling all DNS queries to the on-premise DCs.
Back to the drawing board for us..!
aventador06
/ June 11, 2020Hi,
I’ve setup everything and AOVPN is going up but I have this DNS problem. I’m on 1909 CU June.
I’m setting up a Device VPN and a User VPN.
They all have an Index = 1 but still, I only get the external IP that’s registered in the DNS (not even the one assigned to the VPN).
I want to do split-tunnel so what am I missing here?
Thanks
Richard M. Hicks
/ June 13, 2020So you are having issues with name resolution? Or clients registering their VPN interface IP address in internal DNS?
aventador06
/ June 14, 2020Hi again,
I’ve tried to publish a reply to my problem but it didn’t appear.
I’ve solved this problem by removing the DomainNameInformation section from my Device XML.
I configured the DNS on the Internal-Facing NIC of the RRAS server after taking a closer look at your article and everything is perfect now.
I now have 1 main problem: VPN tunnel bandwidth tops at 710 ko/s and seems to loose connectivity after a certain amount of data transfer. I cannot copy a 65 Mo file to a file server without loosing connection.
I need to dig into this because, maybe, I’ve missed something in your articles. Do you have any guidance to where I should focus my researches?
I’ve configured security according to your recommendations for both IKEv2 device and user profiles:
AuthenticationTransformConstant: SHA256128
CipherTransformConstants:AES128
EncryptionMethod: AES128
IntegrityCheckMethod: SHA256
DHGroup: Group14
PfsGroup: PFS2048
The other one is with W10 2004. It’s acting weirdly. I see like 5 user VPN coming on the RRAS for the same user from this computer and the computer tells it cannot connect because the RRAS server wasn’t available… I’ll leave this for further testing.
Richard M. Hicks
/ June 18, 2020I’ve heard there are issues with IKEv2 IPsec rekeying, perhaps that could be causing your issues. This is a known issue that hasn’t yet been resolved by Microsoft. You can verify this by enabling IPsec auditing and looking at the event logs. I’d also suggest giving SSTP a try to see if it provides more reliability. It will certainly provide better performance.
Heidi Damian
/ June 22, 2020Hi, I’m facing the problem to connect to the vpn with Windows 10 VPN, I’m using Checkpoin Capsule VPN. I did the procedure that has describes Scoot, change the metric of the vpn interface to 1 but the problem persist. Another test I did, it was to set the vpn interface metric to one and set the wifi interface metric to 2. But the problem persist.
Richard M. Hicks
/ June 23, 2020I don’t have a Checkpoint firewall/VPN to test with so I can’t confirm this behavior. Anyone else?
Ert
/ June 24, 2020Hi Richard,
I am having an issue and I am wondering if you have experience with this scenario:
– Device + User tunnel deployment via Intune with custom XML
– Originally set the Device Tunnel to register in DNS
– Changed both XML configurations to register the User Tunnel instead
After doing the above change, the User Tunnel is now registering in DNS, but the problem is the Device Tunnel is still doing so as well.
I originally tried to disable registration on the device tunnel just by moving the true from the profile. However, when that didn’t work I tried false which also is not working. The option is still checked in the GUI and IpDnsFlags is still set to 1 in the rasphone.pbk for the device tunnel.
It seems like once you set that option, at least via the Intune deployment method, you can’t undo it? Unless there is something I’m missing. I did also add and then removed a route from the device tunnel to ensure it was being updated correctly, and that was successful.
Richard M. Hicks
/ June 24, 2020That’s odd for sure. It does sound like you can’t make the change after the profile is deployed, as it seems the settings are sticky based on your experience. Can you confirm it still happens if you remove the VPN profile completely and re-create it, both on the client and in Intune?
Ert
/ June 26, 2020I did try to remove the Device Tunnel interface and then forcing an Intune sync so it would be re-created, and the new tunnel did not have the register DNS option – so that works.
I also spot checked a few users machines, and some of them appeared to have had that option disabled as well. My current theory is this might be related to manual modification of the Intune deployed tunnel.
In my case, I had modified the interface metric of the device tunnel, and the DNS registration option did not turn off. However, the user I checked had never modified their tunnel and the DNS registration was disabled by Intune.
So maybe if we manually tweak the tunnel interface after Intune creates it, it then has trouble with changing those settings via XML updates?
Richard M. Hicks
/ June 29, 2020I guess that’s possible. I’d have to do some more testing to prove that out, but it sure sounds plausible based on your experience.