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.
Jonatan Kragh Hovgaard
/ January 8, 2021I am experiencing the same problem with “RegisterDNS” in my device tunnel configuration. From my point of view it seems like it doesn’t work in 20H2. “Set-DNSClient … -RegisterThisConnectionsAddress $True” will fix it, but I don’t understand why it is needed.
Richard M. Hicks
/ January 9, 2021Odd. I’ll do some testing with 20H2 soon and see if I have the same issue as well.
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. 🙂
akismetuser135850240
/ March 31, 2020Hi, thanks a lot for this tips.
I didn’t find the appropriate KB for windows 10 1909 and just adding the registration key didn’t work at this time.
Any ideas ?
Thanks a lot
Richard M. Hicks
/ March 31, 2020I believe the fix for this issue in 1903 and earlier is included in 1909. No need to apply an update.
victor bassey
/ April 20, 2020Same experience for me. 1909, added registry key, but issue still remains. was anyone able to fix this? i currently have a case with MS.
Richard M. Hicks
/ April 20, 2020Can you try setting the metric for the VPN interface to a number lower than all others? You can do this temporarily using the Set-NetIPInterface PowerShell command.
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
Dale Hopper
/ July 9, 2020Scott just to say a huge thanks for your response, im running an almost identical setup, with the VPN profile connection with a metric of 1, however we were pushing DNS requests on our AoVPN profile at our On-Prem Windows servers running DNS and not the Umb VA, and the VPN servers NIC were also looking at the Windows DNS servers not Umb VA. This way we were still getting both the IP’s register on our Windows DNS server of the VPN Profile and their home internet dhcp address. Il attempt your setup to see if we can fix the duplicate IP issue – many thanks
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.
grahampriley
/ July 17, 2020I am having a problem with my VPN client not registering its VPN IP with our internal DNS servers. I am running Windows 10 1909 and I am testing with PowerShell + ProfileXML.
In the profile I have RegisterDNS set to true. Could I just check, does this setting control the “Register this connection’s addresses in DNS” tick box under the DNS settings of the IPv4 section of the VPN adapter? I have tried all sorts of combinations and I have never seen a tick in this tick box.
If I manually tick it, the VPN adapter successfully registers its IP.
Thanks,
Graham
Richard M. Hicks
/ July 21, 2020You have RegisterDNS set to ‘true’ and not ‘True’, right? Oddly, boolean values in ProfileXML (true/false) must be in lower case. Unusual that something in the Microsoft world would be case sensitive, I know. 🙂
Graham
/ July 20, 2020Hi Richard,
Could I just check something with you. Is the RegisterDNS property responsible for ticking or unticking the “Register this connection’s addresses in DNS” checkbox in the VPN adapter IPv4 – Advanced – DNS properties?
I cannot for the life of my get a tick to appear in this box! When I manually tick it, everything works. I have been using a workaround found in the comments of another one of your articles: set-DnsClient -InterfaceAlias “VPN Device Tunnel Name” -RegisterThisConnectionsAddress $True -UseSuffixWhenRegistering $True
ipconfig /registerdns
Richard M. Hicks
/ July 21, 2020Yes, it does. Make sure that you are using ‘true’ and not ‘True’ as boolean values in ProfileXML (true/false) must be in lower case.
Glen Harrison
/ July 22, 2020Hi Richard, Hope you are well. Sorry to bother you, but since we last spoke we have made great progress with aovpn. The only bit which I am struggling with is DNS. I have added this into the profile.ps1 but it simply won’t resolve servernames to IPs.
.domain.ac.uk
10.100.0.13,10.100.0.14,10.100.0.11,10.100.0.12
The only way I can get it to work is by adding this command to the bottom of the script which actually works great. Any ideas? or can I simply leave it as-is?
Set-VpnConnectionTriggerDnsConfiguration -ConnectionName “Works VPN” -DnsSuffix “domain.ac.uk” -DnsIPAddress “10.100.0.11” -PassThru -Force
Richard M. Hicks
/ July 22, 2020Is there a specific reason you are using the DomainNameInformation element? I rarely use this setting and typically avoid it as much as possible. The VPN client will automatically be assigned the DNS servers that the VPN server is configured to use. As long as those DNS servers are capable of resolving internal names you don’t need DomainNameInformation.
Glen Harrison
/ July 22, 2020The RAS server is in a DMZ using googles DNS. The last part of my previous post was actually incorrect. In troubleshooting it today, the only way I can make DNS work is by manually entering the DNS server directly to the VPN adapter on the client. Unfortunately, you can only set this via commandline when the VPN is connected, so when I image clients via SCCM I can’t set the DNS. This is a bit of a pain. Help!
Richard M. Hicks
/ July 22, 2020Ok, if the RRAS server isn’t joined to the domain or isn’t using domain DNS servers then you must use the DomainNameInformation element. However, if that’s configured correctly your clients should use those DNS servers for that specified namespace. Have a look at the client’s Name Resolution Policy Table (NRPT) using Get-DnsClientNrptPolicy and make sure those entries are in place. Also, be sure to use Resolve-DnsName and not nslookup.exe when troubleshooting name resolutions on the client.
Glen Harrison
/ July 22, 2020Get-DnsClientNrptPolicy returns a blank (windows 10 2004) but Get-DnsClientNrptRule seems to bring some information back. I can see my internal domain listed with the right DNS servers. Resolve-DnsName server.domain.ac.uk comes back with DNS name does not exist.
Richard M. Hicks
/ July 23, 2020Ok, that’s definitely an issue. I’d suggest looking for the presence of the following registry key. If it is there, delete it.
HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig\
Let me know how it goes!
graham
/ July 22, 2020Thanks Richard, apologies for the duplicate questions. Yes I have it set to ‘true’. Could I be really cheeky and ask you to cast your expert eye over my Profile? https://pastebin.com/Z4HEkS9Y to see if you can see anything wrong with it?
Many thanks,
Graham
Richard M. Hicks
/ July 22, 2020There’s an error in your ProfileXML syntax. Specifically, there’s an unclosed Route statement at line 41. I suspect that everything after that is not being processed. If you simply delete line 41 it should work. 🙂
grahampriley
/ July 22, 2020Thanks Richard, I actually removed some routes before uploading the XML file so I must have missed that in my haste. Does everything else look OK?
Also, related to your above reply to Glen, our RRAS server is not domain joined, sits in our DMZ but does use our internal DNS servers. Does that mean we do not need to include the DomainNameInformation element in the XML profile? Also do we need to add our domain suffix in the advanced properties of the RRAS server?
Thanks again for all your help.
Richard M. Hicks
/ July 23, 2020The only other issue I see is that you don’t have the DnsSuffix element defined. Also, if your VPN servers have DNS serves assigned that can resolve on-premises Active Directory domain names you can safely remove the DomainNameInformation element as it is redundant. I might also suggest removing the TrafficFilter element for initial testing. If it works you can add it back and see if it breaks.
Glen Harrison
/ July 22, 2020I think I may have finally got it working. If I delete this key, the policy command works and I can resolve DNS. https://social.technet.microsoft.com/Forums/sqlserver/en-US/99b7ad27-e58e-411c-8fa8-12782992ee3b/always-on-vpn-local-dns-issue-for-clients-using-a-nic?forum=winserverNIS
Richard M. Hicks
/ July 23, 2020I see you already found the fix! 🙂 I added a comment to that thread reminding folks to always use the PowerShell Resolve-DnsName command to test name resolution on a Windows 10 client. Nslookup.exe can yield unexpected results, especially when the Name Resolution Policy Table (NRPT) is enabled (which happens when you define the DomainNameInformation element in ProfileXML).
grahampriley
/ August 5, 2020Hi again Richard, would you be able to cast your eye over my XML profile to check it for errors? https://pastebin.com/a75yBuRp
I still cannot get the tick in the Register DNS box for the VPN adapter. I’ve tried on multiple freshly installed 1909 machines too. Any ideas? Everything else works perfectly and although I can use the PowerShell script to register the VPN adapter IP I would prefer for it to work as it should.
Richard M. Hicks
/ August 6, 2020I don’t see anything out of the ordinary with your ProfileXML. If RegisterDNS is set to that box should be checked. Can you try setting the value of IpDnsFlags in rasphone.pbk to “1” and see if that works, and if the setting sticks? If so I can add it to my Update-Rasphone.ps1 PowerShell script for future use.
MACS
/ August 6, 2020We use DHCP Proxy account to register all DNS records on the network when they are assigned by DHCP. When VPN clients try to update their DNS they are running into a security issue because “DHCP Proxy” account is the owner of the DNS record so the DNS entry never gets updated with the VPN address. If I re-configure DHCP server to only register records when requested by the client then I end up with duplicate records when switching between wired and wireless NICs on the laptop. I am using static pools to assign addresses. Any advice on how to overcome this. We are a school district and with COVID we will really need the manage out capabilities for our VPN clients.
Richard M. Hicks
/ August 6, 2020No good way around this unfortunately. It might be helpful to reduce the default TTL for DNS records when they are created, but when a client moves from one interface to another and re-registers there will always be some overlap and potential delay based on DNS propagation and replication latency.
JeffJack
/ September 4, 2020My DNS registers correctly but I can’t figure out how to get DNS to keep up with the constant changes in IP every time a client disconnects and gets a new IP. Anyone have a resolution for this? I’d love to get some thoughts. My DNS servers also have duplicate machines registered to the same IP because of this.
Richard M. Hicks
/ September 5, 2020This is always a challenge, especially in large environments. Often there are replication delays that prevent name resolution from working correctly. If you are seeing a lot of stale entries you could lower the TTL for DNS records to see if that helps.
Phil Brett
/ October 21, 2020After a fair few days of trying to resolve this problem using Azure VPN Gateway and I think I’ve found the missing element. DeviceTunnel VPN IP addresses were not registered and the local machine IP registered in its place, I used the ‘DisableNRPTForAdapterRegistration’ DWORD but all that happened then was that no registration occurred for any address. I setup the deployment script to use the Update-Rasphonebook.ps1 and was seeing the lowest metric but still no registration. Finally after a lot of thinking I changed the Azure VPN Gateway VNET which had been left to use “Azure DNS” to switch to the domain controllers that were in Azure and all devices registered with the correct VPN interface IP address. I did complete a Azure VPN Gateway reset too and all looking good!
Richard M. Hicks
/ October 24, 2020Great to hear! 🙂
Paddy Berger
/ November 13, 2020Hi Richard,
I have been running aovpn fine however have come across an issue where if the laptop is started with wifi disabled and ethernet plugged in, network drives do not work. The fix I found was to set the vpn metric to 1. However I have now deployed to over 100 users. I want to add this to the vpn prfile.xml but cannot find the correct syntax to add this. We are pushing this out via intune. Any idea what the syntax is and would it go in the section where we state the IP addressing, etc.
Richard M. Hicks
/ November 17, 2020There’s currently no option to define the VPN interface metric in ProfileXML. You can update the interface metric in rasphone.pbk though. I have a PowerShell script that allows you to do this if you like.
https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1
Example syntax: .\Update-Rasphone.ps1 -ProfileName ‘Always On VPN’ -InterfaceMetric 3
Glen Harrison
/ November 18, 2020Amazing timing!! I’ve had to drive into the office today to troubleshoot our AOVPN laptops. We had an issue whereby everything was running great, until the users returned back into the office, then went home again. I can only assume whilst back in the office, the corporate wifi was then trying to route all traffic over its interface rather than the VPN when they returned home. Using this PS script and setting the metric to 3 has done the trick 🙂
Tektrick
/ March 31, 2021Hi Richard,
is there a way to set the metric in the ProfileXML file?
Richard M. Hicks
/ April 1, 2021Unfortunately, no. You can only make this change persistent by updating the InterfaceMetric value in rapshone.bpk. You’ll find a script to automate this process here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.