Windows Always On VPN (AOVPN) Deployment Guide: How to Replace Traditional VPN with a Modern Remote Access Architecture

Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Always On VPN was designed to address the core operational failure of traditional VPN deployments: users do not connect when they should, leave the VPN disconnected for convenience, and IT cannot enforce policy on devices that are off the corporate network. Device Tunnel solves the pre-logon connectivity requirement (Group Policy, DC communication) while User Tunnel handles authenticated user traffic. This guide covers the deployment components -- RRAS server, certificate infrastructure, and ProfileXML -- and the design decision between full tunnel and split tunnel.
Architecture: Device Tunnel vs User Tunnel
Device Tunnel:
- Connects: Before user logon, using the machine certificate
- Authentication: Machine certificate (no user credentials needed)
- Use cases: Group Policy refresh before logon, SCCM client communication, BitLocker network unlock, domain join from remote location
- Configuration: Requires Windows 10 Enterprise/Education or Windows 11, run as a VPN connection for the SYSTEM account
- Traffic: Typically restricted to specific DC, SCCM, and DNS server IPs (not full tunnel) -- keep Device Tunnel narrow
User Tunnel:
- Connects: After the user signs in, using the user certificate or user credentials
- Authentication: User certificate (EAP-TLS) or username/password (PEAP-MSCHAPv2)
- Use cases: All user traffic to corporate resources, file servers, intranet sites, corporate applications
- Configuration: Standard VPN profile deployed via Intune to the user
- Traffic: Can be full tunnel (all traffic through VPN) or split tunnel (only corporate traffic)
Design recommendation:
- Use Device Tunnel in restricted split-tunnel mode (routes only to DCs, SCCM servers, DNS)
- Use User Tunnel with certificate authentication (EAP-TLS with user certificate)
- Split-tunnel User Tunnel for performance: route only corporate subnets through VPN, allow internet traffic direct
- Enable traffic filters on the Device Tunnel to limit what the pre-logon connection can reach
Server-Side Prerequisites: RRAS Configuration
AOVPN requires a Windows Server with the Remote Access role (RRAS) as the VPN endpoint, and an NPS (Network Policy Server) for authentication.
Install Remote Access on the VPN server:
# Install Remote Access and NPS roles
Install-WindowsFeature DirectAccess-VPN, RRAS -IncludeManagementTools
Install-WindowsFeature NPAS -IncludeManagementTools
# Configure RRAS as a VPN server (not DirectAccess)
Install-RemoteAccess -VpnType VPN
# Configure RRAS to use a static address pool for VPN clients
# Or configure DHCP forwarding
Set-RemoteAccess -IPAddressAssignment StaticPool
Add-VpnIPAddressRange -IPAddressRangeStart '10.100.0.1' -IPAddressRangeEnd '10.100.0.254'
Required certificates on the RRAS server:
- Server Authentication certificate: issued by your internal CA, Subject = the RRAS server FQDN, Enhanced Key Usage = Server Authentication. This is what VPN clients validate when connecting.
- The certificate must be in the LocalMachine\My store on the RRAS server
Bind the certificate to IKEv2:
# Configure RRAS to use the correct certificate for IKEv2
$thumbprint = (Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.Subject -match 'vpn.domain.com' }).Thumbprint
Set-VpnAuthProtocol -RootCertificateNameToAccept $thumbprint -UserAuthProtocolAccepted Certificate, EAP
NPS configuration for EAP-TLS (certificate-based auth):
1. Open NPS > Policies > Connection Request Policies > create new
2. Conditions: Tunnel-Type = IKEv2, NAS-Port-Type = VPN
3. Settings: Authentication > Override network policy > EAP methods > add Microsoft: Smart Card or other certificate
4. Create Network Policy matching VPN connections: Authentication type = EAP-TLS
5. Specify the user/computer certificate CA for authentication
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Deploy the VPN Profile via Intune (ProfileXML)
AOVPN profiles are deployed as XML configuration via Intune or Group Policy. The User Tunnel profile is deployed to the user; the Device Tunnel profile is deployed to the device.
Example User Tunnel ProfileXML:
<VPNProfile>
<NativeProfile>
<Servers>vpn.domain.com</Servers>
<NativeProtocolType>IKEv2</NativeProtocolType>
<Authentication>
<UserMethod>Eap</UserMethod>
<Eap>
<Configuration>
<!-- EAP-TLS configuration referencing user certificate -->
<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
<EapMethod>
<Type xmlns="http://www.microsoft.com/provisioning/EapCommonSchema">13</Type>
<VendorId xmlns="http://www.microsoft.com/provisioning/EapCommonSchema">0</VendorId>
</EapMethod>
</EapHostConfig>
</Configuration>
</Eap>
</Authentication>
<RoutingPolicyType>SplitTunnel</RoutingPolicyType>
<DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>
</NativeProfile>
<Route>
<Address>10.0.0.0</Address>
<PrefixSize>8</PrefixSize>
</Route>
<Route>
<Address>172.16.0.0</Address>
<PrefixSize>12</PrefixSize>
</Route>
<DnsSuffix>domain.com</DnsSuffix>
<TrustedNetworkDetection>domain.com</TrustedNetworkDetection>
<!-- TrustedNetworkDetection: do not connect when on corporate network -->
<AlwaysOn>true</AlwaysOn>
<RememberCredentials>true</RememberCredentials>
<RegisterDNS>true</RegisterDNS>
</VPNProfile>
Deploy via Intune: Intune > Devices > Configuration profiles > Create profile > Windows 10 and later > Templates > VPN
- Connection type: IKEv2
- Or use Custom OMA-URI to deploy raw ProfileXML:
- OMA-URI:
./Device/Vendor/MSFT/VPNv2/<ProfileName>/ProfileXML - Data type: String
- Value: (paste your ProfileXML, properly escaped)
- OMA-URI:
Certificate Infrastructure Requirements
AOVPN requires certificates from an internal CA. Minimum requirements:
For the User Tunnel (user certificate):
- Certificate template: duplicate the built-in 'User' template
- Subject: User Principal Name (UPN) of the authenticating user
- Enhanced Key Usage: Client Authentication
- Auto-enroll: enabled via Group Policy or Intune SCEP profile
For the Device Tunnel (machine certificate):
- Certificate template: duplicate the built-in 'Computer' template
- Subject: DNS name of the machine (FQDN)
- Enhanced Key Usage: Client Authentication
- Auto-enroll: enabled on all devices via Group Policy or Intune SCEP
For the RRAS server (server certificate):
- Subject: FQDN of the VPN server endpoint (what clients connect to)
- Enhanced Key Usage: Server Authentication
- Auto-enroll or manual issuance from internal CA
Configure auto-enrollment via Group Policy:
Computer Configuration > Windows Settings > Security Settings > Public Key Policies
> Certificate Services Client - Auto-Enrollment Settings: Enabled
Renew expired certificates, update pending certificates, remove revoked certificates: Enabled
Update certificates that use certificate templates: Enabled
User Configuration > Windows Settings > Security Settings > Public Key Policies
> Same settings for user certificates
OCSP or CRL for certificate revocation: The RRAS server and NPS must be able to validate whether user/machine certificates have been revoked. Configure either:
- CRL Distribution Point (CDP) accessible from both corporate network and internet (for remote devices to check before connecting)
- OCSP responder (faster, more reliable for remote clients)
If a device is lost or stolen, revoke the machine certificate -- the device cannot establish a Device Tunnel connection once the certificate is revoked.
The bottom line
AOVPN deployment checklist: set up RRAS server with server authentication certificate, configure NPS for EAP-TLS authentication, build the internal CA certificate templates for user and machine certificates with auto-enrollment, deploy the ProfileXML via Intune for User Tunnel, deploy the Device Tunnel profile as a PowerShell script or Intune custom OMA-URI, and configure TrustedNetworkDetection so the VPN does not connect when on corporate Wi-Fi. Test the Device Tunnel by verifying Group Policy applies before logon on a remote device, and test User Tunnel certificate revocation to confirm access is removed immediately when a certificate is revoked.
Frequently asked questions
What is the difference between Always On VPN and DirectAccess?
DirectAccess (Microsoft's previous always-on technology) uses IPv6 over IPv4 tunneling (6to4, Teredo, IP-HTTPS) and IPsec. It requires IPv6 infrastructure, only works with domain-joined Windows Enterprise clients, and has complex troubleshooting due to the IPv6-over-IPv4 transport. Always On VPN uses standard VPN protocols (IKEv2, SSTP), works over IPv4 and IPv6 natively, supports both domain-joined and Azure AD-joined devices, and is easier to troubleshoot with standard network tools. Microsoft has stated that Always On VPN is the successor to DirectAccess. New deployments should use AOVPN; existing DirectAccess deployments should plan migration.
Should I use split-tunnel or full-tunnel for the User Tunnel?
Split-tunnel is typically recommended for user traffic -- route only corporate subnets through the VPN, allow internet traffic to go directly from the client. Full-tunnel routes all traffic through the VPN, adding latency for internet traffic and increasing load on the VPN server. The security concern with split-tunnel is that internet traffic is not inspected by corporate security tools. Mitigate this with cloud-based DNS filtering (Microsoft Entra Internet Access, Zscaler, Umbrella) that applies to all client internet traffic regardless of VPN status. For the Device Tunnel, always use split-tunnel restricted to only the specific server IPs (DCs, SCCM, DNS) that need pre-logon connectivity.
How do I troubleshoot AOVPN connection failures?
Start with the Windows Event Viewer on the client: Applications and Services Logs > Microsoft > Windows > VPN. Event ID 1800 series covers IKEv2 authentication failures; Event ID 20271 covers connection establishment. For certificate issues, check the Authentication log in Event Viewer and verify the certificate is present and valid in the machine certificate store. On the server side, check the RRAS event log and NPS event log for authentication rejections. The most common failures are: certificate revocation check failure (CRL/OCSP not reachable from the client before connecting), certificate subject mismatch (the server certificate CN does not match the VPN server DNS name), or NPS policy misconfiguration (no matching network policy for the VPN connection type).
Can Always On VPN work with Azure AD-joined (non-domain-joined) devices?
User Tunnel works with Azure AD-joined devices using certificate-based authentication. The user certificate can be enrolled via Intune SCEP profile rather than Group Policy auto-enrollment. The Device Tunnel requires domain join because it authenticates using a machine Kerberos ticket or machine certificate issued by an on-premises CA and registered in on-premises AD. Hybrid Azure AD-joined devices (joined to both Azure AD and on-premises AD) support both tunnels. Cloud-only Azure AD-joined devices can use User Tunnel with Intune-managed certificates but cannot use Device Tunnel in its traditional form. For cloud-only environments, consider Microsoft Entra Private Access (the zero trust network access replacement for VPN) rather than AOVPN.
What is the biggest operational difference between Always On VPN and a traditional always-connected VPN client?
Traditional always-connected VPN clients (GlobalProtect, Cisco AnyConnect in pre-logon mode) establish a VPN connection at machine startup and require the corporate network for authentication and policy delivery. AOVPN's Device Tunnel provides the same pre-logon connectivity but integrates natively with Windows via the built-in VPN infrastructure (IKEv2 or SSTP) without a separate vendor client. The operational difference: AOVPN is managed entirely through Intune or Group Policy using standard Windows configuration, while third-party clients require their own management infrastructure and updates. For enterprises already managing devices with Intune, AOVPN eliminates a vendor dependency and reduces the attack surface that comes with a persistent third-party agent running on every endpoint.
What are the certificate requirements for Always On VPN Device Tunnel and User Tunnel?
AOVPN uses certificate-based authentication for both tunnels, with different certificate requirements for each. Device Tunnel: requires a computer certificate issued by your internal CA, enrolled via Intune SCEP or GPO autoenrollment, with the machine's FQDN as the Subject Alternative Name. The NPS server validates the machine certificate against your CA's chain and a network policy that permits device tunnel connections from domain computers. User Tunnel: requires a user certificate for EAP-TLS, or can use username/password (PEAP-MSCHAPv2) if certificate enrollment for users is impractical. EAP-TLS with user certificates provides stronger authentication because it validates both the user's identity and device ownership. Certificate deployment: use Intune SCEP profiles to automatically enroll both computer and user certificates -- the SCEP profile requests certificates from your CA on behalf of the device or user and installs them in the correct certificate store. Ensure your CA's CRL is accessible to the VPN server (RRAS) from its network position, as certificate validation fails if the CRL is unreachable.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.

Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.
