Implement Always-On VPN With Conditional Access

Implementing a robust Always-On VPN (AOVPN) solution combined with Azure Active Directory (Azure AD) Conditional Access provides a critical layer of…

Implementing a robust Always-On VPN (AOVPN) solution combined with Azure Active Directory (Azure AD) Conditional Access provides a critical layer of security and seamless connectivity for modern workforces. This architecture ensures that corporate resources are accessed only by authenticated users on compliant devices, enforcing a zero-trust security model. This guide details the configuration steps for both the AOVPN infrastructure and the integration with Azure AD Conditional Access.

The core of this solution involves two distinct VPN tunnels: a device tunnel for pre-logon connectivity and machine policy application, and a user tunnel for authenticated user access to internal resources. Authentication for the device tunnel typically relies on computer certificates, while the user tunnel leverages user credentials, often integrated with Azure AD for multi-factor authentication (MFA).

Always-On VPN Infrastructure Components

Successful AOVPN deployment requires several key infrastructure components. These include:

  • Windows Server 2016 or newer: Running the Remote Access role (DirectAccess and VPN). This server acts as the VPN gateway.
  • Network Policy Server (NPS): For RADIUS authentication and authorization. It integrates with Active Directory for user and computer account validation.
  • Active Directory Certificate Services (AD CS): To issue and manage computer and user certificates required for IKEv2 authentication.
  • Internal DNS Servers: To resolve internal resource names when connected via VPN.
  • Firewall/Network Security Group (NSG) Configuration: Proper port forwarding and access rules are essential.
    • UDP 500 (IKEv2): For initial key exchange.
    • UDP 4500 (IPsec NAT Traversal): If the VPN server is behind a NAT device.
  • Public IP Address and DNS Record: For the VPN server, resolvable externally.

Configuring the Remote Access Server for AOVPN

On your Windows Server, install the Remote Access role. After installation, configure it specifically for AOVPN.

1. Install Remote Access Role

Install-WindowsFeature -Name RemoteAccess -IncludeManagementTools

2. Configure VPN for IKEv2

Open the Routing and Remote Access console (rrasmgmt.msc). Right-click your server and select "Configure and Enable Routing and Remote Access". Choose "Custom configuration" and select "VPN access".

After enabling, right-click "Ports" under "Network Interfaces" and configure for IKEv2. Ensure that "IKEv2" is enabled and other protocols (PPTP, L2TP) are disabled or prioritized lower for enhanced security.

For IP address assignment, configure a static IP address pool or integrate with DHCP. A dedicated static pool is often preferred for management simplicity in AOVPN.

# Example: Configure a static IPv4 address pool for VPN clients
Set-VpnServerIPAddressAssignment -IPAddressRange "10.10.10.100-10.10.10.200" -RoutingDomainName "Default"

# Configure authentication method to use certificates
Set-VpnServerConfiguration -AuthenticationMethod Certificate

Ensure the VPN server has a valid server authentication certificate (with EKU Server Authentication) issued by your internal CA. This certificate's common name (CN) should match the external FQDN of your VPN server.

3. NPS Configuration for RADIUS

NPS is critical for authenticating both device and user tunnels against Active Directory. Install the Network Policy Server role on a domain-joined server, ideally a dedicated one or the VPN server itself for smaller deployments.

  1. Register the NPS server in Active Directory.
  2. Configure the VPN server as a RADIUS client in NPS:
    • Friendly name: VPN_Gateway
    • Address: IP address of your VPN server
    • Shared secret: A strong, complex string.
  3. Create a new "Network Policy" in NPS:
    • Policy Name: AlwaysOn VPN Devices
    • Type of network access server: Remote Access Server (VPN-Dial up)
    • Conditions:
      • Windows Groups: YourDomain\VPN-Devices (a security group containing computer objects)
      • NAS Port Type: VPN
      • Authentication Method: Microsoft: Smart Card or other certificate (for device tunnel)
    • Constraints: Allow clients to connect without negotiating a stronger authentication method (ensure "MS-CHAPv2", "EAP" are checked for user tunnel policies, but primarily certificate for device tunnel).
    • Settings: Access Granted
  4. Create another Network Policy for user access:
    • Policy Name: AlwaysOn VPN Users
    • Conditions:
      • Windows Groups: YourDomain\VPN-Users (a security group containing user objects)
      • NAS Port Type: VPN
      • Authentication Method: Microsoft: Secured password (EAP-MSCHAPv2) or Microsoft: Smart Card or other certificate if user certificates are used.
    • Constraints and Settings similar to the device policy.

Ensure that the order of these policies is correct, typically device policies before user policies if both use certificates or if there's overlap in conditions.

Certificate Services Configuration

For IKEv2 authentication, both the VPN server and client machines/users need certificates. Implement an Enterprise Certificate Authority (CA) if you don't have one.

  • VPN Server Certificate: A Server Authentication certificate with the EKU "Server Authentication" (OID 1.3.6.1.5.5.7.3.1). The Subject CN must match the external FQDN clients use to connect.
  • Client Computer Certificate: An Authentication certificate with the EKU "Client Authentication" (OID 1.3.6.1.5.5.7.3.2). Auto-enroll this certificate to all client machines that will use the device tunnel via Group Policy.
  • Client User Certificate (Optional): If you choose certificate-based user authentication, deploy user authentication certificates. Otherwise, EAP-MSCHAPv2 with username/password is common.

