Microsoft has published its monthly security updates. Many updates address Routing and Remote Access Service (RRAS) vulnerabilities commonly used in Always On VPN deployments. In addition, an update addresses a vulnerability in Active Directory Certificate Services (AD CS). Always On VPN user and device authentication often rely on AD CS-issued certificates.
RRAS Updates
The April 2025 Microsoft security updates include the following CVEs for Windows Server RRAS.
Only one of these CVEs (26668) is a Remote Code Execution vulnerability. The others are information disclosure vulnerabilities. None of these vulnerabilities are rated Critical; all are rated Important.
AD CS Update
This month’s security update includes the following CVE for AD CS.
CVE-2025-27740 – AD CS Elevation of Privilege Vulnerability
Recently, I had the opportunity to deploy the Loadbalancer.org load balancer as part of an enterprise Always On VPN deployment. In the past, I’ve published guidance for using F5 BIG-IP, Citrix ADC (formerly NetScaler), and Kemp LoadMaster, so in this post, I’ll provide guidance for configuring Loadbalancer.org for Always On VPN.
IKEv2
Open the Loadbalancer.org management console and follow the steps below to configure Always On VPN load balancing on the appliance.
Create Virtual Service
Create a layer 4 virtual service for IKEv2.
Click Cluster Configuration.
Click Layer 4 – Virtual Services.
Click Add a new Virtual Service.
Enter a descriptive name for the virtual service in the Label field.
Enter the virtual IP address (VIP) for the service in the IP Address field.
Enter 500,4500 in the Ports field.
Select UDP from the Protocol drop-down list.
Select NAT from the Forwarding Method drop-down list.
Click Update.
Add Real Servers
Add real servers to the virtual service.
Click Layer 4 – Real Servers.
Click Add a new Real Server next to the IKEv2 virtual service.
Enter a descriptive name for the real server in the Label field.
Enter the IP address of the real server in the Real Server IP Address field.
Click Update.
Repeat these steps for each additional VPN server in the cluster.
SSTP
Follow the steps below to configure SSTP load balancing on the appliance.
Create Virtual Service
Create a layer 4 virtual service for SSTP.
Click Cluster Configuration.
Click Layer 4 – Virtual Services.
Click Add a new Virtual Service.
Enter a descriptive name for the virtual service in the Label field.
Enter the virtual IP address (VIP) for the service in the IP Address field.
Enter 443 in the Ports field.
Select TCP from the Protocol drop-down list.
Select NAT from the Forwarding Method drop-down list.
Click Update.
Configure Virtual Service Health Check
Update the health check method for the SSTP virtual service.
Click Layer 4 – Virtual Services.
Click Modify on the SSTP virtual service.
Select Negotiate from the Check Type drop-down list in the Health Checks section.
Enter 443 in the Check Port field.
Select HTTPS from the Protocol drop-down list.
Enter /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ in the Request to send field.
Enter 401 in the Response expected field.
Click Update.
Note: Using the Negotiate health check type for the SSTP monitor on Loadbalancer.org appliances requires version 8.13.0 or later. Administrators can use the External script option when using earlier releases of Loadbalancer.org appliances. An SSTP health check script for Loadbalancer.org can be found here.
Add Real Servers
Add real servers to the virtual service.
Click Layer 4 – Real Servers.
Click Add a new Real Server next to the SSTP virtual service.
Enter a descriptive name for the real server in the Label field.
Enter the IP address of the real server in the Real Server IP Address field.
Click Update.
Repeat these steps for each additional VPN server in the cluster.
Review
Once complete, click System Overview to view the overall health of your VPN servers.
Summary
The Loadbalancer.org appliance is an efficient, cost-effective, and easy-to-configure load-balancing solution that works well with Always On VPN implementations. It’s available as a physical or virtual appliance. There’s also a cloud-based version. It also includes advanced features such as TLS offload, web application firewall (WAF), global server load balancing (GSLB), and more. If you are looking for a layer 4-7 load balancer for Always On VPN and other workloads, be sure to check them out.
Recently, I wrote about Microsoft Always On VPN and Entra Conditional Access and how conditional access improves your organization’s security posture by making policy-based access decisions based on various signals such as user identity, location, device compliance, platform, sign-in risk, and more. In this post, I’ll provide step-by-step instructions for integrating Entra Conditional Access with existing Always On VPN deployments.
Requirements
To use Microsoft Entra Conditional Access with Always On VPN you must have Entra ID P1 at a minimum. To use advanced features such as risk-based policy assessment, you must have Entra ID P2. In addition, all endpoints must be under Intune management; either native Entra ID joined, or hybrid Entra ID joined.
Enable VPN Support
To begin, open the Microsoft Entra admin center (https://entra.microsoft.com/), navigate to Identity > Protection > Conditional Access, and perform the following steps.
Click VPN Connectivity.
Click New certificate.
From the Select duration drop-down list, choose an appropriate certificate validity period.
Click Create.
Once complete, click Download certificate and copy the certificate file to a domain-joined system on-premises.
Publish Certificate
Next, administrators must publish the Entra VPN root certificate in Active Directory to support domain authentication. Open an elevated PowerShell or command window and run the following commands.
certutil.exe -dspublish -f <path to certificate file> RootCA
certutil.exe -dspublish -f <path to certificate file> NtAuthCA
Note: You must be a domain administrator to perform this task.
Conditional Access Policy
Navigate to Identity > Protection > Conditional Access and click Policies, then perform the following steps to create a conditional access policy for VPN access.
Click New Policy.
Enter a descriptive name for the new policy.
Click the link in the Target resources section.
From the Select what this policy applies to drop-down list, select Resources (formerly cloud apps).
In the Include section, choose Select resources.
Click the link in the Select section.
Enter VPN in the search field.
Check the box next to VPN Server.
Click Select.
Click the link in the Grant section.
Select Grant access.
Check the box next to Require device to be marked as compliant.
Click Select.
On the Enable policy slider, select On.
Click Create.
NPS
Changes to Network Policy Server (NPS) policy and configuration are required to support Always On VPN with Entra Conditional Access.
NPS Policy
To update the Always On VPN network policy to support Entra Conditional Access, open the NPS management console (nps.msc), expand Policies, then select Network Policies and perform the following steps.
Right-click on the Always On VPN policy and choose Properties.
Select the Settings tab.
Select Vendor Specific in the RADIUS Attributes section.
Click Add.
Select the Allowed-Certificate-OID attribute.
Click Add.
Click Add.
Enter 1.3.6.1.4.1.311.87 in the Attribute value field.
Click Ok.
Click Ok.
Click Close.
Click Ok.
Important Note: This change will block new Always On VPN user tunnel connections until you update the client configuration. When integrating an existing Always On VPN implementation with Entra Conditional Access, consider creating a new NPS policy and corresponding security group to migrate users to conditional access seamlessly.
NPS Configuration
By default, NPS will perform revocation checks for certificates used for domain authentication. However, Entra Conditional Access uses short-lived certificates (one-hour lifetime) that do not include CRL Distribution Point (CDP) information. Therefore, administrators must change the NPS server configuration to disable revocation checking for certificates lacking this information.
To do this, open the registry editor (regedit.exe) and create a new registry key with the following settings.
Once complete, the server must be rebooted for the change to take effect.
Client Configuration
After making all required changes to the supporting infrastructure, you must also update the Always On VPN client configuration to leverage Entra Conditional Access. Changes to client configuration vary depending on the method used to deploy and manage Always On VPN client configuration settings.
Intune
When using Microsoft Intune and the native VPN policy type to deploy and manage Always On VPN client configuration settings, perform the following steps to update the VPN configuration to include Entra Conditional Access support.
Click Enable next to Conditional access for this VPN connection.
Click Enable next to Single sign-on (SSO) with alternate certificate.
Enter Client Authentication in the Name field.
Enter 1.3.6.1.5.5.7.3.2 in the Object Identifier field.
Enter the organization’s root certification authority (CA) certificate thumbprint in the Issuer hash field.
XML
When using a custom XML configuration file for Always On VPN client configuration settings deployed using Intune or PowerShell, edit the XML file, remove the existing <TLSExtensions></TLSExtensions> section, and replace it with the following.
In addition, add the following code between the <VPNProfile></VPNProfile> tags after <TrustedNetworkDetection>.
Note: You will find a sample XML configuration file you can copy and paste from on GitHub here.
DPC
When using Always On VPN Dynamic Profile Configurator (DPC) for managing Always On VPN client configuration settings, open the DPC group policy and navigate to Computer Configuration > Policies > Administrative Templates > DPC Client > User Tunnel Settings > Advanced and perform the following steps.
Following the guidance in this post to integrate Entra Conditional Access with Always On VPN can significantly improve your organization’s security posture. In the example above, the conditional access policy is a basic one. Yet, it dramatically reduces the attack surface for your remote access infrastructure by ensuring only compliant devices can establish a VPN connection.
Administrators can use advanced conditional access policy settings to strengthen the VPN’s security further by performing additional checks, such as requiring strong, phishing-resistant credentials and requesting multifactor authentication (MFA) for risky sign-ins.
