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
bueschu
/ April 29, 2018Many thanks for the explantation. Do the NRPT Settings also work with device channel vpn?
Richard M. Hicks
/ May 3, 2018They should, yes. 🙂
Georg T.
/ July 27, 2020Device tunnel does not support using the Name Resolution Policy table (NRPT). Device tunnel does not support Force tunnel. https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config
Richard M. Hicks
/ July 28, 2020Very good, thanks for the tip! There’s been a lot of discussion around this inside at Microsoft, and it’s nice to see it formally documented now. 🙂
Schreibkomitee
/ May 4, 2021It seems like NPRT does work with device tunnel if you have device tunnel only. When you establish device tunnel after user tunnel, both NPRT entries are combined (and both are active). But if you establish device tunnel first and then user tunnel, then entries from device tunnel get removed (at least it seems like that for me).
But configuring same policy on both tunnels seems to make sense.
Richard M. Hicks
/ May 5, 2021That’s most likely what the NRPT isn’t supported on the device tunnel. 🙂
exonlineblog
/ September 14, 2021Hi Richard, I have configured NRPT on the User Tunnel in Intune. However, when I am connected with the User Tunnel on a client, the Get-DnsClientNrptPolicy cmdlet does not give any output and NRPT does not seem to be active. When I disconnect the User Tunnel, the Device Tunnel automatically connects and now the Get-DnsClientNrptPolicy cmdlet does show the correct NRPT configuration. I am stumped! Any insights would be most welcome. Thanks so much in advance!
Richard M. Hicks
/ September 14, 2021You are certain you configured the NRPT on the user tunnel and not the device tunnel profile then, right? 😉 Did this client have DirectAccess configured previously?
exonlineblog
/ September 15, 2021Thanks for the feedback! I am pretty sure (the device tunnel is created with a custom XML and the user tunnel is configured via the GUI in Intune – any other way to ascertain this?). On the client side, my understanding is that the User tunnel is the VPN that I can connect to manually via network icon and the device tunnel is the one that I can only connect to via rasdial. Another way I check this is via the PS command: Get-VPNConnection whereby the device tunnel only appears when I add the -AllUserConnection parameter. If I check the InnerXml of the Vpnconfigurationxml of the device tunnel on the client, I do see the node but I don’t see that on the user tunnel. Strangely though, I cannot find NRPT settings in the device tunnel settings in Intune (it’s also not supported if I read that correctly) so it seems as if Intune is applying the NRPT settings configured in the user tunnel only to the device tunnel but not to the user tunnel on the client device.
exonlineblog
/ September 16, 2021Thanks for the feedback! I am pretty sure it’s the user tunnel. The user tunnel is the one that I can configure through the GUI in Intune. The device tunnel is configured via the OMA-URI settings XML (where it also indicates true…
Richard M. Hicks
/ September 16, 2021FYI, it is possible to configure the Always On VPN device tunnel using the Intune UI. There are good reasons to do it using OMA-URI, though. 🙂
exonlineblog
/ September 17, 2021Yes, we did the device tunnel via OMA-URI, it also says “true” for the device tunnel XML node. Still, I am not getting the configured NRPT settings (for “.mydomain.com”) in the user tunnel for some reason. Now when I am connected to the user tunnel and I do “Get-DnsClientNrptPolicy” I get three entries: “wpad”, “_ldap” and “isatap” with my DC’s as NameServers. Do you know where those come from? Is that a default for a domain joined device or something? I don’t find a lot of relevant information about NRPT and AlwaysOnVPN. Maybe NRPT is not the route I should follow to solve my DNS issues. I have also worked with changing the metrics of my VPN adapter but these are often not persistent. Your blog/site seems to be the only descent resource on VPN & NRPT! Do you know any other “deep dive” resources that could help me solve this conundrum? Thanks so much again for your help!
Richard M. Hicks
/ September 17, 2021Correct. When you enable the NRPT for Always On VPN, several default entries are added. That tells me that the settings are coming down from Intune. Why your specific namespace rules aren’t coming down I have no idea.
FYI, I do try to avoid using the NRPT as much as possible. Sometimes there’s no other way, but most often it isn’t required. Some say you have to use it when you have split DNS enabled, but that’s not true either. You can always use DNS policies to workaround split DNS issues.
bueschu
/ May 3, 2018I 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
Sven Farrugia
/ October 28, 2020How did you solve this please, I am struggling to make it work and the only solution, for now, is to disable the app locker which is far from ideal
bueschu
/ October 28, 2020The workaround is little bit strange. I made an NRPT entry under “Name Resolution Policy” in the applocker Policy and applied this Policy to the win 10 Client. Afterwards I deleted this entry in the Policy and NRPT still works. Get-dnsclientnrptpolicy returns now the entries.
Sniper68
/ May 7, 2018Hi, 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
Richard M. Hicks
/ May 10, 2018To 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.
Sniper68
/ May 10, 2018I’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.
Richard M. Hicks
/ May 12, 2018Not sure if it is a typo or not, but you should not have “@” defined in the namespace. It should simply be “.contoso.com”. 🙂
Tony
/ May 8, 2018Hi 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
Richard M. Hicks
/ May 10, 2018No, unfortunately this is a known issue which makes the NRPT much less useful than it should be. :/
Tony
/ May 11, 2018Thanks Richard, I thought that was probably the case!
Tom
/ May 10, 2018Hi 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
Richard M. Hicks
/ May 10, 2018Interesting. 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.
Tom
/ May 13, 2018So currently we are just using the user profile tunnel. We may decide to implement the device tunnel alongside the user profile tunnel in the future. When you say network adapter are you referring to the VPN adapter? Or the Ethernet/Wireless adapter? I’ve been looking online and I’ve just found someone who had the same problem as me: https://social.technet.microsoft.com/Forums/windowsserver/en-US/a79b1acb-e1b3-4dac-99d6-1cd4ae36920f/nrpt-for-always-on-vpn Strange one!
Richard M. Hicks
/ May 16, 2018Physical adapter. Specifying a public DNS server instead of configuring a bypass (no DNS) might work too.
Stuart Banks
/ May 17, 2018Hi 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
Richard M. Hicks
/ May 17, 2018I’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?
Stuart Banks
/ May 17, 2018Thanks 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,
Richard M. Hicks
/ May 21, 2018Got 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.
Ronald Bevers
/ October 23, 2019Hello Stuart and Richard,
I know this is an old post but I still think the following would be applicable. When the VPN connection gets connected, it created the NRPT list and yes this is in the registy. But when the device goes to sleep, it doesn’t remove the NRPT list. In all other situations (shutdown/restart/disable Wifi/etc.) this works fine but when entering in sleep mode its not.
I’m currently in contact with Microsoft and this issue still exists. We are testing a patch at the moment which should fix the issue and if so they will probably only add this to a Windows 10 update in the beginning of next year. Yes this long and the reason for this is the upcoming Windows 10 build release 1909 which has a higher priority.
I hope this information helps.
Richard M. Hicks
/ October 24, 2019Thanks for the update!
Erik
/ May 31, 2018Hi, we are using AO-VPN with ForceTunnel option and would like to use an explicit proxy for internet traffic. Do you know if it’s possible to create a “.” -rule (catch-all) like in DA with forcetunnel and assign the proxy to? Trying to create config with can’t get it to work.
Richard M. Hicks
/ May 31, 2018To enable force tunneling you simply define the NativeProfile/RoutingPolicyType element as ForceTunnel. To configure a proxy server you would then define the Proxy element (Manual or AutoConfigUrl) as required. Reference – https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp.
Erik
/ June 1, 2018Thanks for your reply Richard! (and great Blog) I know how to enable FT and tried “Proxy”-tag from the CSP. But that feels quite limited. We need to configure exclusions and set the client to not use proxy for local resources. Was hoping to be able to configure this by the “DomainNameInformationList” -tag like you were able to with NRPT/DA and set explicit proxy on the “.”-rule. (And then let the NRPT take care of the exclusions)
What I’ve found so far is to use the PS-command Set-VpnConnectionProxy and manage this separately.
Cheers!
Erik
(The formatting in my last post caused some text to be removed when posting)
Richard M. Hicks
/ June 2, 2018I agree, setting the web proxy server manually can be challenging. You do have the option to use an autoconfiguration URL, however. That might be an option if your proxy supports it.
Bryan Hall
/ May 10, 2019I worked around the CSP proxy limitation by running a separate script using “Set-VpnConnectionProxy -ConnectionName [VPN profile name]-ProxyServer [proxyserver:port] -BypassProxyForLocal -ExceptionPrefix [comma separated prefixes]”.
One important thing I found out is that this command cannot be run in the same script as the VPN creation task, when deploying via SCCM. (It does work when running the script locally though).
The reason it turned out to be is that when installing the user tunnel with SCCM (as admin), it runs the entire script as SYSTEM. While the VPN profile is installed in the user context (using the user’s SID), the subsequent powershell Set-VPNConnectionProxy command will still run as SYSTEM, thus it cannot find the tunnel. We worked around this by running a second deployment under the user’s context.
Now, there might be a way to run the Set-VPNConnectionProxy in the user’s context using the -CIMSession switch, but I could not figure that part out.
Eric Yew
/ August 7, 2018Do you know if it is possible to route traffic in a split tunnel to an external site via the VPN tunnel if there is no corporate proxy server?
Richard M. Hicks
/ August 7, 2018Not easily. It might be possible if you do something using NAT, but it wouldn’t be recommended and it certainly could have unintended consequences. 🙂
Phil
/ January 24, 2019I found recently that if you have NRPT DomainNameInformation rules in both your device and user tunnels then they must match otherwise you get an NRPT corruption error in the EventLog (and also when running Get-DnsClientNRPTPolicy) and DNS registration fails
Richard M. Hicks
/ January 24, 2019Good to know. Thanks for the tip, Phil! 🙂
Bryan Hall
/ May 10, 2019I was excited to read this, as I’ve been having this issue, sadly ensuring that both device and user tunnels have the same DNI did not resolve the issue for me. It’s likely I have other contributing factors, but I have yet to find out why. I also have the issue where the network icon shows ‘no internet connection’ yet I can get to the Internet (via proxy). The real problem is that Office products seem to simply take as gospel that there is no internet connectivity and does not try to connect (e.g. Office app’s backstage Accounts section).
Richard M. Hicks
/ May 10, 2019Bryan – The NCSI showing “no Internet” is common in this scenario. It has to do with the way NCSI performs its check. You’re right though, some applications won’t work if the NCSI reports no Internet access, which can be terribly frustrating. I’d be curious to know if configuring NCSI to use global DNS would help? It’s enabled via the registry. Here’s the PowerShell to set it.
New-ItemProperty -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\” -Name UseGlobalDNS -PropertyType DWORD -Value 1 -Force
Curious to know if that helps!
Adam Millgate
/ March 7, 2019Hi Richard,
Great article! I’ve got an issue where if I reconnect to the corporate network without a restart, the NRPT entries are still enforced, even though we are using Trusted Network Detection. Do you know of a way to ensure that the NRPT is no longer applied following a successful reconnect to the corporate LAN?
Thanks!
–Adam
Richard M. Hicks
/ March 7, 2019This is a known issue and most certainly a bug. If you restart the client the NRPT will clear and everything works fine. Hoping Microsoft will address this soon. 🙂
Marlon
/ March 26, 2019We are experiencing the same issue recently, after reconnecting back to corporate network the NRPT still effective. Adam Millgate have you had any luck on resolving this?
Richard M. Hicks
/ March 26, 2019This is a known issue. Not sure if it has been fixed yet by Microsoft. Sounds like it hasn’t. :/
Adam Millgate
/ March 27, 2019Hi Marlon, Richard
Actually, yes. I opened a support call with Microsoft about this and we have resolved the issue, at least for our environment.
In our XML profile, we had defined out trusted network as follows:
true
true
example.net
and because we have an element of split DNS, the first entry in our NRPT was:
.example.net
,
According to Microsoft Support, this introduces a resolution loop into the VPN configuration that it is unable to break out of when you disconnect from the VPN, and so the client still thinks it’s connected and doesn’t unload the NRPT.
Removing this entry from our table resolved the issue and now when we disconnect from the VPN the NRPT rules are unloaded from the client.
In the event MS support weren’t able to help, I also managed to write a script in PowerShell that was triggered on Application Log event ID 20226 from the RasClient source that unloaded all the NRPT rules. It’s not very elegant, and wasn’t fully finished or tested before we resolved the issue the other way, but the crux of it is as follows:
$nrpt = Get-DnsClientNrptRule | Where-Object {$_.Name -like “VPN_CONNECTION_*”}
foreach ($n in $nrpt){
Remove-DnsClientNrptRule -Name $n.Name -PassThru -Force
}
Hope this helps you or someone else.
Cheers
–Adam
Adam Millgate
/ March 27, 2019Sorry, it looks like my tags above have not been rendered so I’ll repost the XML substituting squared brackets where appropriate:
Our Trusted Network Detection:
[AlwaysOn]true[/AlwaysOn]
[RememberCredentials]true[/RememberCredentials]
[TrustedNetworkDetection]example.net[/TrustedNetworkDetection]
The first part of our NRPT:
[DomainNameInformation]
[DomainName].example.net[/DomainName]
[DnsServers](primaryDNS),(secondaryDNS)[/DnsServers]
[/DomainNameInformation]
Hope this works 🙂
Thanks
–Adam
Marlon Rivera
/ May 7, 2019Thank you very much for the info.
sveken
/ May 29, 2019Sorry what part do we remove?
our XML setup looks like your second example already but we are having this issue, do we remove the trusted domain or something?
Richard M. Hicks
/ May 30, 2019If you want to avoid this issue you’ll need to remove the DomainNameInformation element from your ProfileXML.
Adam Millgate
/ January 30, 2020Good News! After working with them for several months to identify the issue, Microsoft have released patches for Windows 10 this month that include fixes for the NRPT rules not being removed on disconnect. I’ve only dome some superficial testing so far, but it looks promising!
The actual text from the updates reads:
Addresses an issue with the Always On Virtual Private Network (VPN) that fails to remove the Name Resolution Policy Table (NRPT) rules after you disconnect.
Richard M. Hicks
/ January 30, 2020Great to hear! 🙂
Ronald
/ February 2, 2020I can confirm this. I also had a case open with Microsoft and told me that a fix for Windows 10 builds 1909, 1903 and 1809 are now available. I didn’t did have any time to test this yet, but had been testing with a test (not public available) of the patch months ago which seems to work.
Damian Murray
/ June 25, 2020We are still seeing the issue where a client retains NRPT despite the tunnel dropping. This causes issues as we do not have an NRPT for the VPN endpoint address so the tunnel *cannot* reconnect (as the client tries to route using internal DNS servers it is no longer connected to). Interestingly the clients affected are part of an Microsoft Managed Desktop pilot and so are running the latest Windows build and are at the current patch level.
Should I put the VPN endpoint address in as an NRPT rule so that if the tunnel disconnects it can still route to the VPN address and connect? I am not sure if this will cause problems if/when clients are connected to the internal LAN as the address does not exist on internal DNS to prevent any confusion with the client trying to bring up the VPN while connected internally. Does that make sense?
Richard M. Hicks
/ June 29, 2020See my previous reply RE: putting the VPN server’s public FQDN in the NRPT as an exclusion. 🙂
Damian
/ June 26, 2020We are still seeing the issue where a client retains NRPT despite the tunnel dropping. This causes issues as we do not have an NRPT for the VPN endpoint address so the tunnel *cannot* reconnect (as the client tries to route using internal DNS servers it is no longer connected to). Interestingly the clients affected are part of an Microsoft Managed Desktop pilot and so are running the latest Windows build and are at the current patch level.
Should I put the VPN endpoint address in as an NRPT rule so that if the tunnel disconnects it can still route to the VPN address and connect? I am not sure if this will cause problems if/when clients are connected to the internal LAN as the address does not exist on internal DNS to prevent any confusion with the client trying to bring up the VPN while connected internally.
Does that make sense?
Richard M. Hicks
/ June 29, 2020That’s odd for sure. I know that Microsoft fixed this issue quite some time ago, but it’s always possible that it could crop up again. Adding the public FQDN to the NRPT as an exception sounds like a good idea, but in practice it doesn’t always work as expected. If you must use the NRPT (it’s typically best to avoid it if possible) then you’ll have to assign public DNS IP addresses to the VPN FQDN to ensure that it is actually resolved externally.
Udo Hentschel
/ March 12, 2019Hi Richard,
great articles – I love to read them.
I wonder if there is a way to use the Name resolution Policy GPO (2016) for VPN (similar to DA).
I see the problem updating the NRPT settings on clients – when deleting the config from the CSP and reconfiguring it (with SCCM), it may leave the remote client unconfigured.
Are there any recommendations for this scenario?
Thanks
Udo
Richard M. Hicks
/ March 12, 2019If you’re talking about configuring the NRPT using GPOs instead of using the DomainNameInformation element in ProfileXML, I guess that might work. However, there may be some unintended consequences we’re not thinking about. I would much prefer to configure the NRPT using ProfileXML as that will be much more supportable and, honestly, that’s the way it was designed to work. Doesn’t hurt to try it though. If you do, let me know how it worked for you. 🙂
Trond E. Gjelsvik-Bakke
/ April 11, 2019Trying to understand how this is all hanging together.
I am currently working to migrate DirectAccess to AlwaysOn.
We are going for the user tunnel for now.
What we want is to use internal DNS servers for query that belongs to our internal domain, and to use the internet connections DNS servers for all other.
Out AlwaysOn Profile include:
true
domain.local
domain.local
192.168.1.10
I suspect that there are some NRPT configuration left from DirectAccess, but can’t locate the settings….
Richard M. Hicks
/ April 11, 2019Your XML markup didn’t come through in the comment. WordPress removes the angle brackets unfortunately. :/ There’s a known issue where the registry key HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig exists but the DnsPolicyConfig key is empty that causes NRPT for Always On VPN to fail. If that registry key exists I’d suggest deleting it to see if that helps.
Trond E. Gjelsvik-Bakke
/ April 12, 2019Hi.
Looking into Registry, and the path that you refer to don’t exists.
Running the Get-DnsClientNrptPolicy -Effective shows some rules for _ldap, wpad and for .domain.local
Running nslookup, all DNS queryes are sent to the DNS Server specified at the VPN server and not towards the DNS Server specified in the ProfileXML.
Richard M. Hicks
/ April 12, 2019I’ve heard other reports of the NRPT being ignored as well. You might have to open a support case with Microsoft to learn more.
Florian
/ April 16, 2019Anyone also haveing issues with Win 1809? We successfully rolled out AlwaysON for 1709&1803. However on 1809 the NRPT rules are not applied from the Config XML. Has anyone an idea? get-dnsclientnrptpolicy doesn’t show any rules.
Florian
/ April 16, 2019Just tried 1903 (18362.30) there it works again without any issue
Richard M. Hicks
/ April 16, 2019Most interesting. Perhaps you’ve found a bug in 1809? Have you opened a support case with Microsoft to investigate?
Florian
/ April 16, 2019not yet just discovered it today, hoped that someone else did already run into this issue,
thanks
Richard M. Hicks
/ April 16, 2019No major issue to report with 1809 for me. I’m not using the NRPT though. Anyone else?
Dan
/ April 27, 2019Also having issues with the NRPT on Win 10 1809, specifically that the entries do not appear in the local NRPT table when the VPN is connected.
Went as far as trying to define public name servers for the names I want to prevent using the tunnel, using the DnsServers tag but made no difference.
Richard M. Hicks
/ April 27, 2019Unusual. There are some known issues with the NRPT, one of which being it is ignored when the following registry entry is present: HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig. However, when this happens you usually see the entries in the table, they are just ignored. Might be worth investigating anyway.
Dan
/ April 29, 2019Sure enough, that key was present on the device.
Once I removed it and reapplied the VPN profile, I could see my entries when running a Get-DnsClientNrptPolicy cmdlet, however, until I defined internet based DNS servers for the names I wished to exclude, they’d still resolve to their internal addresses. They were not excluded simply by omitting the DNSServers tag – whether this is by design or a bug for 1809 clients, I’m not sure.
From what I gather, the key is set by Direct Access’s GPO settings, for which we have an existing deployment – so makes sense for us to see it. As part of my Always On onboarding script, i’ve added the following to remove the keys :
Remove-Item -Path ‘HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig\*’ -Recurse
Richard M. Hicks
/ April 29, 2019Glad you were able to get this working, sort of. 😉 Now you’re running in to a known issue with name resolution for Always On VPN using the NRPT (defined by the DomainNameInformation element in ProfileXML). You’re right, simply creating a blank entry (namespace defined with no DNS server) no longer works as expected. This is because Microsoft fundamentally changed the name resolution process beginning with 1803 I believe. Essentially DNS queries are sent out on all adapters at the same time. The only workaround that I’m aware of is to specify public DNS servers in your exemption rules. This is less than ideal because you never know if those DNS servers will be reachable. If, for example, the network administrators have ACLs in place to restrict access to public DNS (which is recommended and common) the client may not have access to them. :/
Graham Bird
/ May 28, 2019Hello Richard,
Great articles as always, must say my experience of Always-On VPN to date leaves me feeling that its a step down from DirectAccess, however not much can be done about MS decisions 😉
Any how we have setup AO-VPN and need to route traffic for specific hosts that have the same DNS internal as External over the VPN connection.
Reading the article and other links online it should be just as easy as NRPT 😉 however its proving not to be, so a few questions if I may.
1. Does NRPT work with User VPN over EAP Auth?
2. Do you need [DomainNameInformation] [/DomainNameInformation] between every entry in your XML file, e.g.
[TrustedNetworkDetection]internal.domain.com[/TrustedNetworkDetection]
[DomainNameInformation]
[DomainName].Domain.com[/DomainName]
[DnsServers]192.168.1.10, 192.168.1.11
[/DomainNameInformation]
[DomainNameInformation]
[DomainName].Internal.domain.com[/DomainName]
[DnsServers]192.168.1.10, 192.168.1.11
[/DomainNameInformation]
[DomainNameInformation]
[DomainName].www.Domain.com[/DomainName]
[/DomainNameInformation]
3. If using [DnsSuffix]internal.domain.com[/DnsSuffix] in the XML file does this impact the ability to utilize the settings specified in [DomainNameInformation]
4. If clients migrated from DirectAccess configuration to AO-VPN and have nothing under the regkey – ‘HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient\” Is it safe to assume that the DA config has been removed and is not impacting anything?
5. If running the command Get-DnsClientNrptPolicy returns an error “Failed to retrieve NRPT policy” is that OK if we are just using User VPN?
Many thanks
Graham
Richard M. Hicks
/ May 30, 2019So yes, the NRPT does work with Always On VPN and EAP user authentication. However, the behavior I describe in this article (specifically creating exemptions) doesn’t always work. This is due to some changes Microsoft made to the way DNS works beginning with 1803 I think. That said, if you are using split DNS and you need to send some traffic directly to the Internet and not over the VPN, right now the only semi-reliable way to do that is to specify public DNS servers in the DnsServers element. Not ideal because you have no guarantee those DNS servers will be reaching as they could be blocked by a firewall.
Migrating clients from DirectAccess to Always On VPN is not typically problematic, but there are some cases where the NRPT group policy doesn’t completely removed and it breaks Always On VPN’s use of the NRPT. Only way to resolve that is to delete the registry key entirely.
If Get-DnsClientNrptPolicy returns an error, it would see that the NRPT is corrupt. I’d suggest deleting the NRPT registry key and restarting to see if that resolves the issue.
zoredache
/ June 4, 2020What I seem to have found today is that the exceptions not working is at least partly related to the `AutoTrigger` option under `DomainNameInformation`. If you have autotrigger true for a domain/suffix the nrpt rules are added before the tunnel is up, and you don’t seem to be able to make exceptions. But if you don’t have autotrigger, or it is set to false they are added after the tunnel is up, and the exceptions to work.
Haven’t found any docs to confirm this though, but it seemed to be how it was working as I was testing.
Richard M. Hicks
/ June 4, 2020Unusual, but glad it works!
sveken
/ May 29, 2019So i have the same issue with the NRPT rules set in always on VPN still being applied when moved back to the enterprise network,
However if they click on the VPN connection and hit disconnect then join the network the rule will be removed like it should,
If the user just hits disconnect from wifi, then joins our enterprise one it again will still remain active, its only when the manually close the VPN connection it works, likewise if the machine is brought in sleeping the NRPT table will still be active, however only the one rule we define in the VPN XML, the rest like isatap etc that show up on a hotspot disappear,
The main reason we are using this is we have a proxy set in GPO to allow internet access when on site, this is done via a auto URL like http://proxy/usernet.pac but when using a VPN/DA this can be resolved which means the users internet still goes via ours,
In DA this was an easy fix, we just added “proxy” to the DNS exclusion list so it would not resolve and the client would use local internet,
however for always on VPN this isn’t as simple, any other suggestions?
Richard M. Hicks
/ May 30, 2019You could try creating an entry in the DomainNameInformation element that forces “proxy” to be resolved by an external DNS. I’m sure there will be some unintended consequences for this though, so I’d test carefully. It may not work like you expect. :/
sveken
/ May 30, 2019That was my first go to, and unfortunately the issue we are having is if the staff member brings the laptop asleep onto the site, the NRPT table is still active and blocks the internet access as proxy is resolving to 1.1.1.1 still
We have removed the other domainnameinformation tag mentioned above but it still does this, the only way to fix it is if the user manually disconnects from the VPN (this unloads it correctly) or shuts down and brings in the laptop this way,
Interestingly if the user hits connect while onsite, it will of course error as it can’t connect to the VPN on site, but this clears the NRPT table aswell!
Users only need access to about 5 servers, do you think if i use traffic filters and remote addresses this might resolve our issue?
Richard M. Hicks
/ June 7, 2019Yes, the NRPT operation with Always On VPN is not entirely stable. 😉 It’s one of the reasons I advocate against its use unless absolutely necessary. Not sure how using traffic filters will get around your DNS configuration issues being addressed by NRPT though.
Fraser
/ July 31, 2019Hi Richard, Do you have any tips for troubleshooting the NRPT for Always ON, does the NRPT operate in the same way to Direct access?
Richard M. Hicks
/ August 1, 2019My best advice is to avoid using the NRPT whenever possible. 🙂 It’s important to remember that it is optional, and often isn’t required. If you must use it though, it does work exactly like it does with DirectAccess. You can view the NRPT using the Get-DnsClientNrptPolicy PowerShell command. Also, when testing name resolution always using the Resolve-DnsName PowerShell command. Nslookup can yield unexpected results.
Fraser Smith
/ August 4, 2019Thanks for that Richard,
Another question, What is the difference between the Get-DnsClientNrptPolicy command and the Get-DnsClientNrptRule command?
Is policy = configuration, and rules = applied / active, or is it related to policy being applied by group policy and rules being applied by mdm / manual entry?
Best
Richard M. Hicks
/ August 5, 2019Not quite. Get-DnsClientNrptGlobal is the command to view the global configuration rules, while Get-DnsClientNrptPolicy shows all of the rules the policy includes. Get-DnsClientNrptRule will provide information about an individual rule in the NRPT policy.
Fraser
/ August 5, 2019Hmm, we are not seeing that behavior for AlwaysOn, Get-DnsClientNrptPolicy = Empty, Get-DnsClientNrptRule = rules configured for NRPT via CSP.
Have you found that the NRPT policy acts differently depending on the source configuration location? we used the NRPT for Direct Access (Configured via Group Policy) and it worked as expected, when configuring an identical policy via CSP / Intune it appears that configured DNS Servers are being ignored and all requests are going to the servers configured on the local clients interface.
Richard M. Hicks
/ August 13, 2019That’s unusual. I’ve only ever configured it using CSP and ProfileXML. I can do some more testing to see if the behavior is still the same. I’ll let you know if I find anything unusual.
Fraser
/ August 22, 2019Looks like this usual behavior we are experiences is caused by App Locker Group Policies? The only way to get around it is to deploy our App Locker Policies via a Custom XML Policy.
Steve C
/ January 22, 2020If you’re using ProfileXML to set the NRPT rules, and Get-DnsClientNrptPolicy = empty, but Get-DnsClientNrptRule = shows NRPT rules configured via the XML you need to delete this *KEY* not a *VALUE* inside the key but the key itself:
HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig
Once I deleted the key Get-DnsClientNrptPolicy no longer returned empty but showed policy consisting of the rules. Note that the VPN connections must be connected when you run the powershell commands.
Richard M. Hicks
/ January 30, 2020Indeed, and this is one of the reasons it is recommended to avoid the use of the NRPT with Always On VPN. It adds complexity and can also complicate migration from DirectAccess. Sometimes it is unavoidable and you have to use it, but best not to use it if possible. 🙂
Rune Flo
/ May 6, 2020Hi Steve,
I have been struggling with NRPT not working for days. I also ignored Get-DnsClientNrptPolicy = empty (No Errors) thinking it was part of DA only. Reading your above post and cleaning those registry polices, made NRPT working as expected. Thanks a lot!
I also think NRPT is crucial in device SplitTunnel configuration, because of how DNSClient pick DNS server for resolution (interface with lowest (RouteMetric + InterfaceMetric)). In my testing (without NRPT working) resolver get different DNS result if PC is connected to ISP via Ethernet Cabel vs. Wi-Fi. for names defined both public and internal.
I’m testing Windows 10 Enterprise (1909 and 2004) with 2019 RRAS, all setup with dual-stack IPv4/IPv6.
User0123
/ February 12, 2020Hi Richard, Thank you for keeping this blog current. It’s proven to be an invaluable resource during our Always On Deployment (which is turning out to be a never-ending project). Sorry if I missed the memo, but can you elaborate more on the alternative options for avoiding the NRPT in a Split Tunnel environment? Also, do you know if and where the recommendation to avoid the NRPT is stated in Microsoft documentation? I don’t have prior experience with DirectAccess or MS RRAS servers. Thank again!
Richard M. Hicks
/ February 14, 2020To be clear, the recommendation to avoid the use of the NRPT with Always On VPN is based on my experience. It is not something that Microsoft has documented. Since VPN clients inherit the DNS server(s) configured on the VPN server, as long as those DNS servers can resolve Active Directory names then you typically don’t need the NRPT. When it becomes necessary is when, for whatever reason, you can’t configure Active Directory DNS servers on the VPN server.
Martin Hofsteter
/ April 7, 2020Hi Richard
I have the problem that when I use NRPT, an entry “wpad” is automatically created in the NRPT table. There are also automatic entries for isatap and _ldap.
We work with a split tunnel and don’t want wpad to be resolved over the VPN tunnel.
The proxy setting on the client is automatic. When “wpad” is resolved, I can’t access the internet with my browser. Internally in the LAN wpad is used.
If I create a NRPT exclusion for “wpad” in the XML, I get an error message when I call Get-DnsClientNrptPolicy, but interestingly enough I can access the internet with my browser. But all other NRPT entries do not work anymore.
Do you have an idea how I can prevent this.
By the way; we currently use 1809.
Thanks a lot
Richard M. Hicks
/ April 8, 2020The best way to avoid this is not to use the NRPT if possible. You would do this by removing the DomainNameInformation element from your ProfileXML. As long as your VPN servers are configured to use your internal Active Directory DNS servers you won’t need the NRPT anyway.
martinhofstetterbithawkch
/ April 14, 2020Hello Richard
Thank you very much for your feedback.
Unfortunately we cannot do without the NRPT.
For administrative purposes, the VPN server is a member of a perimeter domain. Therefore we cannot assign the DNS servers of the internal domain to the VPN server. We also need to make resources accessible through the VPN tunnel for which there are shared DNS entries. In this way we want to enable SSO or eliminate the need for two-factor authentication.
But I have found that this problem no longer exists with the 1909 build! For this reason we will probably update all devices.
Thanks again
Martin
Richard M. Hicks
/ April 14, 2020Understand completely. Sometimes using the NRPT is unavoidable. Glad it is working in 1909 for you though!
Marco
/ April 27, 2020Can I use NRPT rules on a force tunnel AOVPN only to route traffic from Microsoft to the Internet instead of the tunnel? Or is this only for Split tunneling VPN?
Richard M. Hicks
/ April 27, 2020No. Force tunneling and the NRPT are mutually exclusive. Your only option for excluding traffic when using force tunnel is to use exclusion routes. Details here: https://directaccess.richardhicks.com/2020/04/09/always-on-vpn-force-tunneling-with-office-365-exclusions/.
Also, best practice is not to use force tunneling to avoid issues such as this. Details here: https://directaccess.richardhicks.com/2020/04/14/always-on-vpn-split-vs-force-tunneling/.
Thomas Gusset
/ August 19, 2020Hi
we are testing Always on VPN in a force-tunnel configuration (config as in the MS deployment guide). DNS split is used by the customer.
Everything works fine, but DNS uses the DNS Server of the LAN interface even if the VPN tunnel is up. Therefore FQDNs that exists in internal and external zone are resolved with the external IP instead of the internal.
After a lot of research we found that interface metric is used to decide which DNS response will be used.
If we check the metrics of the interfaces we can see that as soon VPN is established, the metric of the VPN interface is the lowest (but only for IPv4). That we would expect. But DNS still use the external DNS response. When we changed the metric of the IPv6 LAN interface to a higher value than the one of the VPN DNS works like expected.
This looks really strange.
Richard M. Hicks
/ August 19, 2020Very interesting. I would not have expected that making the interface metric for IPv6 *higher* for the VPN interface would work. Just the opposite in fact. But hey…if it works!
Andrew
/ September 27, 2020Could you tell whether is a normal works AOVPN or not?
After configured User VPN internal resources became available via VPN. But I found a route “10.0.0.0 255.0.0.0”.
After disabled a class base route a route “10.0.0.0 255.0.0.0” disappeared, but resolving internal DNS stopped working.
Then was add the route to IP address of internal DNS. Resolving are working again, but internal resources doesn’t available.
Is this a correct statement?
NPTR can’t determine what to route to VPN and only needs name resolution. All VPN routing implement via IP addresses and subnets.
true
SplitTunnel
.domain.local
10.0.11.11
10.0.11.11
32
Richard M. Hicks
/ September 29, 2020NRPT only specified where DNS queries are directed. You must always have a route to the networks where the DNS servers reside. With that, make sure your clients are configured with routes that point any on-premises subnets to the VPN interface.
Nate
/ October 15, 2020Hi,
We have an interesting new problem. We have a situation where we need to use Azure App Service private endpoints (internal web apps) with split DNS. From the App Service perspective, DNS looks like this: https://docs.microsoft.com/en-us/azure/app-service/networking/private-endpoint#dns
For a handful of AOVPN machines, they don’t go over the tunnel for the privatelink address and continue the lookup externally. Seems like a CNAME-related NRPT bug because split DNS and NRPT rules work fine everywhere else, even on the affected machines, although it’s usually on a simple A record, not some long chain of CNAMEs.
I have a workaround, but curious if there’s a fix or if it’s even a known issue. Has anyone seen anything like this?
Richard M. Hicks
/ October 16, 2020I’ve not seen this specifically. Has your workaround been effective? FYI, I’ve used DNS policies to solve some interesting challenges related to name resolution in the past. I’ll post them in the future for sure.
Robin
/ October 27, 2020Great blog Richard!
Do you know if the NRPT table for a user tunnel only works if the tick box “Connect automatically” is enabled and the VPN is connected without the user manually doing it? I’ve been experiencing this during my latest deployment where Get-DnsClientNrptPolicy/Rule shows nothing if it’s manually connected, but the moment the tick box is enabled and it does connect automatically it shows NRPT rules.
Richard M. Hicks
/ October 27, 2020As the NRPT is part of the Always On VPN configuration I’d expect it to be enforced when the connection is active, even if it was established manually. It could be a bug or just unexpected behavior though.
Marc
/ November 5, 2020Hi Richard,
Is there a way to specify DNS servers on a user tunnel independent of the NRPT in the XML you’re aware of?
We push only routes to domain controllers, SCCM and RRAS/NPS down the Device Tunnel in order to limit what can be accessed without a user tunnel. As a result the NIC on the RRAS server must have public DNS servers to give to the client so machines can still access Exchange/SharePoint if they don’t have a user tunnel deployed (our original use case was simply to enable first logon remotely via a device tunnel).
Now I’m looking at implementing user tunnel this causes an issue because connections to internal resources aren’t going down the tunnel. We can manually set the DNS servers on the user tunnel via the IPV4 settings on the adaptor GUI and this gets us the behaviour we want, but I can’t track down a way to programmatically do this via the XML or PowerShell at point of tunnel creation.
Richard M. Hicks
/ November 6, 2020The VPN client will always assume the DNS server that is assigned to the VPN server. Best practice is to assign Active Directory DNS servers to the VPN server to ensure clients can resolve Active Directory hostnames. If that’s done, everything should work. If the VPN server can’t be configured to use Active Directory DNS servers for some reason (for example perimeter/DMZ deployments) then you’ll have to use the NRPT.
Martin Hofsteter
/ November 9, 2020Hi Richard
At one of our customers the VPN server is operated in a perimeter/DMZ domain. Therefore the VPN server has of course the corresponding perimeter DNS servers. We have configured NRPT and the VPN clients can easily access the resources in the LAN domain. Unfortunately, hey do not register their IP on the internal DNS servers of the LAN domain. However, these DNS entries are required for software deployment and remote management.
If we set the DNS servers in the LAN statically on the VPN nic of the VPN client, then the registration in DNS works without problems. It also works fine, if I temporarily set a DNS server of the LAN on the VPN server. Do you have an idea how we can give the VPN clients the correct DNS servers for the DNS registration?
Thanks a lot
Richard M. Hicks
/ November 9, 2020This is a common complaint. You’ll need to make sure an update is installed and that you enable the registry setting outlined in this post: https://directaccess.richardhicks.com/2019/08/05/always-on-vpn-dns-registration-update-available/.
Robin
/ February 3, 2021Ok so I’ve managed to get this working for the Device tunnel since I used the profileXML to deploy it. For the User Tunnel I decided to try the manual way by configuring it in the Intune dashboard.
And I configured my NRPT policy there aswell for .mydomain.com to use our internal DNS-servers. But it doesn’t work. If I have my client connected with both Device tunnel and User tunnel dns works since I have a NRPT config in the Device tunnel config. But if I disconnect the device tunnel and clear the dns cache it won’t resolve my domain using the internal DNS. And if I run the Get-DnsClientNrptGlobal command with only the user tunnel active there is no config there.
The LAN interface do have higher priority than the tunnels. If I give the user tunnel a better metric than the LAN it uses the internal DNS. But what I thought was nice was to have it work without having to do this.
Gonna try configuring the user tunnel using xml file tomorrow using your config.
Thanks for getting me this far
Richard M. Hicks
/ February 5, 2021Setting the interface metric for the user tunnel connection to something lower than the Ethernet connection is the best way to resolve this. I usually set it to “3” using the PowerShell script found here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.
Dimitri
/ February 18, 2021Hi,
I’m using a user tunnel (split tunnel) for my customer.
Because of an ACL, a specific internet url is only allowed when browsing via the customer proxy server.
I specified this in the xml as follows :
.partnersite.be
8.8.4.4
10.12.20.1:8080
true
So when going to this site, use the proxy
The problem is that it seems to work, but it’s very unstable..
Sometimes it’s reachable, sometimes not, and it even depends on which browser I use! (chrome/edge/internet explorer/firefox)
eg, at the moment it’s only working on iexplore.
When I monitor via Fiddler, it seems to go correctly via the proxy, since I don’t see it in Fiddler (443/80), and it’s going via the proxyport.
Is this another known bug I’m hitting here, and can it be fixed? 🙂
Win Client is 1909
I don’t change any settings, and always perform a reboot between tests.
Richard M. Hicks
/ February 24, 2021This is a known limitation of configuring proxy servers in NRPT. Modern browsers seem to ignore it. You could try creating a .PAC file to define the proxy settings locally. I’m not sure if that’s a good solution or not, but it might be worth testing.
robbambs
/ March 18, 2021Hi Richard, do you have any tips of how to get Skype to resolve Outside of a NetMotion VPN, wild NRPT even work in this instance since the VPN isn’t a native provider like DA / Always-On?
Teams A/V was straight forward enough, but Skype appears to be a totally different challenge.
Thanks
Richard M. Hicks
/ March 22, 2021You’ll have to upgrade to NetMotion Mobility v12.x for this to work. With v12 and later, name resolution follows the tunnel. If the traffic goes over the tunnel, names are resolved over the tunnel. If the traffic goes outside the tunnel, names are resolved outside the tunnel.
Jason Kirk
/ March 25, 2021Hello,
I am using an Always On VPN Device tunnel.
We have some need to use the split DNS.
Our configuration has our domain name and name servers.
We have an exception for our external VPN gateway address.
While connected internal name resolution works fine.
Active Directory services all fail.
While the VPN is connected the domain name doesn’t resolve to a domain controller.
The AD SRV records are available if queried directly.
Any idea why the domain name wouldn’t resolve? We only have the two rules when listing the rules table.
Richard M. Hicks
/ March 27, 2021The NRPT isn’t supported for use with the Always On VPN device tunnel. Details here: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config.
Darren
/ April 27, 2021Hi I was trying to go through this whole thread best I could rather large as been going on for years, we are just transitioning over to AOVPN – Currently our Devices on Direct Access use a Hybrid Agent for proxying the web traffic out through the provider but we did have the common issue of needing some URLS to go through our on Premises Proxy because of ACLs for our corporate public IP address. We have been running this to set the URLS we want to use on prem for direct access.
$namespace = “.example.com”
$dnsserver = “”
Add-DAClientDnsConfiguration -DnsSuffix $namespace -DnsIpAddress $dnsserver -PassThru
$gpo = (Get-RemoteAccess).ClientGpoName
$gpo = $gpo.Split(‘\’)[1]
$proxy = “our proxy server”
$rule = (Get-DnsClientNrptRule -GpoName $gpo | Where-Object Namespace -eq $namespace | Select-Object -ExpandProperty “Name”)
Set-DnsClientNrptRule -DAEnable $true -DAProxyServerName $proxy -DAProxyType “UseProxyName” -Name $rule -GpoName $gpo
Just wondering if I could get some advice on the best way to transition all the current ones we have over from Direct Access to AOVPN and how to update this list in the future if anymore come around we need to add?
Thank you in Advance
Darren
Richard M. Hicks
/ May 3, 2021That’s a tough one. Typically I recommend avoiding the use of NRPT for Always On VPN unless absolutely necessary. You can define proxy configuration using XML, but sadly, it only works with Internet Explorer. Modern browsers (Chrome, Firefox, and even New Edge) all ignore it. Another option is to use IP routing to force the traffic over the VPN tunnel. This only works if you know the IP addresses of the public resource. If they are using a CDN or lots of dynamic IP addresses it isn’t a good solution.
urs egli
/ May 3, 2021Another solution could be, to install a DNS Server on the VPN Server. There you can forward the specific request to external or internal dns, as you want. I know it is not a brilliant solution but it worked for me
sandeep misra
/ July 8, 2021Hi Richard we are having issues with DNS resolution when using AOVPN.
We are trying to use NPRT exclusion for VOIP service but rather than resolving to external IP’s the URL’s in the user profile are resolving to our internal DNS which indicates the NPRT rules aren’t working. We are using device and user tunnels from NPRT has only been setup in user tunnel.
Richard M. Hicks
/ July 8, 2021I’m not certain, but what might be happening is that the hostname is being resolved over the device tunnel. The problem is that the NRPT is not supported on the device tunnel. Instead of creating an exclusion, you might want to try specifying public DNS servers in the NRPT rule on the user tunnel. It’s not ideal, but it might work.
Richard M. Hicks
/ July 8, 2021Another option would be to use DNS policies on your internal DNS servers to return the public IP addresses for queries from VPN clients.
https://docs.microsoft.com/en-us/windows-server/networking/dns/deploy/dns-policies-overview
Sandeep Misra
/ July 9, 2021Thanks Richard, we specified public DNS servers in User tunnel profile and now those URL’s are resolving to public IP’s, however correct me if I am wrong for NPRT’s to work and be persistent after reboots we also need specify NPRT in GPO for rules to be persistent?
Haven’t tried the option with DNS but would this be split DNS where we could specify external and internal DNS for the application? Do you have an example i could refer to?
Thanks,
Sandeep.
Richard M. Hicks
/ July 12, 2021You would define the NRPT rules in Microsoft Endpoint Manager or in your custom XML, depending on how you are configuring your Always On VPN clients. Using DNS policies you could create different DNS records for the same hostname resolving to internal and external IP addresses, then use a policy to return the public IP when your VPN clients make a name resolution request, but return private IPs for all other requests.
https://docs.microsoft.com/en-us/windows-server/networking/dns/deploy/dns-policies-overview
sandeep misra
/ July 13, 2021Thanks for getting back to me. Some of the URL’s we are specifying in the User Profile tunnel are subdomains also configured in our internal DNS for internal users accessing the applications from inside the network.
It appears the internal DNS is overriding the NPRT specified in the User Profile tunnel. Not sure how we can over come this so we can get this traffic off the vpn tunnel
I did test specifying public dns servers in the xml and it did work but as you say its not ideal. what is the impact of using public dns in the xml? I am told these settings often play up and usually not persistent after reboots and need to be also enforced via Network GPO? I did try adding in a GPO but then we are unable to resolve to private IP from inside the network which is not what we want either.
appreciate any feedback on we can overcome.
I looked at the split dns link but wasnt sure if this would apply in this case
Richard M. Hicks
/ July 15, 2021I agree, specifying public DNS servers in the NRPT rules is not ideal at all. The risk is that these public DNS servers might not be accessible behind restrictive firewalls. Some network operators may choose to restrict access to public DNS, especially when using services like OpenDNS or Quad9. If you go this route, I would add several public DNS servers just to improve your chances.
redelf
/ August 17, 2021Is there a tool that IS supported for this when using Device Tunnel? I keep being told by Microsoft that NRPT isn’t supported in this scenario – although it does appear to work.
It’s not perfect though – our scenario is that we only want our internal domain DNS lookups going over the VPN to our internal DNS servers, all other DNS lookups should be done by the local adapter DNS configured servers, whatever they may be. We have got an NRPT configuration that directs our internal domain traffic to the internal servers over the VPN but for all other traffic, we have to specify the public DNS servers we use (we have not configured this in the PolicyXML but using group policy at this moment – but if NRPT isn’t supported then I don’t want to waste time trying to sort it in the PolicyXML)
We have got the device tunnel configured as split tunnel with trusted network but can see that without the NRPT settings, the DNS requests get sent to ALL DNS servers, which is causing us issues on our internal DNS servers – too much traffic. Are we missing something simple in our config?
Thanks
Richard M. Hicks
/ August 24, 2021Unfortunately, no. Indeed, Microsoft does state that using the NRPT is not supported on the device tunnel, even though it appears to work. They must have some reason for this, however. I expect there are some unintended consequences we aren’t aware of or haven’t encountered yet.
Nate
/ October 21, 2021Hi,
Just wanted to share an issue we’re having: NRPT had been working great until we got into Azure private endpoints. I created NRPT entries for .privatelink..windows.net to run those lookups internally. This works for 99% of our users but some were still resolving the external IP and we’ve been hacking hosts files.
I finally realized that those users were connected to Ethernet with a lower metric than the VPN adapter. When something like mydb.database.windows.net resolves on the Ethernet interface to mydb.privatelink.database.windows.net (that zone does exist externally with the public IP), NRPT doesn’t kick in to route that lookup internally. I feel like that’s a bug.
Setting the VPN to a lower metric than Ethernet works-around the issue. WiFi isn’t an issue since it typically has a higher metric than the VPN.
-Nate
Richard M. Hicks
/ October 25, 2021The VPN interface metric setting often causes problems when devices also have a wired Ethernet connection. I’m hoping that one day Microsoft exposes this setting in XML or in Intune so we can easily make this change without having to resort to editing the rasphone.pbk file. 🙂
RF
/ January 14, 2022Any guidance on setting the local reverse DNS? Can we just extend the XML with .10.in-addr.arpa for example to also resolve PTRs in the 10.0.0.0/8 range?
Richard M. Hicks
/ January 14, 2022I’ve never had to do that myself, but if you have a requirement for clients to perform reverse lookups on-premises you can always add the .10.in-addr.arpa namespace to the NRPT.
Sean Waterson
/ June 7, 2022Hi Richard,
I purchased your book for DA years ago and now Always ON VPN to bring our DA environment from almost 10 years up to date. I am having issues with certain elements of the XML file not implementing when run. ,,NRPT (i.e. ) to be exact. If I correct the first two using PS cmds I connect and route properly but still have a split DNS issue to resolve. Also we do have Intune where I have tested pushing configs from and yes everything works perfect but of course we are not completely ready to transition to Intune for our Windows device yet. We are running the 21HI and 21H2 enterprise versions. I am using your templates etc.. Any suggestions?
Richard M. Hicks
/ June 9, 2022I would avoid using the NRPT for DirectAccess if you can, especially if you are trying to migrate from DirectAccess to Always On VPN. When you use the NRPT with Always On VPN and apply those settings to a client configure with DirectAccess, there will be conflicts because you essentially have two NRPTs.