Always On VPN and Split DNS

Cloudflare Public DNS Resolver Now Available

Split DNS, sometimes called ‘split brain’ DNS, is when an organization uses the same DNS namespace internally and externally. For example, the internal Active Directory domain name is example.com, so internal resources are accessed using a fully qualified domain name (FQDN) like dc1.example.com. Additionally, external properties such as mail and web services use the same namespace so that a public web server might have a name like www.example.com. Internal resources will resolve to internal, private IP addresses, whereas public services resolve to external, public IP addresses.

Complications

Things get complicated when the same resource (FQDN) is available internally and externally, especially for Always On VPN clients. For example, accessing app.example.com on the internal network resolves to a private address, but accessing the same resource on the Internet resolves to a public IP address. Often there are different authentication requirements for internal and external resources, which can yield unexpected results.

Name Resolution

Always On VPN administrators might prefer app.example.com to be accessed via the Internet when connected with Always On VPN. However, VPN clients will attempt to connect via the internal network using their default configuration. Solving this challenge requires internal DNS server changes.

NRPT?

It might be tempting for administrators to use the Name Resolution Policy Table (NRPT) to solve name resolution issues for Always On VPN. However, the NRPT has some limitations and may not always produce the desired results. For example, the NRPT only directs DNS queries. It does not define which resource records are returned by DNS. Also, some applications ignore the NRPT, which limits its usefulness. A better solution is to use DNS Policies in Windows Server.

DNS Policies

Microsoft introduced DNS policies with Windows Server 2016. DNS policies are a powerful tool administrators can use to fine-tune name resolution based on many factors. In the case of split DNS, administrators can configure internal DNS to return an IP address for a resource based on the source IP address of the name resolution query. VPN clients receive one IP address for a given DNS query, while all other clients receive a different IP address. DNS policies ensure that remote clients connected to the VPN will receive the proper IP address for the resource requested, as defined by the administrator.

Caveats

DNS policies are powerful and flexible, but there are some potential drawbacks. All enterprise DNS servers used by Always On VPN clients must be running Windows Server 2016 or later. Also, administrators must use PowerShell to configure DNS policies exclusively. There is no GUI interface to configure DNS policies. DNS policies do not appear in the DNS management interface, which could confuse an administrator unaware that DNS policies are in place. In addition, DNS client subnets and query resolution policies do not replicate across DNS servers. Administrators must manually configure these on each DNS server used by Always On VPN clients. However, zone scopes and resource records in those scopes do replicate automatically.

Scenario

For demonstration purposes, let’s assume that an Always On VPN client needs to access foo.example.com. It resolves to a private IP address on the internal network and a public IP address on the Internet. By default, foo.example.com will resolve to the internal private IP address of the server when connected with Always On VPN. However, the desire is to have foo.example.com resolve to the public IP address when connected with Always On VPN. To accomplish this, we’ll create a DNS policy to ensure that connected Always On VPN clients can resolve foo.example.com to the public IP address when resolving this name over the VPN tunnel.

DNS Policy Configuration

Open an elevated PowerShell command on a DNS server and perform the following steps to create a DNS policy for VPN clients.

Client Subnet

Run the Add-DnsServerClientSubnet PowerShell command to create a client subnet in DNS that includes all IP networks assigned to VPN clients. Summarize IP prefixes if there are multiple VPN servers in the organization.

Add-DnsServerClientSubnet -Name VPN -IPv4Subnet ‘172.16.100.0/22’ -IPv6Subnet ‘2001:db8:fcd2:1000::/60’

If summarizing IP prefixes for multiple servers isn’t possible, multiple subnets can be added to a DNS client subnet using the following command.

Add-DnsServerClientSubnet -Name VPN -IPv4Subnet @(‘172.16.100.0/24’, ‘172.16.101.0/24’, ‘172.16.102.0/24’, ‘172.16.103.0/24’) -IPv6Subnet @(‘2001:db8:fcd2:1001::/64’, ‘2001:db8:fcd2:1002::/64’, ‘2001:db8:fcd2:1003::/64’)

To make changes to an existing DNS client subnet, use the Set-DnsServerClientSubnet PowerShell command.

Note: Client Subnets do not replicate across domain controllers. Run the command above on all DNS servers or each DNS server used by Always On VPN clients.

Zone Scope

Create a Zone Scope that includes the DNS records to be returned to VPN clients. The default zone scope is the DNS zone itself. Configure an additional zone scope for the DNS zone by using the Add-DnsServerZoneScope PowerShell command.

