Always On VPN and Blast-RADIUS

Microsoft released an update for the Windows Server Network Policy Server (NPS) to address recently disclosed vulnerabilities in the Remote Access Dial-In User Service (RADIUS) protocol in the July 2024 security updates. RADIUS is an industry-standard authentication protocol widely used for remote access, including Always On VPN. The RADIUS protocol was first introduced in the early 1990s and, unfortunately, still relies on the deprecated MD5 cryptographic hash function. The good news is that this vulnerability does not affect Always On VPN. Read on to learn more.

Blast-RADIUS

Blast-RADIUS is an attack on the RADIUS protocol that allows an attacker to alter network authentication packets to gain access to a service relying on RADIUS for authentication by exploiting the weakness of MD5 integrity checks in RADIUS. In the absence other controls, an attacker could alter an authentication response and change the reply from Access-Reject to Access-Accept.

Considerations

It’s important to note that leveraging this attack is not trivial. It requires local network access, so the attacker must have a presence on the target network to carry out this attack. However, cloud-hosted RADIUS services are inherently more vulnerable. In addition, the attack is mostly academic today because the default timeout for authentication requests is typically short, usually between 5 and 30 seconds. This is not enough time (today) for an attacker to mount the attack. However, this attack could become more feasible if authentication timeouts are increased (sometimes required to support MFA) or if an attacker has access to vast computing resources.

Affected Protocols

Although Blast-RADIUS is a vulnerability in the RADIUS protocol itself, not all authentication protocols are affected. Specifically, this vulnerability affects services leveraging PAP, CHAP, MS-CHAP, and MS-CHAPv2. Extensible Authentication Protocol (EAP) and Protected Extensible Authentication Protocol (PEAP) are not vulnerable to this attack. Since Always On VPN requires EAP authentication, it is not susceptible to this attack.

Mitigation

Microsoft has published guidance in KB5040268 for mitigating Blast-RADIUS attacks on Windows NPS servers. Specifically, administrators are encouraged to enable the Message-Authenticator attribute in Access-Request packets sent by the network access server and to ensure the NPS server requires the Message-Authenticator attribute in any Access-Request messages it receives.

Note: The following changes are not required for Always On VPN or any other workload using EAP-TLS or Protected EAP, as these protocols use TLS natively to protect the authentication exchange.

NPS

To configure this setting in the UI, open the NPS management console (nps.msc) and perform the following steps.

  1. Expand RADIUS Clients and Servers.
  2. Highlight RADIUS Clients.
  3. Right-click the RADIUS client to configure and choose Properties.
  4. Select the Advanced tab.
  5. Check the box next to Access-Request messages must contain the Message-Authenticator attribute.

PowerShell

To configure this setting using PowerShell, open an elevated PowerShell command window and run the following command.

Set-NpsRadiusClient -Name <RADIUS client name> -AuthAttributeRequired $True

Additional NPS Settings

Administrators should also run the following commands on their NPS servers to further protect their infrastructure from Blast-RADIUS attacks.

netsh.exe nps set limitproxystate all = enable

netsh.exe nps set requiremsgauth all = enable

RRAS

When using Windows Server Routing and Remote Access (RRAS) without EAP, ensure the RADIUS server configuration always includes the Message-Authenticator. To configure this setting, open the Routing and Remote Access console (rrasmgmt.msc) on the RRAS server and perform the following steps.

  1. Right-click the VPN server and choose Properties.
  2. Select the Security tab.
  3. Click the Configure button next to the Authentication provider drop-down list.
  4. Highlight the RADIUS server and choose Edit.
  5. Check the box next to Always use message authenticator.

Repeat these steps for any additional configured RADIUS servers.

CLI

Administrators can implement this change at the command line by opening an elevated command window and entering the following command.

netsh.exe ras aaaa set authserver name = <name of RADIUS server> signature = enabled

For example:

netsh.exe ras aaaa set authserver name = nps.lab.richardhicks.net signature = enabled

New NPS Events

After installing the KB5040268 update on NPS servers, the NPS server will record event ID 4421 from the NPS source after a service start if the RequireMsgAuth or LimitProxyState settings are not configured.

“RequireMsgAuth and/or limitProxyState configuration is in Disable mode. These settings should be configured in Enable mode for security purposes.”

Optional Mitigation

If administrators cannot configure the above settings, consider using IPsec to secure network traffic at the transport layer. IPsec will protect all RADIUS traffic at the network layer to mitigate Blast-RADIUS attacks. Unfortunately, Windows Server NPS does not support TLS or DTLS, so IPsec is your only option.

Summary

Always On VPN is not vulnerable to the Blast-RADIUS attack. However, NPS is commonly a shared service in many organizations, and other workloads may use older, vulnerable protocols. Consider implementing the changes detailed in KB5040268 as outlined in above to ensure the integrity of your environment and mitigate these potential attacks.

More Information

Microsoft KB5040268: how to manage Access-Request packets attack vulnerability associated with CVE-2024-3596

RADIUS Protocol Vulnerability Exposes Networks to MitM Attacks

New Blast-RADIUS attack breaks 30-year-old protocol used in networks everywhere

Overview of Microsoft Protected Extensible Authentication Protocol (PEAP)

Always On VPN NPS Auditing and Logging

Always On VPN Device Tunnel Issues with April 2024 Security Update

Always On VPN administrators may find that their device tunnel connections no longer connect automatically after applying the April 2024 security updates. The device tunnel connection is optional and only required under specific conditions, so end users may not be immediately impacted. However, administrators should be aware of this issue.

Note: The issues outlined in this post have been resolved with the May 14, 2024, security updates.

Error Messages

When manually establishing an Always On VPN device tunnel connection using rapshone.exe or rasdial.exe, you may receive one of the following error messages.

Rasphone.exe

Error 0x80070057: The parameter is incorrect.

Rasdial.exe

Connecting to <Name of Device Tunnel>…The parameter is incorrect.

Affected Devices

The issue affects all supported versions of Windows with an Always On VPN device tunnel connection configured to require a specific Enhanced Key Usage (EKU) OID. Administrators can run the following PowerShell command to identify this configuration.

Get-VpnConnection -AllUserConnection -Name <Name of Device Tunnel> | Select-Object MachineCertificateEkuFilter

If the output of this PowerShell command returns data, it is affected by this issue.

Workaround

To restore Always On VPN device tunnel functionality on devices with the April 2024 security updates installed, open an elevated PowerShell command window and run the following command.

Set-VpnConnection -AllUserConnection -Name ‘Always On VPN Device Tunnel’ -MachineCertificateEKUFilter $Null

After running this command, the output should now be blank.

Caveat

The problem with implementing the workaround described here is that you likely enabled this configuration to address an issue where the wrong certificate was selected for use with the device tunnel. In this case, the workaround may result in unexpected behavior and may not restore full functionality.

Known Issue Rollback

Currently, Microsoft is aware of the issue and is actively working to resolve it. If you are experiencing this issue, open a support case with Microsoft, and they will provide you with more information and possibly a private Known Issue Rollback (KIR). I will update this post as soon as Microsoft publishes a permanent fix.

Additional Information

Always On VPN Device Tunnel Operation and Best Practices

Always On VPN Device Tunnel Only Deployment Considerations

Considerations for Always On VPN with Azure VPN Gateway and Virtual WAN

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