Ensure that client machines trust the issuing CA (the CA certificate is in their Trusted Root Certification Authorities store).

Client Configuration (VPN Profiles)

Client configuration is typically pushed via Microsoft Intune (recommended) or Group Policy.

Device Tunnel Profile

This tunnel establishes connectivity before a user logs on, allowing Group Policy processing, script execution, and pre-logon application updates.

# Example PowerShell to generate the XML profile for device tunnel (simplified)
# Use New-VpnConnection -AllUserConnection for device tunnel
$VPNProfileName = "AOVPN Device Tunnel"
$VPNSERVER = "vpn.yourdomain.com" # External FQDN of your VPN server

# This is a highly simplified example for illustration.
# In a real-world scenario, you'd use a more robust XML configuration,
# often generated by Intune or a script that includes
# EKU for computer cert, CustomConfiguration etc.

# Basic PowerShell for a device tunnel (AllUserConnection)
# New-VpnConnection -Name $VPNProfileName `
#                   -ServerAddress $VPNSERVER `
#                   -TunnelType IKEv2 `
#                   -AuthenticationMethod MachineCertificate `
#                   -AllUserConnection `
#                   -SplitTunneling ` # Consider if all traffic needs to go over VPN
#                   -RememberCredential ` # Not applicable for MachineCertificate
#                   -CimSession $null # For local execution

# Full XML Profile is preferred for GPO/Intune deployment
# The XML structure should be like below.
# The `AlwaysOn` node is critical for AOVPN functionality.

$ProfileXML = @"
<VPNProfile>
  <ProfileName>$VPNProfileName</ProfileName>
  <AppInfo>Automatic</AppInfo>
  <DnsSuffix>yourdomain.com</DnsSuffix>
  <NativeProfile>
    <Servers>$VPNSERVER</Servers>
    <NativeProtocolType>IKEv2</NativeProtocolType&    >
    <Authentication>
      <MachineCertificate>
        <EapConfiguration>
          <EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
            <EapMethod>
              <Type xmlns="http://www.microsoft.com/provisioning/EapCommon">13</Type>
              <VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId>
              <VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType>
              <AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId>
            </EapMethod>
            <Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
              <Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">
                <Type>13</Type>
                <EapType xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1">
                  <CredentialsSource>
                    <CertificateStore>
                      <Smartcard>false</Smartcard>
                      <CertificateIssuerName>CN=Your Internal CA,DC=yourdomain,DC=com</CertificateIssuerName>
                      <CertificatePurpose>ClientAuthentication</CertificatePurpose>
                    </CertificateStore>
                  </CredentialsSource>
                  <ServerValidation>
                    <DisableUserPromptForServerValidation>true</DisableUserPromptForServerValidation>
                    <ServerRootCAToValidate>CN=Your Internal CA,DC=yourdomain,DC=com</ServerRootCAToValidate>
                    <ServerNames>$VPNSERVER</ServerNames>
                  </ServerValidation>
                  <DifferentUsername>false</DifferentUsername>
                  <PerformServerValidation>true</PerformServerValidation>
                </EapType>
              </Eap>
            </Config>
          </EapHostConfig>
        </EapConfiguration>
      </MachineCertificate>
    </Authentication>
  </NativeProfile>
  <AlwaysOn>true</AlwaysOn>
  <RememberCredentials>false</RememberCredentials>
  <TrustedNetworkDetection>
    <TrustedNetworkServers>yourdomain.com</TrustedNetworkServers>
  </TrustedNetworkDetection>
  <DnsConfig>
    <EnableAlwaysOn>true</EnableAlwaysOn>
    <DnsSearchSuffixes>yourdomain.com</DnsSearchSuffixes>
    <DnsServers>10.0.0.1,10.0.0.2</DnsServers> # Your internal DNS servers
  </DnsConfig>
</VPNProfile>
"@
# Save this XML and deploy via Intune Custom URI (OMA-URI: ./Vendor/MSFT/VPNv2/<ProfileName>/ProfileXML) or GPO.

The <AlwaysOn>true</AlwaysOn> tag is essential. The TrustedNetworkDetection element tells the client not to connect the VPN when it detects one of the specified servers (e.g., domain controllers) or DNS suffixes, indicating it's on the corporate network.

User Tunnel Profile

The user tunnel connects after a user logs on, providing access to internal resources based on user identity. It uses EAP-MSCHAPv2 for authentication against NPS, which in turn queries Active Directory.

# Example of a simplified user tunnel XML profile structure (similar to device, but different authentication and no AllUserConnection)
# This would use UserCredential or Certificate (if user certs are used)

$UserVPNProfileName = "AOVPN User Tunnel"
$UserProfileXML = @"
<VPNProfile>
  <ProfileName>$UserVPNProfileName</ProfileName>
  <AppInfo>Automatic</AppInfo>
  <DnsSuffix>yourdomain.com</DnsSuffix>
  <NativeProfile>
    <Servers>$VPNSERVER</Servers>
    <NativeProtocolType>IKEv2</NativeProtocolType>
    <Authentication>
      <UserMethod>Eap</UserMethod>
      <EapConfiguration>
        <!-- EAP-MSCHAPv2 configuration -->
      </EapConfiguration>
    </Authentication>
  </NativeProfile>
  <AlwaysOn>true</AlwaysOn>
  <RememberCredentials>true</RememberCredentials>
  <TrustedNetworkDetection>
    <TrustedNetworkServers>yourdomain.com</TrustedNetworkServers>
  </TrustedNetworkDetection>
  <DnsConfig>
    <EnableAlwaysOn>true</EnableAlwaysOn>
    <DnsSearchSuffixes>yourdomain.com</DnsSearchSuffixes>
    <DnsServers>10.0.0.1,10.0.0.2</DnsServers>
  </DnsConfig>
</VPNProfile>
"@
# Deploy this XML for user context.

For deployment, Intune's "VPN" profile type (Windows 10 and later) simplifies this considerably, offering GUI-based configuration for both device and user tunnels, including certificate selection and EAP settings.

Conditional Access Integration

Azure AD Conditional Access (CA) enhances AOVPN by enforcing device compliance and MFA for access to sensitive cloud applications, even after the user is authenticated via VPN. This requires Azure AD Join or Hybrid Azure AD Join for client machines and Intune for device compliance policies.

1. Device Enrollment and Compliance

  • Hybrid Azure AD Join: Clients are joined to both on-premises AD and Azure AD. This is common for existing AD environments. Configure Hybrid Azure AD Join via GPO for domain-joined devices.
  • Intune Enrollment: Devices must be enrolled in Intune (either via GPO for Hybrid Join or directly for Azure AD Join) to receive compliance policies.
  • Compliance Policies: In Intune, create device compliance policies (e.g., require OS patch level, BitLocker, antivirus, no jailbreaking). Mark devices as "Compliant" or "Non-compliant".

2. Conditional Access Policy Configuration in Azure AD

Create a CA policy to require compliant devices for accessing specific applications.

  1. Navigate to Azure AD Admin Center > Azure Active Directory > Security > Conditional Access.
  2. Create a new policy:
    • Name: Require Compliant Device for Sensitive Apps
    • Users or workload identities: Select specific users/groups or "All users" (with exclusions).
    • Cloud apps or actions:
      • Select "All cloud apps" or specific sensitive applications (e.g., SharePoint Online, specific SaaS apps).
      • Crucially, for on-premises resources accessed via AOVPN, this CA policy applies to the cloud authentication involved in accessing the application, not the VPN tunnel itself. For example, if a user accesses an on-premises SharePoint site that uses Azure AD Application Proxy or federated authentication (e.g., ADFS), this policy can apply.
    • Conditions: (Optional, e.g., Device platforms: Windows, Locations: Any location).
    • Grant: Select "Grant access" and check "Require device to be marked as compliant". You may also add "Require MFA" for an additional layer.
    • Session: (Optional, e.g., Sign-in frequency, Persistent browser session).
    • Enable policy: On (or Report-only for testing).

When a user attempts to access a cloud application protected by this CA policy, Azure AD evaluates their device's compliance status (reported by Intune). If the device is non-compliant, access is blocked, even if the user is connected via AOVPN.

Common Pitfalls and Troubleshooting

  • Certificate Issues: The most common source of AOVPN problems.
    • Ensure VPN server certificate's CN matches the FQDN clients connect to.
    • Verify client computer/user certificates have the correct EKU and are trusted by the VPN server's root CA.
    • Check certificate expiration dates.
    • Use certutil -verify -urlfetch <certificate_file> to check certificate chain and CRL distribution points.
  • NPS Policy Order: Policies are processed top-down. If a less restrictive policy is above a more restrictive one, unintended access may occur.
  • Firewall Rules: Incorrect NAT, port forwarding, or internal firewall rules blocking UDP 500/4500 can prevent connections. Use Test-NetConnection -Port 500 -ComputerName vpn.yourdomain.com from a client.
  • DNS Resolution: Ensure internal DNS servers are correctly configured in the VPN profile and that they resolve internal resources when connected.
  • Always-On Feature: Verify the <AlwaysOn>true</AlwaysOn> flag is set in client VPN profiles.
  • Client VPN Profile Updates: When making changes to VPN profiles (especially XML-based), push updates incrementally to a small pilot group. Faulty profiles can disable remote connectivity.
  • Conditional Access Evaluation: For on-premises apps, CA applies if the app leverages Azure AD for authentication (e.g., via App Proxy or ADFS). If it's pure Kerberos/NTLM over VPN, CA won't directly enforce device compliance for that specific resource access, though the user might still need a compliant device for their Azure AD login session.
  • Event Logs: Always check the "RemoteAccess-Server" and "System" event logs on the VPN server, and "Applications and Services Logs > Microsoft > Windows > VPN Client" on client machines for detailed connection failures.

Back to the knowledge base · Ask the AI assistant