Add-DnsServerZoneScope -ZoneName example.com -Name VPN

Resource Records

Next, add DNS records to the new zone scope using the Add-DnsServerResourceRecord PowerShell command.

Add-DnsServerResourceRecord -ZoneName example.com -A -Name foo -IPv4Address 203.0.113.12 -ZoneScope VPN

Add-DnsServerResourceRecord -ZoneName example.com -AAAA -Name foo -IPv6Address 2001:db8:21::12 -ZoneScope VPN

DNS Policy

Finally, create a DNS query resolution policy that ties everything together. Run the Add-DnsServerQueryResolutionPolicy command to create the DNS query resolution policy. Once configured, when the DNS server receives a DNS query, the policy will recognize that the query originates from a VPN client subnet and will return the resource record from the VPN zone scope with the public IP address defined previously.

Add-DnsServerQueryResolutionPolicy -Name VPN -Action ALLOW -ClientSubnet ‘EQ,VPN’ -FQDN ‘EQ,foo.example.com’ -ZoneScope ‘VPN,1’ -ZoneName example.com

Note: DNS query resolution policies do not replicate across domain controllers. Run the command above on all DNS servers or each DNS server used by Always On VPN clients.

Results

Once complete, the hostname ‘foo’ in our example above resolves to different IP addresses based on the client’s IP address.

DNS query for ‘foo’ from internal client.

DNS query for ‘foo’ from VPN client.

Summary

There are many scenarios where Windows Server DNS policies can be used to fine-tune name resolution for Always On VPN clients. Hopefully, this example gives you an idea of how DNS policies work, and you can use them to solve your unique name resolution challenges with Always On VPN.

Additional Information

Windows Server DNS Policies Overview

Always On VPN Short Name Access Failure

Always On VPN Client DNS Server Configuration

Always On VPN Proxy Server Configuration

Always On VPN Proxy Server Configuration

Web proxy servers are not as common today as they once were, but a few organizations still leverage them to provide secure Internet access for their employees. Commonly they are used to inspect and control Internet traffic and to enforce acceptable use policies. Some organizations may wish to extend this protection to Always On VPN clients in the field by enabling force tunneling. Administrators can define a web proxy server for Always On VPN connections globally for web traffic or individual websites or domains.

VPN Proxy

A VPN web proxy server can be defined when the Always On VPN user tunnel connection uses force tunneling. Although you can still configure a VPN web proxy server with split tunneling enabled, it will not work. It is only functional when force tunneling is in use.

Administrators can configure a VPN web proxy server using the Microsoft Endpoint Manager UI or custom XML deployed with Endpoint Manager or PowerShell. Administrators can define a VPN web proxy server explicitly, or a proxy automatic configuration (PAC) file can be specified.

Note: VPN proxy server settings only work when force tunneling is enabled. Force tunneling is an unsupported configuration for the device tunnel, making the global proxy server setting for the device tunnel unsupported.

Proxy Autoconfiguration

Perform the following steps to configure a VPN web proxy server with a PAC file in Endpoint Manager.

  1. Expand the Proxy section in the Configuration settings of the Always On VPN configuration profile.
  2. Enter the URL for the PAC file in the Automatic configuration script field. Be sure to include the port number in the URL when using a non-standard port.
  3. Leave the Address and Port number fields blank.
  4. Choose Enable or Disable from the Bypass proxy for local addresses drop-down list.

To configure a VPN web proxy server with a PAC file using custom XML, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.

Explicit Proxy

Perform the following steps to configure an explicit VPN web proxy server in Endpoint Manager.

  1. Enter the IP address, hostname, or fully qualified domain name (recommended) in the Address field.
  2. Enter the port number in the Port number field.
  3. Choose Enable or Disable from the Bypass proxy for local addresses drop-down list.

To configure an explicit VPN web proxy server using custom XML, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.

Namespace Proxy

Administrators can also define VPN web proxy servers on a per-namespace or per-hostname basis. Namespace VPN proxy servers can be helpful for scenarios where routing public websites over the Always On VPN connection is required. Most commonly, this is necessary because the public website restricts access to the IP address of the on-premises Internet gateway.

A namespace VPN proxy server is implemented using a Name Resolution Policy Table (NRPT) rule. At the time of this writing, a bug in Microsoft Endpoint Manager prevents administrators from deploying this option using the UI.

As you can see here, administrators can specify a proxy server as part of an NRPT rule in the Endpoint Manager UI. Notice this section of the UI validates the proxy FQDN correctly.

Always On VPN Proxy Server Configuration

