Always On VPN Client IP Address Assignment Methods

When Always On VPN clients connect to the VPN server, they must be assigned an IP address to facilitate network communication. When using Windows Server and Routing and Remote Access Service (RRAS) for VPN services, administrators must choose between Dynamic Host Configuration Protocol (DHCP) and static address pool assignment methods.

DHCP

DHCP is a quick and easy way to handle VPN client IP address assignment. However, there are some drawbacks and limitations associated with this option. Consider the following.

Allocation

DHCP for Always On VPN clients does not work as you might expect. For example, when a VPN client connects, it does not obtain its IP address directly from the DHCP server. Instead, the VPN server leases a block of IP addresses from the DHCP server and manages those on behalf of its clients. On the DHCP server, you will see the Unique ID column of these IP address leases indicating RAS.

Address Block Size

After configuring the VPN server to use DHCP VPN client IP address assignment, the VPN server will automatically lease a block of ten IP addresses from a DHCP server. When this initial block of ten IP addresses is exhausted, the VPN server will lease another block of ten IP addresses. Administrators can increase the size of the requested address block by creating the following registry key on each VPN server.

Key: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IP
Value: InitialAddressPoolSize
Type: DWORD
Data: <size of DHCP pool request>

Alternatively, administrators can download Update-VpnServerDhcpPoolSize.ps1 from my GitHub repository and run it on each VPN server to increase the size of the initial DHCP address pool request.

DHCP Options

The VPN server discards all DHCP option information returned by the DHCP server. The VPN server uses only the IP address from the DHCP lease. The client is unaware of any other information in the DHCP lease.

Subnet

By default, the VPN server will only request DHCP addresses from a scope that matches the same subnet as the IP address assigned to the VPN server’s network adapter. If the VPN server has more than one network interface, it will send DHCP requests from the network interface listed on the Adapter drop-down list, as shown here.

Note: This option is only available on servers configured with multiple network interfaces. Also, if the value is set to Allow RAS to select adapter, it is best to specifically define the network interface where DHCP and DNS requests are made.

Scope Size

When using the DHCP assignment method, ensure the DHCP scope contains enough IP addresses to support the number of concurrent connections expected on all VPN servers.

IPv6

DHCPv6 is not supported on RRAS for VPN client IP address assignment. The only option for IPv6 is prefix assignment.

RRAS in Azure

DHCP is not supported when deploying RRAS in Azure. Administrators deploying RRAS in Azure to support Always On VPN must use the static address pool assignment method. More details here.

Known Issues

When using DHCP with Windows Server 2019 RRAS servers, a known issue prevents this from working correctly. Administrators can download Update-VpnServerDhcpPrivileges.ps1 from my GitHub repository and run it on each VPN server to ensure proper DHCP operation.

Increased Complexity

Since the VPN server leases IP addresses on behalf of clients and discards DHCP option information included in the lease, there’s no real benefit to using DHCP. Using DHCP only adds complexity and introduces another dependency, making the solution more brittle and difficult to manage. Using the static address pool assignment method is a better choice.

Static Pool

Implementation best practices dictate using the static address pool assignment method instead of DHCP. The following is guidance for configuring RRAS to support the static address pool option for VPN client IP address assignment.

Unique Subnet

Using a unique IP subnet is best when using the static address pool assignment method. However, this also requires configuring internal network routing to return traffic for that subnet to the individual VPN server where that subnet is assigned. Each server must have a unique IP address pool assigned. Define static address pools using subnet boundaries when configuring multiple VPN servers. Assigning IP address pools along subnet boundaries simplifies internal network routing configuration. Ensure that assigned IP address pool subnets are large enough to accommodate the total number of concurrent connections expected on each server. Be sure to overprovision to handle failover scenarios.

Same Subnet

Alternatively, administrators can assign VPN client IP addresses from the same subnet as the VPN server’s network interface. Assigning VPN client IP addresses from the same subnet as the VPN server eliminates the need for any internal network routing configuration, simplifying deployment. However, server subnets are often small and may not have enough IP address space to support numerous concurrent VPN connections. Be sure to plan accordingly.

Static IP Addresses

It is possible to assign a static IP address to an individual user. However, assigning a static IP address to a specific device is not. I will discuss static IP address assignments for Always On VPN clients in a future blog post.

Other Limitations

Here are some additional things to consider when creating a VPN client IP addressing strategy.

DNS

Always On VPN clients can be configured to register their IP address in DNS. However, the VPN client configuration controls this setting. The DHCP server does not register IP addresses in DNS when using DHCP. The client registers its IP address in DNS directly after it connects. In addition, a VPN client will receive a different IP address each time it connects to the VPN server. DNS propagation can delay hostname resolution on-premises for remote-connected VPN clients.

Selective Addressing

Regardless of which assignment method is selected, assigning different IP addresses to different types of connections is not possible. For example, a common ask is to assign user connections from one IP address pool and device connections from another. The only option to support this is to use different servers for each type of connection.

Summary

The best practice for IPv4 VPN client addressing is to use the static address pool method with a unique IPv4 subnet per server. Using static address pool assignment provides the most flexible configuration options and eliminates the dependency on internal services, making the solution more resilient and easier to manage. A unique address pool per server ensures that a large enough subnet can be defined to support the expected number of concurrent connections, regardless of the subnet size the VPN server is assigned to. Also, a unique IP subnet for VPN clients makes configuring internal firewall rules to control VPN client access easier.

Additional Information

Always On VPN and IPv6

Always On VPN Client DNS Server Configuration

Always On VPN Routing Configuration

Always On VPN RRAS Internal Interface Non-Operational

Always On VPN and Interface Metrics

Always On VPN DNS Registration Update Available

In Windows, each network interface identified by the operating system is assigned a metric value. Interface metrics are settings that determine the priority or preference of network interfaces when there are multiple active network connections. The Windows networking stack uses these metrics to determine which network interface should be used for routing traffic when multiple network interfaces are available. Network interface metrics are critical for Always On VPN administrators to understand because they can impact how name resolution requests are processed when an Always On VPN connection is established.

Metric Values

By default, Windows automatically assigns metric values to network interfaces (including VPN interfaces) based on various factors, including the connection speed, link state, and interface type. It tries to select the most suitable interface for general internet connectivity.

Metrics and DNS

Windows will also use the network interface with the lowest metric value as the preferred interface for sending DNS queries by default. This means that DNS queries will be routed through the network interface with the lowest metric value, assuming it is available and connected. When an Always On VPN connection is established, DNS queries may fail or return unexpected results if the network interface metrics are not configured optimally.

Split DNS and Wired Ethernet

Split DNS (sometimes called ‘split brain DNS’) is when the DNS namespace is the same internally and externally. The most common scenario where interface metric settings interfere with DNS operation is when using split DNS and the endpoint is connected to the Internet with a wired Ethernet connection. In this scenario, the Ethernet interface will be assigned the same or lower interface metric value as the Always On VPN interface, which can yield unexpected results.

Viewing Metrics

Always On VPN administrators can view currently assigned interface metric values by running the following PowerShell command.

Get-NetIpInterface

Assigning Metrics

Most Always On VPN administrators will never have to change interface metric settings. However, if your implementation uses split DNS and some of your endpoints connect using wired Ethernet connections, you may need to update the interface metric settings to ensure proper DNS operation. Choose a setting for the interface metric value that is lower than the wired Ethernet interface. I’ve used a value of ‘3’ without issue for many years. Use one of the following methods to update the interface metric for Always On VPN connections.

PowerShell

Updating interface metric settings in Windows can be accomplished by running the Set-NetIpInterface PowerShell command.

Set-NetIpInterface -InterfaceAlias <connection name> -InterfaceMetric 3

Note: Using PowerShell to assign the interface metric is not persistent! While this method is suitable for local validation testing, you should use one of the following methods to implement this change permanently.

Rasphone.pbk

To assign the interface metric permanently, Always On VPN administrators can edit the following settings in the rasphone.pbk configuration file.

IpInterfaceMetric=3

Ipv6InterfaceMetric=3

Administrators can automate updating this setting using the Update-Rasphone.ps1 PowerShell script. In addition, the following scripts can be used with Microsoft Intune remediation.

Detect-DeviceIpv4InterfaceMetric.ps1

Remediate-DeviceIpv4InterfaceMetric.ps1

Detect-DeviceIpv6InterfaceMetric.ps1

Remediate-DeviceIpv6InterfaceMetric.ps1

Detect-Ipv4InterfaceMetric.ps1

Remediate-Ipv4InterfaceMetric.ps1

Detect-Ipv6InterfaceMetric.ps1

Remediate-Ipv6InterfaceMetric.ps1

DPC

Organizations using PowerON Platforms’ Dynamic Profile Configurator (DPC) to manage Always On VPN client configuration settings with Active Directory and group policy or Microsoft Intune can enable the VPN Tunnel Metric setting.

Additional Information

Get-NetIpInterface PowerShell Command

Set-NetIpInterface PowerShell Command

Managing Always On VPN Client Settings with DPC

Always On VPN DPC with Microsoft Intune

Always On VPN DPC Advanced Features

Always On VPN DPC Video Demonstration

PowerON Platforms Always On VPN Dynamic Profile Configurator (DPC)

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