Always On VPN Servers and Failover

When configuring Microsoft Always On VPN, one of the first and most crucial settings is defining the public hostname of the VPN server to which clients connect. If you’re deploying Always On VPN client configuration settings using Intune—either with the native VPN policy template or a custom XML profile—you’ll see that multiple server entries are supported. Intune even allows administrators to define a “default server.” At first glance, this might suggest that the client will try the default server first and automatically fail over to the others if it’s unavailable. Unfortunately, that’s not how it works.

Intune VPN Template

When using the native Intune VPN device configuration template, administrators will find multiple entry fields for the servers in the Base VPN section.

In the example below, the Global VPN entry is marked as ‘default’.

Custom XML

When defining VPN settings using XML configuration, administrators can also list multiple servers.

Interestingly, the VPNv2 CSP used by custom XML profiles doesn’t support the concept of a “default server” at all.

How It Really Works

Defining multiple servers in the Always On VPN profile does not enable automatic failover. The client connects only to the first server in the list. The so-called “default server” setting in Intune is ignored, and the GUI even allows you to mark all servers as default, which is meaningless.

However, the configuration isn’t entirely useless. If you define multiple servers, they’ll appear on the client side as manual options. If the first server becomes unavailable, the user can open the Settings app, navigate to the advanced settings of the Always On VPN profile, and select an alternate server to connect manually.

Summary

Although Intune and XML configurations allow multiple VPN servers, Always On VPN does not provide automatic failover. Clients only attempt to connect to the first server in the list, and the “default server” setting in Intune has no effect. Multiple entries are still useful, but only for manual server selection by end-users when the primary server is down. For true automated high availability and redundancy, consider an external solution such as Azure Traffic Manager.

Additional Information

Always On VPN Multisite with Azure Traffic Manager

Always On VPN DPC 5.2.0 Now Available

I’m pleased to announce that Always On VPN Dynamic Profile Configurator (DPC) version 5.2.0 is now available. My good friend Leo D’Arcy has been hard at work for the last few months squashing some bugs and adding a few new features to DPC. If you are running a previous release of Always On VPN DPC, either open source or commercial, it’s time to upgrade.

Important!! DPC 5.2.0 has a bug that prevents the service from stopping. This has been addressed in DPC 5.2.1. Guidance for upgrading from DPC 5.2.0 to 5.2.1 can be found here.

Reminder: We’re on Discord. Join the conversation today!

What’s New in DPC 5.2.0

Always On VPN DPC 5.2.0 has some compelling new features.

  • Exclude Routes from DNS – DPC has a feature that allows administrators to add routes to the routing table using DNS. When this setting is enabled, DPC will attempt to resolve the specified hostname to an IP address and add it to the VPN’s routing table when creating the profile. With 5.2.0, this capability has been extended to exclusion routes, allowing administrators to exclude resources by host name.
  • Write Event Logs to Disk – This setting allows administrators to optionally write DPC event information to a text file in addition to logging them in the event log. Writing event log information to a text file on disk can make troubleshooting easier in some scenarios.
  • Delay Profile Updates – This new feature ensures reliable VPN profile creation after group policy updates take place.

Bug Fixes

In addition to new capabilities, Always On VPN DPC 5.2.0 includes fixes for many outstanding issues.

  • DPC name resolution issue where duplicate IP addresses are returned, resulting in failed route additions when using ‘Allow Routes from DNS’.
  • Missing events in the DPC operational event log.
  • Enabling ‘Disable Disconnect Button’ or ‘Disable Advanced Edit Button’ settings results in a profile mismatch warning.
  • Added resiliency to DPC name resolution when one or more name resolution requests fail.

Group Policy Template

As a reminder, any time there are new features in DPC, there will be corresponding changes to Group Policy administrative template and template language files. Be sure to update your ADMX and ADML files in the group policy central store to take advantage of these new capabilities in DPC 5.2.0.

Recommendation

If you are running any release of Always On VPN DPC, commercial or open source, consider upgrading now to gain access to new features and operational reliability improvements. You can find DPC v5.2.0 on GitHub here.

Additional Information

Always On VPN DPC v5.2.0 Available Now

Always On VPN Dynamic Profile Configurator (DPC)

Always On VPN DPC Now Open Source

Migrating from Always On VPN DPC Commercial to Open Source

Always On VPN DPC with Microsoft Intune

Microsoft Always On VPN on Discord

Always On VPN DPC

Always On VPN and Entra Conditional Access

Microsoft recently introduced Entra Private Access, an identity-centric Zero Trust Network Access (ZTNA) solution to provide secure remote access to on-premises resources. With Entra Private Access, administrators can leverage Entra Conditional Access to enforce policy-based access control for network access. However, Entra Private Access isn’t for everyone. It does not provide full feature parity with Always On VPN, and there are also licensing considerations. However, for those organizations using Always On VPN, the good news is that you can integrate Entra Conditional Access with Always On VPN today to gain some of the security benefits it provides.

Conditional Access

Microsoft Entra Conditional Access is a security feature that enables administrators to create and enforce policies that specify how users can access resources. In the specific case of Always On VPN, conditional access is critical to ensuring legitimate access to authenticated users on authorized devices.

Signals

Conditional access policies use a wide variety of signals for policy enforcement, such as:

  • User Identity: Who is making this access request?
  • User Properties: Is this user a member of a specific group?
  • Location: Where is this access request originating?
  • Device Management: Is this device joined to Entra ID?
  • Device State: Is this device compliant with security policies?
  • Device Platform: Is this a Windows device?
  • Risk Level: Is this login considered risky?

Access Control

Based on these signals, administrators can design a conditional access policy to enforce granular access control, such as:

  • Grant access only from managed devices
  • Deny access from untrusted locations
  • Require additional context-based authentication (e.g., multifactor authentication)
  • Enforce specific authentication types (e.g., phishing-resistant credentials)
  • Allow access only from specific device platforms (e.g., Windows only)
  • Require Entra hybrid-joined device
  • Block access when a device is not compliant with security policies

Always On VPN

Entra Conditional Access works with Always On VPN by issuing a special, short-lived user authentication certificate once the user has been authorized. The Always On VPN infrastructure can be configured to use this certificate to grant access to the VPN. Integrating conditional access with Always On VPN can significantly improve the security posture of organizations using this feature.

Deployment Guide

I’ve published a detailed, step-by-step deployment guide to configure Entra conditional access for Always On VPN. In addition, I have posted a demonstration video for enabling Entra conditional access with Aways On VPN on YouTube.

Additional Information

Microsoft Entra Conditional Access Overview

Configure Entra Conditional Access for Always On VPN