However, when you try to save the configuration profile, Endpoint Manager returns the following error.

“Unable to save due to invalid data. Update your data then try again: ProxyServerUri must be a valid URL or be empty.”

Interestingly, when entering a URL such as http://proxy.lab.richardhicks.net:8080/ in the Proxy field, the Endpoint Manager UI accepts it and successfully validates. But according to the VPNv2 Configuration Service Provider (CSP) reference, the value must be entered as an IP address. A hostname or FQDN also works based on my testing. Entering a URL as shown in the example above will not work at all.

With that, the only way to implement a namespace VPN web proxy server is to use custom XML. To do this, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.

Include the leading “.” to specify the entire domain, as shown above. Omit the leading “.” to specify an individual host (for example, app.richardhicks.com). Repeat this section for each additional host or domain, as required.

Caveat

Unfortunately, the Microsoft Internet Explorer web browser is the only browser that functions with the namespace VPN web proxy server. All modern web browsers, including Microsoft Edge, ignore the namespace proxy setting entirely, which seriously limits this feature’s usefulness in most organizations today.

Workaround

If routing a public website over the Always On VPN tunnel is required, adding its IP address(es) to the Always On VPN connection’s routing table is needed. However, doing this presents some unique challenges, as public websites frequently have many IP addresses, which are often dynamically changing. Also, it is common for public websites to pull content from many different domains or use Content Delivery Networks (CDNs), making the problem of identifying which IP addresses to add to the Always On VPN connection’s routing table even more challenging. Further, administrators must update the client configuration each a public website’s IP address changes, adding significant management overhead.

Summary

Routing client Internet traffic through an on-premises web proxy server for Always On VPN clients works well when force tunneling is enabled. Administrators can explicitly define a web proxy server or use a proxy automatic configuration (PAC) file. All web browsers work without issue in this scenario. Using a namespace proxy is only effective when browsing with Microsoft Internet Explorer. All modern web browsers, including Microsoft Edge, ignore namespace proxy settings.

Additional Information

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

Windows 10 VPNv2 Configuration Service Provider (CSP) Reference

Windows 10 Always On VPN Client DNS Server Configuration

Always On VPN DNS Registration Update Available

Always On VPN DNS Registration Update AvailableWhen configuring Always On VPN, administrators have the option to enable DNS registration for VPN clients. When this option is set, VPN clients will register the IP address assigned to their VPN interface in the internal DNS. This allows client devices to be managed using their hostname from the internal network whenever they are connected remotely.

DNS Registration

DNS registration is enabled in one of two ways, depending on how Always On VPN client devices are managed.

Intune

When using the native Microsoft Intune UI to manage Always On VPN profiles, DNS registration can be configured by selecting Enabled next to Register IP addresses with internal DNS in the Base VPN settings section.

Always On VPN DNS Registration Update Available

ProfileXML

When using custom ProfileXML with PowerShell, SCCM, or Intune, the administrator will define the RegisterDNS element to enable DNS registration.

Always On VPN DNS Registration Update Available

Known Issues

Some users have reported unexpected behavior when DNS registration is enabled. Specifically, under some circumstances the VPN client will register the IP address of the VPN network interface along with the IP address of its public network interface (Wi-Fi, Ethernet, etc.). However, the VPN client can only be managed using the VPN interface. If the VPN client’s hostname resolves to its public IP address, manage out will fail.

This appears to happen only when Name Resolution Policy Table (NRPT) rules are defined in Intune DNS settings, or if the DomainNameInformation element is defined in ProfileXML.

Always On VPN DNS Registration Update AvailableAlways On VPN DNS Registration Update Available

Resolution

Microsoft recently released fixes for this DNS registration issue for Windows 10. The fix for this issue is included in the following updates.

Windows 10 1803 – KB4507466
Windows 10 1809 – KB4505658
Windows 10 1903 – KB4505903

Additional Configuration

After installing the update, the following registry entry must be defined on each VPN client.

HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DisableNRPTForAdapterRegistration DWORD = 1

To enable this setting, open an elevated PowerShell window and run the following command.

New-ItemProperty -Path ‘HKLM:SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\’ -Name DisableNRPTForAdapterRegistration -PropertyType DWORD -Value 1 -Force

Once complete, restart the client device for the changes to take effect. After validation testing is complete, the registry entry can be deployed to Always On VPN clients using Active Directory group policy preferences or Intune.

Additional Information

Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML

Windows 10 Always On VPN Updates to Improve Connection Reliability

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Hands-On Training Classes