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

Always On VPN and the Name Resolution Policy Table (NRPT)The Name Resolution Policy Table (NRPT) is a function of the Windows client and server operating systems that allows administrators to enable policy-based name resolution request routing. Instead of sending all name resolution requests to the DNS server configured on the computer’s network adapter, the NRPT can be used to define unique DNS servers for specific namespaces.

DirectAccess administrators will be intimately familiar with the NRPT, as it is explicitly required for DirectAccess operation. Use of the NRPT for Windows 10 Always On VPN is optional, however. It is commonly used for deployments where split DNS is enabled. Here the NRPT can define DNS servers for the internal namespace, and exclusions can be configured for FQDNs that should not be routed over the VPN tunnel.

To enable the NRPT for Windows 10 Always On VPN, edit the ProfileXML to include the DomainNameInformation element.

<DomainNameInformation>
   <DomainName>.example.net</DomainName>
   <DnsServers>10.21.12.100,10.21.12.101</DnsServers>
</DomainNameInformation>

Note: Be sure to include the leading “.” in the domain name to ensure that all hosts and subdomains are included.

To create an NRPT exclusion simply omit the DnsServers element. Define additional entries for each hostname to be excluded, as shown here.

<DomainNameInformation>
   <DomainName>www.example.net</DomainName>
</DomainNameInformation>
<DomainNameInformation>
   <DomainName>mail.example.net</DomainName>
</DomainNameInformation>
<DomainNameInformation>
   <DomainName>autodiscover.example.net</DomainName>
</DomainNameInformation>

Additional Information

Windows 10 VPNv2 Configuration Service Provider (CSP) Reference

Windows 10 Always On VPN Protocol Recommendations for Windows Server Routing and Remote Access Services (RRAS)

Windows 10 Always On VPN Hands-On Training

Leave a comment

19 Comments

  1. Many thanks for the explantation. Do the NRPT Settings also work with device channel vpn?

    Reply
  2. I had a Problem with the applocker Policy on the win 10 Clients which cuased the nrpt Policy not do work. Now everything is ok. Many thanks

    Reply
  3. Sniper68

     /  May 7, 2018

    Hi, did you know if NRPT can resolve SRV Record ? I have some issue about that and I have no idea how to resolve that. I have tried to create NRPT Rule but it have no effect.

    Many thanks for your help

    Reply
    • To be clear, NRPT doesn’t “resolve” anything. It just directs name resolution queries to specific DNS servers based on the namespace. 🙂 That said, SRV records are fully subject to the NRPT and will be routed according to defined policy.

      Reply
      • Sniper68

         /  May 10, 2018

        I’m totally agree with you. I have a policy routing all traffic with a suffix domain *@contoso.com. When I will try to resolved a srv record like _ldap._tcp.contoso.com it failing.
        Of course I can resolve other request like A record without problem. I will use split brain DNS architecture.
        How can I troubleshoot this issue ?
        Thanks for your help.

      • Not sure if it is a typo or not, but you should not have “@” defined in the namespace. It should simply be “.contoso.com”. 🙂

  4. Tony

     /  May 8, 2018

    Hi Richard

    I’ve found that Chrome and Firefox don’t pickup sites in the NRPT table. I have used the webproxyservers setting for a website as it needs to be access internally due to ACL. This works on IE but not on Chrome or Firefox. We had the same issue with DirectAccess. Do you know of a way around it? As a lot of folks in our organisation prefer those browsers over IE.

    Thanks
    Tony

    Reply
  5. Tom

     /  May 10, 2018

    Hi Richard,

    I’ve followed your guidance above to exclude some A records that we don’t want to go down our VPN tunnel, however no matter what I tried without the element, the records still kept resolving to the internal IP addresses.

    I managed to resolve it in the end by leaving the element in the xml for every record we had and then pointing the records to public DNS, like so below where I use Google DNS:

    externalrecord.domain.com
    8.8.8.8,8.8.4.4

    Doing this for all of our exclusions worked perfectly!

    But I just wanted to check, should we have to do this? Or should it just work without defining an external DNS provider? Sounds like you had a different experience to us, so I wanted to be sure 🙂

    Many Thanks

    Reply
    • Interesting. Are you also using the device tunnel? I ran in to this scenario once and it turned out that name resolution queries were leaking back over the device tunnel. Other than that, you should not have to specify public DNS servers when you configure exclusions. They should simply bypass the VPN tunnel and use whatever DNS server is configured on the network adapter.

      Reply
  6. Stuart Banks

     /  May 17, 2018

    Hi Richard,
    We have configured the VPN Device Tunnel with NRPT for services we want to resolve externally. This works correctly however when we log back onto the domain, the device tunnel is down, the NRTP registy entries under: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Dnscache\Parameters\DnsPolicyConfig do not remove from the computer and means we are then not able to resolve these services as they are trying to use a public DNS set in the NRPT which is blocked by the firewall.

    Two questions here:
    1. Is the NRTP policies set in registry when the tunnel comes up meant to be removed when you connect back to the network?
    2. If not, why are they still applying? are we missing a setting?

    Any help would be great.

    Thanks

    Reply
    • I’ve never used the NRPT with the device tunnel myself, but in theory it shouldn’t apply until the tunnel interface is established. Sounds like that isn’t happening for you? Are you using TrustedNetworkDetection in your profileXML?

      Reply
      • Stuart Banks

         /  May 17, 2018

        Thanks for the reply.

        Sorry I not sure if I was clear. Our NRPT works correctly when the device tunnel comes up and preforms as expected. Our issue lies when we plug the machine back into the network (without reboot), the NRPT is still applying to the machine meaning we aren’t able to resolve any addresses in the NRPT with our internal DNS servers. Our current workaround is to manually delete the registry keys in “HKLM\SYSTEM\ControlSet001\Services\ Dnscache\Parameters\DnsPolicyConfig” using a powershell script or to reboot the machine when swapping from the VPN to the network.

        We are using TrustedNetworkDetection in the profileXML.

        We are also setting the following reg keys: MaxCacheTTL and MaxNegativeCacheTTL to zero.

        We aren’t sure if the NRPT should be removed when we connect back onto the network or if it should remain but de-activate/not apply when the machine is on the domain network. In our case neither is happening.

        Thanks,

      • Got it. I would expect the NRPT not to be enabled/enforced if the associated VPN tunnel interface is not active. However, it sounds like that isn’t happening in your case. No idea why it is behaving like that either. How critical is the NRPT in your case? I’m finding there are only a few limited uses cases for it. Given it often introduces odd issues like this, I typically try to avoid its use.

  1. Deploying Windows 10 Always On VPN with Microsoft Intune | Richard M. Hicks Consulting, Inc.

Leave a 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 )

w

Connecting to %s

%d bloggers like this: