Always On VPN Client DNS Server Configuration

Always On VPN Client DNS Server ConfigurationDNS 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.

Always On VPN Client DNS Server Configuration

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.

Always On VPN Client DNS Server Configuration

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.

Always On VPN Client DNS Server Configuration

Additional Information

Windows 10 Always On VPN and the Name Resolution Policy Table (NRPT)

Deploying Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Hands-On Training

Leave a comment

48 Comments

  1. Hi! 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

    Reply
    • Correct. 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.

      Reply
  2. Robert Olsen

     /  November 7, 2018

    Hi!
    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?

    Reply
    • Incorrect. 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. 🙂

      Reply
  3. Colin

     /  February 1, 2019

    One 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.

    Reply
    • Agreed. 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.

      Reply
  4. Mike

     /  February 8, 2019

    I 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.

    Reply
    • Hi 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. 🙂

      Reply
  5. Steve

     /  April 25, 2019

    Hi 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!

    Reply
  6. Hi 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…

    Reply
    • There 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?

      Reply
      • Christof Computing

         /  November 14, 2019

        I 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

  7. Matt H

     /  November 20, 2019

    I 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.

    Reply
    • Very 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.

      Reply
  8. Hello 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.

    Reply
  9. Ryan Young

     /  February 3, 2020

    Maybe 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?

    Reply
    • The 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.

      Reply
  10. jonny3010

     /  April 14, 2020

    I 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?

    Reply
    • I’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.

      Reply
      • FingerlessGloves

         /  April 17, 2020

        But then how would you do DNS without DomainNameInformation being used? If you try and avoid it?

      • The 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, 2020

      Ehi 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.

      Reply
  11. Nathan

     /  April 16, 2020

    Hi 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

    Reply
    • Try removing the registry key HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig. Let me know how that works. 🙂

      Reply
      • Nathan

         /  April 16, 2020

        That 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

  12. I’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?

    Reply
    • No, 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!

      Reply
      • Andy Chips

         /  April 17, 2020

        Thanks Richard. You are the master 🙂
        That worked perfectly.

      • Andy Chips

         /  April 20, 2020

        Quick 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.

      • Yes, 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.

    • @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

      Reply
      • This 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.

  13. Brandon

     /  April 21, 2020

    Hey 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!

    Reply
    • That’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. 🙂

      Reply
  14. Tristan

     /  April 29, 2020

    Hey 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.

    Reply
    • Yes, 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.

      Reply
      • Tristan

         /  April 29, 2020

        Thanks 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.

      • Shouldn’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.

  15. LanDI

     /  May 7, 2020

    is 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 ?

    Reply
  1. Always On VPN Routing Configuration | Richard M. Hicks Consulting, Inc.

Leave a Reply to Andy Chips Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: