Always On VPN Static IP Address Assignment

A question that occasionally arises when I’m conducting an Always On VPN planning and design workshop for a customer is static IP address assignment options for VPN connections. Typically, the use case is a specific user that requires special access to a sensitive system internally. Assigning a static IP address to the user allows administrators to create firewall rules restricting access to this connection.

Static IP Assignment

Assigning a static IP address to a user is accomplished by editing the properties of their user account in Active Directory. Open the Active Directory Users and Computers console (dsa.msc), navigate to the Dial-in tab on the target individual’s Active Directory user account, and check the box next to Assign Static IP Addresses.

Next, click the Static IP Addresses button, check the box next to Assign a Static IPv4 address, and enter an IP address. Optionally, check the box next to Assign a static IPv6 address and enter a prefix and Interface ID, if required.

NPS Configuration

Once the user account in Active Directory is configured with a static IP address assignment, each NPS server in the organization must be registered in Active Directory. More details on Active Directory registration for NPS servers can be found here.

Caveats

Assigning static IP addresses to VPN users has many drawbacks and limitations. Consider the following.

Device IP

Assigning a static IP address to a device is not supported. You can only assign a static IP address to a user in Active Directory.

Address Assignment

The IP address you assign to the user must be from the same subnet as the VPN server’s internal network interface. If there is more than one VPN server, all VPN servers must be on the same subnet.

Multisite

Assigning static IP addresses to users is not supported when VPN servers are deployed in multiple locations.

Concurrent Sessions

Users with a static IP address assignment must only log on to one device at a time. If a user attempts to log in to multiple devices simultaneously, subsequent connections will fail due to the duplicate IP address assignment.

NPS

Always On VPN administrators may have discovered the option to assign a static IP address using NPS policy. Unfortunately, this option is severely limited. A separate NPS policy is needed for each user that requires a static IP address. However, NPS does not support assigning NPS policies to users, only groups. Technically speaking, you could create a separate group for each user needing a static IP address, but that’s not scalable. Also, it offers no real advantage over using the Active Directory method described above.

Summary

Although it’s possible to assign a static IP address to a user, there is currently no option to assign a static IP address to a device. In addition, static IP address assignment imposes other limitations that make the option challenging. Also, the inability to connect to geographically dispersed VPN servers is severely limiting.

Additional Information

Always On VPN and NPS Active Directory Registration

Always On VPN Client IP Address Assignment Methods

Always On VPN and IPv6

Always On VPN and NPS AD Registration

Always On VPN Users Prompted for Certificate

Windows Server Network Policy and Access Services (NPAS, more commonly called NPS) is a popular solution used in Always On VPN deployments to support Active Directory authentication for user-based VPN connections. NPS is integrated with Active Directory to perform certificate-based authentication. With additional configuration, NPS can apply specific settings to an individual connection by reading the properties of the user’s AD account.

Dial-In Properties

Administrators can allow or deny network access, assign a static IP address, or assign a static route on a per-user basis. This information is defined on the Dial-In tab of the user account in Active Directory Users and Computers (dsa.msc).

Register in AD

Registering the NPS server in Active Directory is strictly optional. It is not required to perform user authentication. However, administrators must register the NPS server in Active Directory to assign connection properties per user. Active Directory registration for NPS allows the NPS server to read the properties of individual Active Directory user accounts. Active Directory registration for NPS is accomplished in one of several ways.

NPS Management Console

On each NPS server, open the NPS management console (nps.msc), right-click the server, and choose Register server in Active Directory.

Command Line

Administrators can register the NPS server in Active Directory by opening an elevated command window and running the following command.

netsh.exe nps add registeredserver <domain> <host>

Where <domain> is the Active Directory domain where you want to add the NPS server to the RAS and IAS Servers security group, and <host> is the hostname of the NPS server to register.

For example:

netsh.exe nps add registeredserver lab.richardhicks.net nps1

ADUC

Registering an NPS server in Active Directory does nothing more than add the NPS server to the RAS and IAS Servers domain security group. Administrators can open ADUC and add NPS servers to the group directly if required.

Note: Registering an NPS server in Active Directory using the NPS console or the command line adds the NPS server to the RAS and IAS Servers group in the domain to which the NPS server belongs. If user accounts are in a different domain, NPS servers must also be added to the RAS and IAS Servers group in those domains.

NPS Policy

In addition to registering the NPS server in Active Directory, administrators must ensure that the option to Ignore user account dial-in properties on the Network Policy used for Always On VPN is not checked.

Additional Information

Always On VPN and NPS Server Load Balancing

Always On VPN NPS Auditing and Logging

Always On VPN NPS RADIUS Configuration Missing

Always On VPN November 2023 Security Updates

Microsoft has released its security updates for November 2023. For Always On VPN administrators, it’s a light month, with just a single CVE affecting Always On VPN infrastructure.

PEAP

CVE-2023-36028 addresses a remote code execution (RCE) vulnerability in the Microsoft Protected Extensible Authentication Protocol (PEAP). An attacker could exploit this vulnerability by sending a specially crafted PEAP packet to a Windows Network Policy Server (NPS). This attack does not require authentication or user interaction.

Affected Systems

This PEAP vulnerability affects only NPS servers configured to support PEAP authentication explicitly. PEAP authentication is a best practice configuration for Always On VPN deployments and is widely deployed. NPS servers deployed to support other services, such as Wi-Fi or router and switch access that are configured to allow PEAP authentication, are also affected.

Exposure

NPS servers are not (or should not be!) exposed directly to the public Internet. This limits the attack surface to adversaries already on the internal network.

Mitigation

Microsoft suggests disabling PEAP authentication support on NPS servers until the update is applied. However, this would break the majority of Always On VPN deployments today. Since disabling PEAP isn’t a viable option, administrators can reduce their attack surface by updating the NPS firewall rules to restrict access only to authorized VPN servers or other network devices until their systems are fully updated.

Additional Information

November 2023 Security Updates

CVE-2023-36028 PEAP Remote Code Execution Vulnerability