How to Set Up Always On VPN with Windows Server 2025

Always On VPN (AOVPN) is Microsoft’s strategic successor to DirectAccess, providing automatic, transparent VPN connectivity for Windows 10 and Windows 11 devices without requiring IPv6 infrastructure or specific network hardware. Unlike DirectAccess — which is deeply tied to IPv6, Kerberos, and a specific AD/PKI topology — Always On VPN is protocol-agnostic, supports IKEv2 and SSTP, works natively over IPv4, and integrates with modern MDM platforms like Microsoft Intune for profile deployment. On Windows Server 2025, AOVPN is implemented through the combination of Routing and Remote Access Service (RRAS), Network Policy Server (NPS) as a RADIUS authentication backend, and a Public Key Infrastructure (PKI) providing machine and user certificates. This tutorial covers the full deployment from feature installation through certificate requirements, NPS configuration, and VPN profile deployment via Intune.

Always On VPN vs DirectAccess

Understanding why AOVPN replaces DirectAccess helps clarify the architectural decisions you will make during deployment.

  • IPv6 dependency: DirectAccess mandates IPv6 for internal network traversal (using 6to4, Teredo, or IP-HTTPS transition technologies). AOVPN uses standard IKEv2 or SSTP over IPv4 — no IPv6 required.
  • Infrastructure requirements: DirectAccess requires a specific server placement (edge or behind NAT with NAT64/DNS64), UAG or Forefront TMG support has ended. AOVPN works behind any NAT-capable firewall with a standard port (UDP 500/4500 for IKEv2, TCP 443 for SSTP).
  • MDM integration: AOVPN profiles are XML-based and deployable via Intune, SCCM, or PowerShell. DirectAccess had no MDM profile concept.
  • Tunnel types: AOVPN supports both a Device Tunnel (connects before user login, for machine policy and remote management) and a User Tunnel (connects after user login, for user traffic). DirectAccess only provided machine-level connectivity.
  • Platform support: DirectAccess required domain-joined Windows Enterprise editions. AOVPN supports domain-joined, hybrid Azure AD-joined, and Intune-managed devices.

Prerequisites

  • Windows Server 2025 server for the VPN/RRAS role (edge or behind NAT with port forwarding for UDP 500, 4500 and TCP 443)
  • Windows Server 2025 or 2022 server for the NPS/RADIUS role (can be co-located with RRAS in small deployments, but separate is recommended)
  • An Active Directory Certificate Services (AD CS) infrastructure issuing machine and user certificates
  • An Active Directory domain with user accounts and security groups for VPN access
  • Microsoft Intune (or SCCM/ConfigMgr) for profile deployment to managed devices
  • A public IP address or FQDN resolving to the VPN server’s external interface

Step 1 — Install RRAS on the VPN Server

The VPN server requires the Remote Access server role with the DirectAccess-VPN sub-feature (this is the AOVPN component — the name is historical).

# Install on the VPN server
Install-WindowsFeature -Name DirectAccess-VPN, Routing -IncludeManagementTools

# Verify installation
Get-WindowsFeature -Name DirectAccess-VPN, Routing | Select-Object Name, InstallState

Configure RRAS for VPN-only mode using PowerShell. Do not use the GUI wizard if you want reproducible configuration:

# Initialize RRAS for VPN (not DirectAccess)
Install-RemoteAccess -VpnType Vpn

# Verify RRAS service state
Get-RemoteAccess | Select-Object VpnStatus, RoutingStatus

Step 2 — Configure IKEv2 Protocol Settings on RRAS

AOVPN Device Tunnel requires IKEv2. Configure RRAS to use machine certificates for IKEv2 authentication and set appropriate security parameters for Windows Server 2025.

# Configure IKEv2 with machine certificate authentication
Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP `
    -TunnelAuthProtocolsAdvertised Certificate

# Set the certificate used by RRAS for IKEv2 (use the thumbprint of your VPN server cert)
$cert = Get-ChildItem -Path Cert:LocalMachineMy |
    Where-Object { $_.Subject -like "*vpn.contoso.com*" } |
    Select-Object -First 1

Set-RemoteAccessIKEv2 -CertificateIssuedTo $cert.Subject

# Configure RRAS authentication
Set-VpnAuthProtocol `
    -RootCertificateNameToAccept $cert `
    -TunnelAuthProtocolsAdvertised Certificate

Ensure the Windows Firewall allows IKEv2 traffic through the external interface:

# Allow IKEv2 (UDP 500, 4500)
New-NetFirewallRule -DisplayName "Allow IKEv2 VPN" -Direction Inbound `
    -Protocol UDP -LocalPort 500, 4500 -Action Allow

# Allow SSTP (TCP 443) — used as fallback when UDP is blocked
New-NetFirewallRule -DisplayName "Allow SSTP VPN" -Direction Inbound `
    -Protocol TCP -LocalPort 443 -Action Allow

Step 3 — Install and Configure NPS as RADIUS Server

NPS acts as the RADIUS server, receiving authentication requests from RRAS and validating them against Active Directory. Install NPS on a dedicated server or the same server as RRAS.

# Install NPS on the NPS server
Install-WindowsFeature -Name NPAS -IncludeManagementTools

# Register NPS in Active Directory (required to read user dial-in properties)
netsh nps add registeredserver domain=contoso.com server=NPS-SERVER01

Configure RRAS to use the NPS server as its RADIUS server:

# On the RRAS server, configure RADIUS authentication
Add-RemoteAccessRadius `
    -ServerName NPS-SERVER01 `
    -SharedSecret "Str0ngSharedSecret!" `
    -Purpose Authentication `
    -Port 1812

Add-RemoteAccessRadius `
    -ServerName NPS-SERVER01 `
    -SharedSecret "Str0ngSharedSecret!" `
    -Purpose Accounting `
    -Port 1813

On the NPS server, add the RRAS server as a RADIUS client and create a Network Policy for VPN authentication:

# Add RRAS server as a RADIUS client on NPS
New-NpsRadiusClient `
    -Name "RRAS-VPN-Server" `
    -Address "10.10.1.10" `
    -SharedSecret "Str0ngSharedSecret!"

# Create a Connection Request Policy (routes requests to NPS locally)
# This is typically configured in the NPS MMC or via netsh nps commands
# Export/import NPS config for repeatability
Export-NpsConfiguration -Path C:NPSBackupnps-config.xml

In the NPS console, create a Network Policy with these conditions to restrict VPN access to a specific AD security group:

  • Condition: Windows Groups — select your VPN users group (e.g., CONTOSOVPN-Users)
  • Authentication method: Microsoft: Smart Card or other certificate (for certificate-based auth) or PEAP-MSCHAPv2 (for credential-based auth)
  • Grant access: selected

Step 4 — Certificate Requirements

AOVPN depends heavily on certificates issued from a trusted enterprise CA. The requirements differ between Device Tunnel and User Tunnel.

Device Tunnel (Machine Certificate)

  • Issued to the computer account (subject: CN=HOSTNAME.contoso.com)
  • Stored in LocalMachineMy certificate store
  • Must include the Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2)
  • Issued by the same CA that the VPN server trusts for IKEv2
  • Auto-enrolled via Group Policy: Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Automatic Certificate Request

User Tunnel (User Certificate)

  • Issued to the user account (subject: [email protected])
  • Stored in CurrentUserMy certificate store
  • Must include the Client Authentication EKU
  • Auto-enrolled via Group Policy: User Configuration → Windows Settings → Security Settings → Public Key Policies → Automatic Certificate Request Settings

VPN Server Certificate

  • Must be issued by a CA trusted by all client devices (typically an internal Enterprise CA whose root is deployed via Group Policy)
  • Subject Alternative Name must match the FQDN clients use to connect (e.g., vpn.contoso.com)
  • Must include the Server Authentication EKU
# Verify the VPN server certificate is correct
Get-ChildItem -Path Cert:LocalMachineMy |
    Where-Object { $_.HasPrivateKey -and $_.Subject -like "*vpn.contoso.com*" } |
    Select-Object Subject, Thumbprint, NotAfter,
        @{N="EKUs";E={$_.EnhancedKeyUsageList.FriendlyName -join ", "}}

Step 5 — Deploy VPN Profiles via Intune

AOVPN profiles are XML documents conforming to the VPNv2 CSP (Configuration Service Provider) schema. They are deployed via Intune as Custom OMA-URI configuration profiles.

Below is a minimal User Tunnel profile XML. Save this as UserTunnel.xml:

<VPNProfile>
  <AlwaysOn>true</AlwaysOn>
  <TrustedNetworkDetection>contoso.com</TrustedNetworkDetection>
  <NativeProfile>
    <Servers>vpn.contoso.com</Servers>
    <NativeProtocolType>IKEv2</NativeProtocolType>
    <Authentication>
      <UserMethod>Eap</UserMethod>
      <Eap>
        <Configuration>
          <!-- EAP-TLS or PEAP-MSCHAPv2 XML block goes here -->
        </Configuration>
      </Eap>
    </Authentication>
    <RoutingPolicyType>SplitTunnel</RoutingPolicyType>
  </NativeProfile>
  <Route>
    <Address>10.10.0.0</Address>
    <PrefixSize>16</PrefixSize>
  </Route>
  <DnsSuffix>contoso.com</DnsSuffix>
</VPNProfile>

In Intune, create a Device Configuration Profile:

  • Platform: Windows 10 and later
  • Profile type: Templates → Custom
  • OMA-URI: ./User/Vendor/MSFT/VPNv2/ContosoUserTunnel/ProfileXML
  • Data type: String (XML)
  • Value: paste the XML content

For a Device Tunnel (connects before login), the OMA-URI path changes to ./Device/Vendor/MSFT/VPNv2/ContosoDeviceTunnel/ProfileXML and the profile XML must include <DeviceTunnel>true</DeviceTunnel>. Device Tunnel requires IKEv2 with machine certificate authentication only — EAP is not supported for Device Tunnel.

Conclusion

Always On VPN on Windows Server 2025 provides a modern, flexible, and MDM-integrated replacement for DirectAccess that works across heterogeneous network environments without IPv6 dependencies. By combining RRAS for VPN termination, NPS for RADIUS-based authentication with AD group enforcement, a correctly configured PKI for machine and user certificates, and Intune for scalable XML profile deployment, you build a transparent VPN experience where managed devices automatically connect without user interaction. The Device Tunnel and User Tunnel architecture ensures that machines receive Group Policy and remote management connectivity even before a user logs in, while the User Tunnel carries user application traffic with full authentication. Invest time in getting the certificate chain correct — it is the most common source of AOVPN deployment failures and the foundation everything else depends on.