Name resolution is one of the most critical aspects for Always
On VPN and arguably any Windows‑based system,
but name resolution is obviously very critical to Always On
VPN because if we can't resolve those names,
we're not going to be able to access those resources.
So it's vital that Always On VPN clients be configured with the correct DNS
servers and those DNS servers be reachable. Now, by default,
Windows Always On VPN clients are assigned the DNS server
that is assigned to the VPN server.
So whatever DNS servers are configured on the VPN server,
if you have a single network interface, it's the only interface,
but if it's a multi‑homed server, it would be on the internal interface.
Whatever servers are defined there are automatically given to the VPN client.
So it's not assigned with DHCP or anything like that.
It's just a function of the VPN server giving that to the VPN
client. And this is the recommended configuration, and
honestly, it works well in most scenarios.
However,
there are some times when it doesn't work correctly or as expected. For example,
if the VPN server itself has DNS servers assigned that are not using DNS
servers that are capable of resolving internal or,
you know, Active Directory hostnames, then obviously that's not going to work.
The most common scenarios that you'll run into for this will be if
the VPN server is joined to a perimeter or DMZ network and it's not
joined to a domain. In that scenario,
the VPN server may very well be using public DNS servers or maybe DNS
servers that are in the perimeter or DMZ network, but still are not capable
of resolving internal hostnames in the Active Directory namespace that
those clients are going to need to get to.
So in that scenario, we need something to address that.
That's where the Name Resolution Policy Table, or NRPT, comes into play.
The NRPT provides policy‑based name resolution request
routing for DNS requests on an endpoint.
DirectAccess administrators will be intimately familiar with the NRPT
because it was a required component of DirectAccess.
DirectAccess didn't function without it.
However, in Always On VPN it is optional.
When the NRPT is enabled,
we can route name resolution requests for specific domain
name spaces or even individual hosts within a domain to
specific DNS servers. For example,
we could route the entire corp.example.net namespace to our
internal Active Directory DNS servers.
Or alternatively, we could forward the name resolution request
for a specific host, like app1.corp.example.net, and we would
route that to a specific DNS server.
You do have the option of specifying a proxy server
to go along with the NRPT entry.
And while this might sound interesting,
I will caution you that it is quite limited in actual usefulness
because it only works with Internet Explorer.
So unless you're still using IE for everything, this is probably
not going to be an important feature for you.
You can define a proxy server for the NRPT entry,
but all modern web browsers will simply ignore it,
and that includes Microsoft Edge, the new Chromium edge browser from Microsoft.
So it only works with Internet Explorer,
so probably going to be of limited value there.
And finally, one critical point about the NRPT.
The Name Resolution Policy Table is not supported
for use with the device tunnel.
This is only supported to use on the user tunnel.
So, in this scenario,
if you need to resolve hostnames over the device tunnel and the VPN server
is not configured with DNS servers capable of resolving internal hostnames,
using the NRPT is unfortunately not an option.
You'll have to assign DNS servers on the VPN server that are capable of resolving whatever hostnames you need your endpoints to resolve.