All posts tagged name resolution policy table

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

143 Comments

by Richard M. Hicks on April 23, 2018 • Permalink

Posted in Always On VPN, AOVPN, DNS, enterprise mobility, name resolution policy table, NRPT, Remote Access, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016

Tagged Always On VPN, CSP, DNS, Microsoft, Mobility, name resolution policy table, NRPT, Remote Access, VPN, Windows, Windows 10, XML

Posted by Richard M. Hicks on April 23, 2018

https://directaccess.richardhicks.com/2018/04/23/always-on-vpn-and-the-name-resolution-policy-table-nrpt/

DirectAccess NRPT Configuration with Split DNS

DirectAccess NRPT Configuration with Split DNS The Name Resolution Policy Table (NRPT) in Windows provides policy-based name resolution request routing for DNS queries. DirectAccess uses the NRPT to ensure that only requests for resources in the internal namespace, as defined by the DirectAccess administrator, are sent over the DirectAccess connection. DNS queries for all other namespaces are sent to the DNS servers defined on the client’s network interface.

Note: This behavior changes when force tunneling is enabled. In this case, all DNS queries are sent over the DirectAccess connection with the exception of the NLS and the DirectAccess server’s public hostname(s). If force tunneling is enabled, the configuration guidance described below is not required.

Split DNS

NRPT configuration is straightforward when the internal and external namespaces are unique. However, when split DNS is used, meaning when the internal and external namespaces are the same, DirectAccess configuration is more challenging. Typically, there may be many resources that should not go over the DirectAccess connection, such as public-facing web servers, email and unified communications servers, federation servers, etc. Without additional configuration, requests for all of these services would go over the DirectAccess connection. That may or may not be desirable, depending on the requirements of the implementation.

DirectAccess Server

One crucial public resource is the DirectAccess server itself. When using split DNS, the DirectAccess implementation’s public hostname will, by default, be included in the internal namespace. In this scenario, the DirectAccess client will fail to establish a connection to the DirectAccess server.

Troubleshooting

When troubleshooting failed connectivity, the output of ipconfig will show the IP-HTTPS tunnel interface media state as “Media disconnected”.

The output of Get-NetIPHttpsState will also return an error code 0x2AF9 with an interface status “Failed to connect to the IPHTTPS server; waiting to reconnect”.

To further troubleshoot this issue, examine the output of Get-NetIPHttpsConfiguration. Test name resolution of the FQDN listed in the ServerURL field. If the issue is related to NRPT configuration, the client will fail to resolve this name to an IP address. Testing from a non-DirectAccess client should resolve correctly, however.

NRPT Configuration

If split DNS is employed, it is necessary to include the DirectAccess server’s public hostname in the NRPT as an exemption. This will cause the DNS query for the public hostname to use public DNS servers, allowing the DirectAccess client to establish a connection successfully.

To resolve this issue, open the Remote Access Management console on the DirectAccess server, highlight DirectAccess and VPN under Configuration, and then click Edit on Step 3. Select DNS, and then double-click on an empty row in the table.

Enter the public hostname for the DirectAccess deployment in the DNS suffix field (the public hostname can be found by clicking Edit on Step 2). Do NOT specify a DNS server. Click Apply, click Next twice, and then click Finish.

Note: For multisite deployments, be sure to include the public hostname for each entry point in the enterprise. Also, if multisite is configured to use GSLB, include the GSLB hostname as well.

PowerShell

Alternatively, you can run the following PowerShell commands to automatically configure the NRPT for split DNS. For multisite deployments, be sure to run these commands on at least one DirectAccess server in each site.

$hostname = Get-RemoteAccess | Select-Object -ExpandProperty ConnectToAddress
Add-DAClientDnsConfiguration -DnsSuffix $hostname -PassThru

If multisite is configured to use GSLB, run the following PowerShell commands on one DirectAccess server in the enterprise.

$gslbfqdn = Get-DAMultiSite | Select-Object -ExpandProperty GslbFqdn
Add-DAClientDnsConfiguration -DnsSuffix $gslbfqdn -PassThru

Additional Information

Troubleshooting DirectAccess IP-HTTPS Error 0x2af9

DirectAccess DNS Not Working Properly

DirectAccess DNS Records Explained

Troubleshooting Name Resolution Issue on DirectAccess Clients

16 Comments

by Richard M. Hicks on December 26, 2017 • Permalink

Posted in DirectAccess, DNS, IP-HTTPS, IPv6, IPv6 Transition, multisite, name resolution policy table, NRPT, PowerShell, Remote Access, transition technology, troubleshooting, Windows 10, Windows Server 2012 R2, Windows Server 2016

Tagged 0x2af9, DirectAccess, DNS, force tunnel, force tunneling, IP-HTTPS, IPv6, IPv6 transition technology, name resolution, name resolution policy table, namespace, NRPT, PowerShell, Remote Access, split DNS, troubleshooting

Posted by Richard M. Hicks on December 26, 2017

https://directaccess.richardhicks.com/2017/12/26/directaccess-nrpt-configuration-with-split-dns/

Top 5 DirectAccess Troubleshooting PowerShell Commands

Top 5 DirectAccess Troubleshooting PowerShell Commands Native PowerShell commands in Windows 10 make DirectAccess troubleshooting much easier than older operating systems like Windows 7. For example, with one PowerShell command an administrator can quickly determine if a DirectAccess client has received the DirectAccess client settings policy. In addition, PowerShell can be used to view the status of the connection and retrieve additional information or error codes that can be helpful for determining the cause of a failed connection. Further, PowerShell can also be used to review configuration details and perform other troubleshooting and connectivity validation tasks.

Here are my top 5 PowerShell commands for troubleshooting DirectAccess on Windows 10.

1. Get-DAClientExperienceConfiguration

Ensuring that the DirectAccess Client Settings group policy has been applied to the client is one of the first steps in troubleshooting failed DirectAccess connections. While it is possible to use gpresult to do this, using the Get-DAClientExperienceConfiguration PowerShell command is much simpler. If DirectAccess client settings have been applied, the output of the command will include information such as the IPsec tunnel endpoint IPv6 addresses and the Network Connectivity Assistant (NCA) corporate resource URL. If DirectAccess client settings have not been applied, this information will be missing.

Figure 1. DirectAccess Client Settings group policy successfully applied.

Figure 2. DirectAccess Client Settings group policy not applied.

2. Get-NetIPHttpsState

Performance improvements first introduced in Windows 8 have made IP-HTTPS the IPv6 transition technology of choice when it comes to supporting DirectAccess client connectivity. Also, if the DirectAccess server is located behind an edge device performing Network Address Translation (NAT), IP-HTTPS is the only supported transition technology. Using the Get-NetIPHttpsState PowerShell command, the DirectAccess administrator can quickly determine if the IP-HTTPS connection was successful. If it was not, the command will return an error code and interface status that will indicate why the IP-HTTPS connection was unsuccessful.

Figure 3. Get-NetIPHttpsState

3. Get-NetIPHttpsConfiguration

When troubleshooting IP-HTTPS connection failures, it is necessary to obtain additional information to continue the troubleshooting process. Using the Get-NetIPHttpsConfiguration PowerShell command, the DirectAccess administrator can obtain the public hostname for the DirectAccess server and ensure that the name resolves to the correct IP address in DNS and that it is reachable on TCP port 443.

Figure 4. Get-NetIPHttpsConfiguration

4. Resolve-DnsName

Using the Resolve-DnsName PowerShell command is crucial when performing any name resolution tasks on the DirectAccess client. This is because Resolve-DnsName is aware of the Name Resolution Policy Table (NRPT) and will direct name resolution requests accordingly. Tools like nslookup are DNS server testing tools and are unaware of the NRPT. Typically they do not yield expected results when testing name resolution on a DirectAccess client.

Figure 5. Name resolution results from Resolve-DnsName and nslookup.

5. Get-DnsClientNrptPolicy

Often the cause of DirectAccess client connectivity issues is a misconfigured NRPT. Using the Get-DnsClientNrptPolicy PowerShell command the DirectAccess administrator can validate that name resolution requests for host names in any internal namespaces are being sent to the DirectAccess DNS64 IPv6 address.