DNS server configuration for Windows 10 Always On VPN clients is crucial to ensuring full access to internal resources. For Always On VPN, there are a few different ways to assign a DNS server to VPN clients.
Default DNS Servers
By default, Windows 10 clients use the same DNS server the VPN server is configured to use. This is true even if the VPN client IP address assignment method is DHCP.
There may be some scenarios in which this is not appropriate. For example, if the DNS server is in a DMZ network and is not configured to use internal Active Directory domain DNS servers, clients will be unable to access internal resources.
DNS Server Assignment
To configure Windows 10 Always On VPN clients to use DNS servers other than those configured on the VPN server, configure the DomainNameInformation element in the ProfileXML, as shown here.
<VPNProfile>
<DomainNameInformation>
<DomainName>.corp.example.net</DomainName>
<DnsServers>10.21.12.100,10.21.12.101</DnsServers>
</DomainNameInformation>
</VPNProfile>
Note: Be sure to include the lading “.” In the domain name to ensure that all hosts and subdomains are included.
Reference: https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp
DNS and NRPT
Once the DomainNameInformation element has been defined, the new DNS server assignment does NOT appear on the VPN virtual adapters interface. In fact, it will still be configured to use the DNS server assigned to the VPN server, just as before. Using the DomainNameInformation element instead configures the Name Resolution Policy Table (NRPT) and assigns the new DNS server to the namespace defined by the administrator. You can view the NRPT running the Get-DnsClientNrptPolicy PowerShell command.
Additional Information
Windows 10 Always On VPN and the Name Resolution Policy Table (NRPT)
Deploying Windows 10 Always On VPN with Microsoft Intune
Dietmar
/ November 6, 2018Hi! Is that valid for both the user and the machine tunnel? I have configured both and both are connecting. However, if both tunnels are connected I cannot access domain ressources. Before I added the machine tunnel everything worked like a charm. Any ideas? Thanks in advance! Dietmar
Richard M. Hicks
/ November 9, 2018Correct. There are many issues with device tunnel/user tunnel coexistence, so you may be encountering one of them. Can’t say for sure though. Have a close look at routing, becuase that can cause problems/conflicts if configured incorrectly.
Robert Olsen
/ November 7, 2018Hi!
We have configured Always On VPN in our enviroment, both the Device tunnel and the User tunnel with IKEv2. We have also implemented the fallback to SSTP which seems to be working well also. There is only one more problem to solve, and that is to have the VPN Clients to register their VPN IP in the DNS (for Manage Out capabilities).
As I understand, the applies only to Device Tunnel, correct? That does not seem to work, the VPN clients does not get registered in the DNS. Is there a workaround for this?
Richard M. Hicks
/ November 9, 2018Incorrect. DNS registration is supported for both the device and user tunnels. Best practice is to define the RegisterDNS element only on the device tunnel if you are using it. However, be advised that there are a number of known issues with DNS registration. Sometimes it doesn’t register, other times it registers both the tunnel interface IP and the client’s ethernet or Wi-Fi IP. Be sure you are running 1803 with the latest cumulative update for the best experience. 🙂
Colin
/ February 1, 2019One thing that annoys me about AOVPN is that setting
.corp.example.net
doesn’t work to exclude an internal fqdn from using the internal dns servers. I set it for an fqdn that is available on the outside and inside and it always resolves to the inside address.
If i specify public DNS servers along with it it will resolve outside. It doesn’t seem to work as advertised. Unless I am missing something.
Richard M. Hicks
/ February 1, 2019Agreed. I need to evaluate this post again closely. When I wrote it initially this worked as expected. However, I tried it again recently for a customer and it didn’t work. I suspect that something changed in the OS that changed this behavior. The workaround is to specify public DNS servers for the namespace you want to exclude. I’m not entirely comfortable with this because there’s no guarantee they’ll be available (could be blocked by a firewall). I do some more testing soon and update the post with additional information if necessary.
Mike
/ February 8, 2019I am using AOVPN, and found that I was sending SfB traffic back over the tunnel, and encountering odd issues. I have split brain DNS, with SfB on a subdomain. I have attempted to use NRPT to send the SfB traffic out to the internet, rather than back over the tunnel, while sending traffic for the root domain over the tunnel. Initially I applied settings using GPO, but found that NRPT was applying even when the clients were connected to the internal network. I have since attempted to apply NRPT in the VPN profile; in this scenario I have found that NRPT settings are not applied until the VPN is connected. Once connected, if the client disconnects then the NRPT settings are still applied. The NRPT settings are still applied after log off / log on. A reboot of the machine finally clears the NRPT settings.
Do you know if this is the expected behaviour? Perhaps I’m missing something with how / when NRPT is applied…
Appreciate your blog posts – they have proven very useful.
Richard M. Hicks
/ February 9, 2019Hi Mike. A number of my customers have been experiencing this issue. I am also able to reproduce. It certainly appears to be a bug. I’d suggest giving Microsoft support a call to have them troubleshoot. Perhaps they can share a private hotfix or workaround with you. 🙂
Steve
/ April 25, 2019Hi Richard,
We are getting issues with clients registering there External DNS along with the device tunnel DNS into windows DNS. We are running 1803 with the April cumulative updates installed. Are you still experiencing the same thing, and have you found any workarounds?
Thanks for your wonderful blog!
Richard M. Hicks
/ April 25, 2019This is a known issue. Microsoft is aware and addressing it. No ETA on a public fix though. I’ll be sure to post something when it is released.
Gerald
/ May 22, 2019Same Problem here. Any workarounds or news on this behaviour?
Richard M. Hicks
/ May 23, 2019Nothing new to report. A fix is being worked on and should be available in the next month or so.
Scott
/ August 5, 2019We are also seeing this issue, is there a public hotfix available yet? I has been a couple months since your last update Rich.
Richard M. Hicks
/ August 5, 2019Just published this today. 🙂 https://directaccess.richardhicks.com/2019/08/05/always-on-vpn-dns-registration-update-available/
Karsten Hentrup
/ November 6, 2019Hi Richard,
I configured the NRPT for a device tunnel and set the registerdns option.
Have you heard of any dependencies using these two options? I am asking because the registerdns is not working in this combination and the checkbox “Register this connection’s addresses in DNS” is not set for the Device-Tunnel-Adapter. Removing the NRPT-Settings (Domain Name Information) leads to a correct registerdns!
When not removing the NRPT-Settings, then setting the Checkbox manually in the network connection is a workaround. Strange.
Cheers, Karsten…
Richard M. Hicks
/ November 10, 2019There was an update that addressed an issue where DNS registration was happening for both the physical and virtual (tunnel) interface, but that doesn’t seem to be what is happening here. You might try playing with the registry entries listed in this post: https://directaccess.richardhicks.com/2019/08/05/always-on-vpn-dns-registration-update-available/. Other than that, perhaps it is a bug?
Christof Computing
/ November 14, 2019I have the update and registry key applied but still experience the issue Karsten is experiencing. A workaround I am using is to run the following commands via a scheduled task.
set-DnsClient -InterfaceAlias “VPN Device Tunnel Name” -RegisterThisConnectionsAddress $True -UseSuffixWhenRegistering $True
ipconfig /registerdns
Matt H
/ November 20, 2019I noticed something interesting. I’ve ready the posts here and thought I’d chime in.
So I’m using the split DNS with NRPT.
On the server, if I change the adapter to “Allow RAS to select adapter” under “Use the following adapters to obtain DHCP, DNS, and WINS addresses for dial-up clients, this happens:
DNSServer is blank for my vpn adapter when doing get-netipconfiguration
My NRPT exclusions do work. If I ping the excluded address, they ping the outside address.
My internal NRPTs do work. They ping/resolve to internal ips as expected.
My client IP does not register in DNS
Using a packet capture, we see DNS queries gets split as expected by the NRPT table.
On the server, if I change the adapter to use my “internal nic” under “Use the following adapters to obtain DHCP, DNS, and WINS addresses for dial-up clients, this happens:
DNSServer shows the same DNS servers my internal nic shows on the server.
My NRPT exclusions do not work. They ping the internal ip.
My internal NRPTs do work. They ping/resolve to internal ips as expected.
My client IP does register in DNS.
Using a packet capture, we see all DNS queries go through the vpn tunnel instead of splitting.
This is driving me crazy. I want the client ip to register but I wan the NRPT to work as expected.
Richard M. Hicks
/ November 21, 2019Very strange indeed. This is one of the reasons I try to avoid using the NRPT if at all possible. Question…are the DNS servers configured on the internal network interface of your RRAS server capable of resolving internal hostnames? If so, I’d suggest not using the NRPT altogether. If they aren’t, or if you have some other specific reason to use the NRPT, we’ll have to continue to investigate.
Matt H
/ November 26, 2019Hello Richard,
Thank you for commenting and your valuable blog.
To answer your question, our internal DNS servers are indeed set on the internal nic of our RRAS server. They are capable of resolving internal hostnames.
For now, I am just going to use the “internal nic” under “Use the following adapters to obtain DHCP.
At least that way my client’s vpn ip does register a record in our DNS. As suggested in the comments here, I will just use a public DNS (like 8.8.8.8) in the xml for NRPT exclustions.
Richard M. Hicks
/ December 5, 2019My pleasure. 🙂 Hopefully the workaround will make things more stable for you. 🙂
Ryan Young
/ February 3, 2020Maybe I’m not fully understanding NRPT. If I configure a device tunnel to use the NRPT setting for corp.contoso.com to force certain DNS, what is the expected behavior for any other non-specified domain?
Richard M. Hicks
/ February 3, 2020The NRPT essentially provides policy-based name resolution request routing. The NRPT will direct name resolution queries for defined namespaces to specified DNS servers. Name resolution requests for namespaces not defined in the policy are sent to the DNS servers configured on the network interface of the device.
jonny3010
/ April 14, 2020I was looking to getting rDNS working with SplitTunnel, I was wondering if you’ve tried adding “10.in-addr.arpa” as DomainNameInformation record, in theory this would allow the client to reverse lookup DNS records from their IP address. If you have was there any side effects?
Richard M. Hicks
/ April 14, 2020I’ve not tried that myself. However, I typically avoid the use of the DomainNameInformation element in ProfileXML as it often causes more problems than it solves.
FingerlessGloves
/ April 17, 2020But then how would you do DNS without DomainNameInformation being used? If you try and avoid it?
Richard M. Hicks
/ April 17, 2020The VPN interface on the client will use the same DNS server configured on the VPN server. As long as the VPN server is configured with a DNS server that is capable of resolving internal names you’re good to go. If that’s not possible for some reason (for example a VPN server in a perimeter/DMZ network) then you’re stuck with using the DomainNameInformation element in ProfileXML.
Francesco F.
/ July 1, 2020Ehi Jonny3010 did you finally tried to put .in-addr.arpa into DomainNameInformation? I have the same problem with rDNS. In my case the remote client doesn’t use the same dns server as the vpn server.
Nathan
/ April 16, 2020Hi Richard
I’ve been looking at setting this up for a deployment, however the clients seem to be ignoring the NRPT for some reason I can’t work out.
It’s being deployed but the profile XML and powershell and it all looks like it’s OK. What’s odd, if I run Get-DnsClientNrptPolicy i get no results however if I run Get-DnsClientNrptRule I see the configuration. I can also see it in the local poloicy when I use GPEdit to have a look. Running nslookup and any internal resource, like SCCM server for example, it always uses the DNS Server from the local adapter and not the NRPT. What have I missed?
Thanks
Nathan
Richard M. Hicks
/ April 16, 2020Try removing the registry key HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig. Let me know how that works. 🙂
Nathan
/ April 16, 2020That looks like it’s done the trick, might need to do some checks in group policy to see if something is getting in the way.
Thankyou
Andy Chips
/ April 16, 2020I’m not sure if this problem falls into this scenario but here goes: I have a secondary split-brain DNS zone which LAN clients are able to resolve hosts against, but the AO clients are only using the external DNS servers. I want AO clients to use the internal addresses for that zone.
All other name resolution is fine apart from this.
For example, in the case of accessing our on-premises Exchange server the LAN clients resolve the internal address (good), but the AO clients resolve the external address (not ideal).
Is that a DNS search order issue?
Richard M. Hicks
/ April 16, 2020No, it’s probably a network interface metric issue. To test, use Set-NetIpInterface to set the interface metric of the VPN interface to something low like “5”. Let me know if that resolves your issue. If it does, you can make this change permanent by updating the IpInterfaceMetric setting in rasphone.pbk. A script to do that can be found here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.
Let me know how it goes!
Andy Chips
/ April 17, 2020Thanks Richard. You are the master 🙂
That worked perfectly.
Richard M. Hicks
/ April 17, 2020😁
Andy Chips
/ April 20, 2020Quick update:
I’ve just figured that if the laptop is connected on WiFi then the AOVPN IFmetric is lower than the WiFi one. If I switch to Ethernet then the AOVPN IFmetric is higher than the Ethernet one. So this means that DNS resolution order only works satisfactorily on WiFi. This is not a big deal as most people use WiFi. Of course, the Ethernet issue can be corrected as per your previous post.
Quick question: can the AOVPN IFmetric be set lower at the creation stage? If so, I’ll modify the XML files for all future installations.
Richard M. Hicks
/ April 20, 2020Yes, and this issue is quite common. User can access on-premises resoruces over the Always On VPN connection when connected to Wi-Fi, but not when they are connected to a docking station using wired Ethernet. Unfortuantlye Microsoft does not expose interface metric settings in ProfileXML. Hopefully they will one day, but for now the only option is to change the default setting on the client in the rasphone.pbk file after the profile is created. A script to do that can be found here.
Dietmar
/ April 21, 2020@Andy Chips: If you install the Profile.xml with the MSFT provided PowerShell-Scipt you can add the following lines at the end of that script:
$Benutzer = ($objuser.value).ToString()
$Benutzer = ($Benutzer.Split(“\”))[1]
#######################################
# Workaround for missing VPN settings
#######################################
$Benutzer = ($objuser.value).ToString()
$Benutzer = ($Benutzer.Split(“\”))[1]
(Get-Content -Path “C:\Users\$Benutzer\AppData\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk”) | `
ForEach-Object {$_ -replace ‘VPNStrategy=.*’, ‘VPNStrategy=14’} | `
ForEach-Object {$_ -replace ‘NumCustomPolicy=.*’, “NumCustomPolicy=1 `r`nCustomIPSecPolicies=020000000200000003000000030000000200000003000000”} | `
ForEach-Object {$_ -replace ‘IpInterfaceMetric=.*’, ‘IpInterfaceMetric=10’} | `
ForEach-Object {$_ -replace ‘Ipv6InterfaceMetric=.*’, ‘Ipv6InterfaceMetric=10’} | `
Set-Content -Path “C:\Users\$Benutzer\AppData\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk” -Force
Richard M. Hicks
/ April 22, 2020This will certainly work, but be advised that if there are any other VPN profiles configured on the client it will change them as well. This may not be desired. The script that I created allows you to selectively edit rasphone.bpk settings for only a specific VPN profile. You can find the script here.
Brandon
/ April 21, 2020Hey Richard,
Something we’ve noticed and not sure if it’s something we’ve missed in config.
The DNS servers list remains empty if you into the IPv4 settings of the AOVPN connection.
On the corporate network, the DHCP server provides the option for domain name suffix and search list.
So when a user is working remotely from any network with a different domain, the AOVPN will not route traffic correctly, it will only use external DNS.
I’m thinking this means we need to move the Domain Name setting and DNS search list to GPO instead of DHCP so the settings persist?
Thank you for your great blog!
Richard M. Hicks
/ April 22, 2020That’s expected. The VPN client will use the DNS server assigned to the VPN server. You will only need to define the DNS suffix for all of your internal domains on the VPN client connection. Should work fine after that. 🙂
Tristan
/ April 29, 2020Hey Richard,
Can I confirm how traffic routing should work here. Always On VPN works fine and clients can access the network. Should admins be able to access VPN clients as normal (Ping, RDP etc) when they are connected? Thinking in terms of deploying software and updates.
VPN server is on the LAN (multiple NICs 1 for Corp Lan and 1 for DMZ) and split tunnelling is used for VPN clients. Im guessing there is additional firewall config required to achieve this.
Richard M. Hicks
/ April 29, 2020Yes, you should be able to connect to clients connected remotely. You’re right, the Windows firewall must be configured to allow whatever protocols and ports you need to perform the required management tasks. The VPN interface should have the Domain profile, so make sure you define any firewall rules for remote management on that profile and not the Public or Private profiles.
Tristan
/ April 29, 2020Thanks Richard.
Is there any additional config required on the VPN server or firewall needed? Seems blocked even with Windows firewall disabled.
Guessing I’m missing something – thanks.
Richard M. Hicks
/ April 29, 2020Shouldn’t be. I’d suggest making sure the client firewall is enabled and then enable logging. That will at least tell you if the traffic is making it to the client and if it is being allowed or dropped. Also, make sure you are managing out from a subnet that the client is able to route to.
LanDI
/ May 7, 2020is there away to set it to set eeh exceptions to use “local DNS” whatever that may be on the client machines rather than a public DNS e.g. 8.8.8.8 ?
Richard M. Hicks
/ May 14, 2020Unfortunately, no. :/
Brian Steele
/ September 11, 2023I know this seems to be an old thread, but I ran into this same DNS-related issue with my AOVPN installation. Resolution requests for Internet domains were being sent to the corporate DNS via the AOVPN link when the clients were connected by wireless to the Internet, but not when they connected via wired connection to the Internet.
Instead of fudging the metrics for the connections, I just fudged the AOVPN server. Installed the Windows DNS service on it, configured a conditional forwarder in its DNS service to point to the DCs to resolve FQDNS in our internal domain, and ensured that it the DNS could also resolve Internet domain names (i.e. DNS traffic to the Internet was not being blocked). Then, I configured the server to use itself for DNS. So even if a name query for an Internet site was sent over an AOVPN link from a client, it would still resolve correctly. Seems to be working fine as a solution. So far, LOL.
Richard M. Hicks
/ September 12, 2023Great to hear! 🙂
Olly
/ December 9, 2020I’m probably missing something but I’m unable to ping clients from the internal network using their FQDN. Clients can ping back to the internal network and resolve DNS address fine. I have AOVPN set to forward ipv4 address assignments to our DHCP server and clients are getting their IP ok. What I do see in the DHCP server which I don’t understand is that in the list of leases, all the clients are showing as having the FQDN of the RRAS server itself rather than the clients FQDN. Is there a way to get clients to register with DHCP with their own FQDN instead?
Richard M. Hicks
/ December 9, 2020That’s expected and by design. When using the DHCP client IP address assignment method in Routing and Remote Access Service (RRAS), the VPN server leases blocks of IP addresses from the DHCP server and hands them out to clients as needed. However, as long as your VPN clients are configured to register their IP address in internal DNS, they should do so and resolve to the IP address assigned to the VPN interface. Also, ensure the Windows firewall on your clients allows whatever traffic you need such as ICMP Echo Request, RDP, SMB, etc.
Dan Poulter
/ January 24, 2021I’ve included the RegisterDNS option in the XML but it’s not registering in DNS, when I look at the adapter the check box which stipulates that the device registers the connection is DNS is not checked, I assume the RegisterDNS option should be checking this box as when I manually check it it’s works perfectly? Have you come across this issue at all?
Thanks
Richard M. Hicks
/ January 26, 2021I’m hearing some reports similar to this. Not sure what the cause is though. Seems to be quite random as well. :/
Chris
/ November 2, 2021My AO VPN Servers are not domain joined.
But the internal Interface is in the same subnet as the domain joined VPN notebooks. Is it recommended to add a primary suffix from the domain to this internal interface?
At the moment I only have suffixes configured globally via: Set-DnsClientGlobalSetting -SuffixSearchList
Richard M. Hicks
/ November 2, 2021I usually do that, yes. However, if you have it defined globally it might not be necessary. If you can resolve internal hostnames using their short name it should be ok.
Tor Marius
/ January 20, 2022Hi,
we are about to change the Idress of the DNSserver. what is the easiest way to upgrade the AOVPN setting on the client?
Richard M. Hicks
/ January 20, 2022Unless you’ve configured the VPN client differently, the VPN client will inherit the DNS servers configured on the network interface of the VPN server it connects to. So, if you update the DNS servers on the VPN server, clients will use these new DNS servers the next time they connect. However, if you have configured the NRPT in your VPN profile on the client, then you’ll have to update the client-side configuration. Here, if you are using Intune, you just update the settings there and your endpoints will pick up the new settings the next time they sync. If you are using PowerShell with SCCM or something else, you’ll have to deploy new VPN profiles entirely.
RGB
/ April 1, 2022Hi,
I’m using AOVPN Device Tunnel with Azure P2S VPN with domain-joined clients. Overall it’s working well except for dynamic dns registration. This only works when setting DNS to access “Secure and Unsecure” updates, but that is not acceptable in our environment. Is there a way to get it working with “Secure Only” updates?
Richard M. Hicks
/ April 5, 2022I’m not sure, to be honest.
Søren
/ May 25, 2022Hi Richard. You seems to know all there is to know about Always On VPN. Maybe you can advise me here?
At our company we have a licens to a website which hosts dictionaries, from the office, we can access it without any login, as the license is network based.
However, when people work away from the office and use Always On VPN, the website don’t work and asks for a login.
So, i’m thinking I need to add the website as “trusted” or “internal” or whatever its in the userprofile.xml? and then deploy to all laptops
Richard M. Hicks
/ May 25, 2022Your only option to route public websites over the VPN tunnel is to use IP routing. With that, you’ll need to know the IP address(es) of the website and you’ll need to include those IPs in the routing table on the VPN client. Alternatively, you could configure your clients to use an on-premises proxy server for that specific namespace. You would need to configure a proxy autoconfiguration (PAC) file to support that, though.
Nick Doud
/ September 28, 2023S0ren – if you are using split tunnel, try Force tunnel?