All posts in category DNS

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

Leave a comment
by Richard M. Hicks on January 9, 2023  •  Permalink
Posted in Active Directory, administration, Always On VPN, AOVPN, DNS, DNS Policies, Enterprise, enterprise mobility, Infrastructure, Microsoft, Mobility, Name Resolution, name resolution policy table, NRPT, Operational Support, PowerShell, Remote Access, Split DNS, troubleshooting, user tunnel, VPN, Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022
Tagged , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 9, 2023

https://directaccess.richardhicks.com/2023/01/09/always-on-vpn-and-split-dns/

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

Recently I wrote about a compelling solution from PowerON Platforms for managing Always On VPN client configuration setting using Active Directory group policy. Always On VPN Dynamic Profile Configurator (DPC) addresses a very specific need for managing Always On VPN for organizations that have not yet migrated to Microsoft Endpoint Manager/Intune. Recently, PowerON Platforms released an important update to DPC that includes many new features and capabilities.

New Features

Always On VPN DPC version 3.0 includes the following new functionality Always On VPN administrators are sure to find useful.

  • Traffic filters – Support for enabling traffic filters for both device tunnel and user tunnel are now supported in DPC, greatly simplifying the task of creating access control lists to enforce zero-trust network access (ZTNA) policies.
  • Enhanced security – The option to disconnect the VPN connection if the VPN server does not present a cryptobinding TLV is now enabled by default. This often-overlooked security setting ensures VPN client connections are not intercepted by detecting man-in-the-middle attacks.
  • Device tunnel enhancements – Administrators can now display the device tunnel connection and status in the Windows UI.
  • Backup connection – Always On VPN DPC now supports the configuration and deployment of a backup VPN connection, which is helpful when Always On VPN connectivity is disrupted.
  • Hostname routing – Administrators can now define hostnames in the routing table. Hostnames are resolved on the endpoint and converted to IP addresses for including in the routing table.
  • Smart card authentication – Always On VPN DPC now supports smart card authentication as an authentication option in addition to client authentication certificates.

Learn More

Interested in learning more about Always On VPN DPC? Fill out the form below and I’ll provide you with additional information or visit aovpndpc.com to sign up for a free trial.

Additional Information

Always On VPN with Active Directory Group Policy

Always On VPN Video Demonstration

Always On VPN DPC Advanced Features

Always On VPN DPC on YouTube

Leave a comment
by Richard M. Hicks on July 25, 2022  •  Permalink
Posted in Active Directory, administration, Always On VPN, Always On VPN DPC, AOVPN, AovpnDPC, Application Filter, device tunnel, DNS, DPC, EAP, Endpoint Manager, Enterprise, enterprise mobility, Group Policy, MDM, MEM, MEMCM, Microsoft Endpoint Manager, Microsoft Intune, Mobile Device Management, Mobility, Name Resolution, Operational Support, ProfileXML, Remote Access, routing and remote access service, RRAS, SCCM, Security, System Center Configuration Manager, systems management, Traffic Filter, Update, user tunnel, VPN, Windows 10, Windows 11, Zero Trust, Zero Trust Network Access, ZTNA
Tagged , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on July 25, 2022

https://directaccess.richardhicks.com/2022/07/25/whats-new-in-always-on-vpn-dpc-v3-0/

Always On VPN SSTP with Let’s Encrypt Certificates

Always On VPN SSTP Security Configuration

When configuring the Windows Server Routing and Remote Access Service (RRAS) to support Secure Socket Tunneling Protocol (SSTP) for Always On VPN user tunnel connections, administrators must install a Transport Layer Security (TLS) certificate on the VPN server. The best practice is to use a certificate issued by a public Certification Authority (CA). In addition, administrators should use a TLS certificate using Elliptic Curve Digital Signature Algorithm (ECDSA) for optimal security and performance.

Let’s Encrypt

Obtaining a public TLS certificate is not inherently difficult, nor is it expensive. However, Let’s Encrypt is a nonprofit public CA issues TLS certificates entirely for free. Always On VPN supports Let’s Encrypt TLS certificates, and installing a Let’s Encrypt certificate on the Always On VPN RRAS server is quite simple.

Pros and Cons

Using Let’s Encrypt certificates for Always On VPN has several significant advantages over traditional public CAs.

  • Cost – Let’s Encrypt certificates are free! No cost whatsoever.
  • Speed – Enrolling for a Let’s Encrypt certificate takes just a few minutes.
  • Trusted – Let’s Encrypt certificates are trusted by default in Windows 10 and Windows 11.

Let’s Encrypt is not without some drawbacks, however.

  • Lifetime – Let’s Encrypt certificates are only valid for 90 days.
  • Administration – Certificates must be redeployed frequently (every 90 days).
  • Security – PFX files (which include private keys) are left on disk by default.

It is possible to mitigate some of these drawbacks, though. For example, deleting PFX files after import can improve security. Alternatively, using a Certificate Signing Request (CSR) eliminates PFX files completely.

Also, it is possible to fully automate the Let’s Encrypt certificate enrollment and RRAS configuration process, which eases the administrative burden. And rotating certificates every 90 days could be considered an advantage from a security perspective! Enrolling new certificates (and specifically certificates with unique keys) is advantageous in that respect.

Certificate Enrollment

There are several different ways to enroll for Let’s Encrypt certificates. The preferred method is using PowerShell, as it works on both Windows Server with Desktop Experience (GUI) and Windows Server Core. Using PowerShell, administrators can also fully automate the enrollment and assignment of the certificate in RRAS.

PowerShell Module

To enroll for Let’s Encrypt TLS certificates on the VPN server, install the Posh-ACME PowerShell module. On the RRAS server, open an elevated PowerShell window and run the following command.

Install-Module Posh-ACME

Certificate Request

After installing the Posh-ACME PowerShell module, select a Let’s Encrypt environment by running the following command. Use LE_PROD for the production Let’s Encrypt server or LE_STAGE for the staging environment (used for testing).

Set-PAServer LE_PROD

Next, request a new certificate using the following command.

New-PACertificate -Domain vpn.example.net -Contact ‘[email protected]’ -CertKeyLength ec-256 -AcceptTOS -Install

The administrator is prompted to create a TXT record in public DNS to prove ownership of the domain. Using the example above, create a DNS record called _acme-challenge.vpn in the example.net DNS zone.

Once complete, the TLS certificate is automatically installed in the local computer certificate store on the VPN server and can be assigned in the RRAS management console, as shown here.

Note: R3 is a Let’s Encrypt issuing certification authority.

DNS Plugin

The Posh-ACME PowerShell module supports DNS plugins that allow administrators to automate the creation of the DNS TXT record used to authorize certificate enrollment. DNS plugins for many public DNS providers are available. Some of the more popular DNS providers are listed here.

  • Microsoft Azure
  • Amazon Route53
  • Cloudflare
  • Akamai
  • GoDaddy
  • Infoblox
  • Windows Server

A list of all supported DNS plugins for Posh-ACME can be found here.

Certificate Binding

Administrators can use the following PowerShell example code to automate the process of binding the new TLS certificate to the SSTP listener in RRAS.

$Thumbprint = <TLS certificate thumbprint>
$Cert = Get-ChildItem -Path Cert:\LocalMachine\My\$thumbprint
Set-RemoteAccess -SslCertificate $Cert
Restart-Service RemoteAccess -Passthru

Additional Information

Posh-ACME Tutorial

Windows 10 Always On VPN TLS Certificate Requirements for SSTP

Windows 10 Always On VPN SSTP Security Configuration

3 Comments
by Richard M. Hicks on October 4, 2021  •  Permalink
Posted in Always On VPN, AOVPN, authentication, certificates, DNS, ECC, Elliptic Curve Cryptography, Encryption, Enterprise, enterprise mobility, Mobility, Operational Support, PKI, PowerShell, public key infrastructure, Remote Access, routing and remote access service, RRAS, Secure Socket Tunneling Protocol, Security, SSL, SSL and TLS, SSTP, TLS, user tunnel, VPN, Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022

Posted by Richard M. Hicks on October 4, 2021

https://directaccess.richardhicks.com/2021/10/04/always-on-vpn-sstp-with-lets-encrypt-certificates/

« Older Posts
%d bloggers like this: