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

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

    • Ronald Bevers

       /  October 23, 2019

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

      Reply
  7. Erik

     /  May 31, 2018

    Hi, 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.

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

      Reply
      • Erik

         /  June 1, 2018

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

      • I 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, 2019

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

  8. Eric Yew

     /  August 7, 2018

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

    Reply
    • Not easily. It might be possible if you do something using NAT, but it wouldn’t be recommended and it certainly could have unintended consequences. 🙂

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

    Reply
    • Good to know. Thanks for the tip, Phil! 🙂

      Reply
    • Bryan Hall

       /  May 10, 2019

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

      Reply
      • Bryan – 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!

  10. Adam Millgate

     /  March 7, 2019

    Hi 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

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

      Reply
    • Marlon

       /  March 26, 2019

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

      Reply
      • This is a known issue. Not sure if it has been fixed yet by Microsoft. Sounds like it hasn’t. :/

      • Adam Millgate

         /  March 27, 2019

        Hi 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, 2019

        Sorry, 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, 2019

        Thank you very much for the info.

      • sveken

         /  May 29, 2019

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

      • If you want to avoid this issue you’ll need to remove the DomainNameInformation element from your ProfileXML.

  11. Udo Hentschel

     /  March 12, 2019

    Hi 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

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

      Reply
  12. Trond E. Gjelsvik-Bakke

     /  April 11, 2019

    Trying 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….

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

      Reply
      • Trond E. Gjelsvik-Bakke

         /  April 12, 2019

        Hi.

        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.

      • I’ve heard other reports of the NRPT being ignored as well. You might have to open a support case with Microsoft to learn more.

  13. Florian

     /  April 16, 2019

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

    Reply
    • Florian

       /  April 16, 2019

      Just tried 1903 (18362.30) there it works again without any issue

      Reply
      • Most interesting. Perhaps you’ve found a bug in 1809? Have you opened a support case with Microsoft to investigate?

      • Florian

         /  April 16, 2019

        not yet just discovered it today, hoped that someone else did already run into this issue,

        thanks

    • No major issue to report with 1809 for me. I’m not using the NRPT though. Anyone else?

      Reply
  14. Dan

     /  April 27, 2019

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

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

      Reply
      • Dan

         /  April 29, 2019

        Sure 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

      • Glad 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. :/

  15. Graham Bird

     /  May 28, 2019

    Hello 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

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

      Reply
  16. sveken

     /  May 29, 2019

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

    Reply
    • You 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. :/

      Reply
      • sveken

         /  May 30, 2019

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

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

  17. Fraser

     /  July 31, 2019

    Hi Richard, Do you have any tips for troubleshooting the NRPT for Always ON, does the NRPT operate in the same way to Direct access?

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

      Reply
      • Fraser Smith

         /  August 4, 2019

        Thanks 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

      • Not 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, 2019

        Hmm, 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.

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

  18. Looks 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.

    Reply
  1. Deploying Windows 10 Always On VPN with Microsoft Intune | Richard M. Hicks Consulting, Inc.
  2. Always On VPN Client DNS Server Configuration | Richard M. Hicks Consulting, Inc.
  3. #StackBounty: #vpn #windows-10 #internal-dns #split-dns #split-tunnel Windows 10 Always On VPN, Split DNS, NRPT, and how to configure w… – TechUtils.in

Leave a Reply to Graham Bird 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: