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

When Always On VPN Isn’t

Microsoft Always On VPN is a beautiful thing. VPN profiles are assigned to the user (and, optionally, their device). When users power up their device and log on, they are automatically connected to the corporate network and can access all the applications and data they need on-premises. Until recently, though, end users could disconnect the VPN. Why they would do this is beyond comprehension, but sadly, it happens all too often. When it does, it presents a problem for Always On VPN administrators because they must now rely on the user to re-enable this feature. And until they do, they often suffer productivity loss, and their devices may fall out of compliance.

Connect Automatically

When an Always On VPN profile is provisioned to a user (or a device), the VPN profile has the option to ‘Connect automatically’ enabled by default. Unfortunately, this setting is cleared if a user terminates the VPN.

This setting will remain cleared until the user rechecks the box to enable it. Until then, the VPN will no longer connect automatically.

Workarounds

Instead of relying on the grace of the end user to restore Always On functionality, administrators have a few options to correct this problem programmatically.

Intune Remediation

Administrators can use Intune Remediations to deploy a set of detection and remediation scripts I’ve published to update this setting. Now, administrators can enforce ‘Always On’ VPN connections with the assurance that if the user turns off this feature, it will be quickly re-enabled.

Detect-AutoTriggerDisabledProfile.ps1

Remediate-AutoTriggerDisabledProfile.ps1

SCCM

You can find a standalone version of this script here if you use System Center Configuration Manager (SCCM) or another systems management solution to manage your endpoints.

Clear-AutoTriggerDisabledProfile.ps1

AovpnTools

In addition, you will find the Clear-AutoTriggerDisabledProfile function is included in my AOVPNTools PowerShell module, which can be installed from the PowerShell gallery.

Install-Module -Name AOVPNTools -Force

Disable Disconnect Button

To avoid this pain in the future, Always On VPN administrators can prevent users from disconnecting the VPN using the UI by leveraging the DisableDisconnectButton option in ProfileXML. This setting is supported for both user and device tunnels on Windows 11 and later devices.

Additional Information

AOVPNTools PowerShell Module

AOVPNTools PowerShell Module on GitHub

Always On VPN and Intune Remediations

10 PowerShell Commands Always On VPN Administrators Should Know

Managing a secure and reliable VPN infrastructure is critical for supporting today’s highly mobile workforce. For Always On VPN administrators, PowerShell is an indispensable tool for achieving this goal. Not only can PowerShell be used to automate the installation and configuration of Windows Server Routing and Remote Access Service (RRAS) server, but it can also be used to audit configuration and monitor system health and user activity as well. In addition, it is highly recommended that the RRAS role be installed on Server Core for optimum security and performance. Administrators must be familiar with these PowerShell commands and more to support RRAS on Windows Server Core in their environment.

RemoteAccess Module

The RemoteAccess PowerShell module should be installed when the RRAS server is configured. There are 122 commands in this module, but only a subset of those pertain to the VPN server role. Here are ten popular commands for monitoring and managing an Always On VPN RRAS server.

Configuration Review

The following PowerShell commands are useful for reviewing the current RRAS server configuration.

Get-RemoteAccess – Displays the current configuration of the VPN server. Details include installation status, TLS certificate configuration, VPN client IP address assignment method, IPv4 and IPv6 addressing information (if using the static address assignment method), authentication type, and configured RADIUS servers.

Get-VpnAuthProtocol – Displays authentication configuration details such as accepted authentication types for both user and device connections, root certification authority (CA) certificate restrictions (if enabled), and certificate advertisement and EKU restrictions if enabled.

Get-VpnServerConfiguration – Displays additional VPN server configuration information, such as the IPsec configuration for IKEv2, the number of VPN ports configured, and more.

System Health

Get-RemoteAccessHealth – Displays the current health status of various VPN server services. The command’s default output is a little noisy. I recommend filtering it as follows:

Get-RemoteAccessHealth | Where-Object HealthState -NotMatch Disabled | Format-Table -AutoSize

User Activity

The following PowerShell commands can be used to view current and historical user activity details.

Get-RemoteAccessConnectionStatistics – Displays all active VPN connections on the server.

Get-RemoteAccessConnectionStatisticsSummary – Displays cumulative information about VPN connections on the server since the last service restart or reboot, such as the total number of connections, the number of unique users, the maximum number of concurrent connections, and the amount of data transferred.

Get-RemoteAccessUserActivity – Displays all active VPN connections for a specific user or device.

Management

The following PowerShell commands are helpful for reviewing authentication and logging settings.

Get-RemoteAccessRadius – Allows the administrator to view the currently configured RADIUS servers on the VPN server.

Get-RemoteAccessAccounting – Allows the administrator to view the current accounting repository (RADIUS or inbox) on the VPN server.

Clear-RemoteAccessInboxAccountingStore – Allows the administrator to remove log data from the Inbox Accounting database. Removing log data from the database can be helpful when transitioning a test server to production or to free up disk space by reducing the size of the logging database.

Additional Modules

In addition to the PowerShell commands above, Always On VPN administrators can leverage my custom PowerShell modules for advanced server and client configuration. These modules are published in the PowerShell Gallery.

AovpnTools – PowerShell module to configure and optimize Windows RRAS servers to support Always On VPN.

Install-Module -Name AovpnTools

InboxAccountingDatabaseManagement – PowerShell module to configure and manage the Inbox Accounting database for logging system information and user activity on the VPN server.

Install-Module -Name InboxAccountingDatabaseManagement

Additional Information

Always On VPN and RRAS on Windows Server Core

Inbox Accounting Database Management

AovpnTools PowerShell Module on GitHub

Inbox Accounting Database Module on GitHub