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 DPC with Intune

In the past, I’ve written about PowerON Platforms’ Always On VPN Dynamic Profile Configurator (DPC), a software solution administrators can use to provision and manage Always On VPN client configuration settings using Active Directory and group policy. In addition to streamlining the deployment and management of Always On VPN client settings, DPC has many advanced features and capabilities to ensure optimal security, performance, and connection reliability.

Optimizations

Many settings required to fine-tune and optimize Always On VPN connections are not exposed in the Intune UI or XML. They must be configured by manipulating configuration files, setting registry keys, and running PowerShell commands. Much of this can be automated using Intune Proactive Remediation, but it is far from ideal. Administrators must configure Always On VPN using one method, then deploy optimizations using another. In addition, Proactive Remediation suffers from timing issues where some settings are not applied immediately, resulting in degraded or inoperable VPN connections until changes take effect.

Always On VPN DPC

Always On VPN DPC allows administrators to configure many advanced settings quickly and conveniently using the familiar Group Policy Management console (gpmc.msc). DPC dramatically reduces the administrative burden associated with Always On VPN client management. In addition, DPC enables many of these options by default, ensuring optimal security and reliable operation. Also, DPC immediately implements all configuration settings, eliminating the need to reboot to apply configuration changes.

Intune and ADMX

Historically, Always On VPN DPC could only be used when managing endpoints exclusively with Active Directory group policy. However, DPC can now be used with Microsoft Endpoint Manager/Intune thanks to a new feature that allows administrators to import custom ADMX and ADML administrative templates to Microsoft Endpoint Manager (MEM).

Note: This feature is in public preview at the time of this writing.

DPC and Intune

The combination of DPC and Intune brings with it many advantages. Using DPC with Microsoft Endpoint Manager/Intune offers administrators simplified deployment and many advanced features provided by Always On VPN DPC. In addition, customers who have deployed DPC on-premises can now migrate seamlessly to Microsoft Endpoint Manager/Intune management without giving up DPC’s valuable features.

Learn More

Enter your contact details in the form below for more information regarding Always On VPN DPC. Also, visit https://aovpndpc.com/ to register for a free Always On VPN DPC trial.

Additional Information

Always On VPN with Active Directory Group Policy

Introduction to Always On VPN DPC

Always On VPN DPC Advanced Features

Always On VPN DPC Video Demonstrations

What’s New in Always On VPN DPC v3.0

Always On VPN DPC Free Trial

Always On VPN NPS Auditing and Logging

The Network Policy Server (NPS) event log is incredibly valuable for administrators when troubleshooting Always On VPN user tunnel connectivity issues. Administrators can find these pertinent events by opening the Event Viewer on the NPS server (eventvwr.msc) and navigating to Custom Views > Server Roles > Network Policy and Access Services.

Event Logs

When configured correctly, event logs will record the disposition of all authentication requests, allowed or denied. The two most common recorded events are event IDs 6272 (access granted) and 6273 (access denied).

NPS Event ID 6272 – Access granted.

NPS Event ID 6273 – Access denied.

Auditing

In some cases, administrators may find none of these events recorded even though user authentication is working correctly. Here, the only events recorded are NPS informational events indicating which domain controller the NPS server is using to perform authentication.

The lack of 6272 and 6273 events in the event log indicates that auditing for NPS events is not enabled. Open an elevated PowerShell window and run the following command to view the current auditing setting for NPS events.

auditpol.exe /get /subcategory:”Network Policy Server”

Open an elevated PowerShell window and run the following command to enable auditing for NPS events.

auditpol.exe /set /subcategory:”Network Policy Server” /success:enable /failure:enable

Group Policy

Alternatively, consider using Active Directory group policy to enforce the NPS server auditing settings. Open the Group Policy Management Console (GPMC) and create a new GPO. Next, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff > Audit Network Policy Server and select the option to audit both success and failure attempts.

Once complete, link this GPO to the OU where the NPS servers reside.

Missing Events

If auditing is enabled and there are no recorded 6272 or 6273 events, the NPS server did not receive any authentication requests from the VPN server. Review the event logs on any other NPS servers if there is more than one configured. In addition, this may indicate that network communication between the VPN and NPS server is blocked. Ensure network connectivity and name resolution are working as expected.

Troubleshooting Guides

Are you interested in learning more about Always On VPN troubleshooting? My Always On VPN book contains an entire chapter dedicated to troubleshooting. Also, my Always On VPN video training course on Pluralsight includes a module on troubleshooting. The video training course is available to Pluralsight subscribers only. If you don’t have a Pluralsight subscription, you can sign up for a free trial here.

Additional Information

Troubleshooting Always On VPN Errors 691 and 812

Troubleshooting Always On VPN Errors 691 and 812 – Part 2

Troubleshooting Always On VPN Errors 691 and 812 – Part 3

Always On VPN NPS Load Balancing

%d bloggers like this: