Always On VPN Ask Me Anything (AMA) March 2024

Do you have questions about Always On VPN? Are you having a specific issue you can’t figure out? Would you like more information about configuration options? Here’s your chance to get your questions answered! Join me on Tuesday, March 26, at 10:00 AM PDT (UTC -7) for an opportunity to ask me anything (AMA!) about Microsoft Windows Always On VPN and related technologies.

The AMA will be an open forum session where we can all talk shop about Always On VPN. It’s a great chance to learn new things and share experiences with your peers. We’ll discuss known issues and limitations, best practices, and more.

Everyone is welcome. Don’t miss out on this excellent opportunity to connect and learn. Register now!

Can’t make the session? Register anyway, and I’ll send you the link to the recording as soon as it is available!

Always On VPN and IPv6

Internet Protocol version 6 (IPv6) has been with us for nearly 30 years. IPv6 adoption on the public Internet has steadily increased over the last decade, and today is approaching 50%. However, enterprise adoption of IPv6 has been surprisingly sluggish despite its numerous benefits. IPv6 includes an expanded address space that removes complex subnetting requirements and globally unique addressing that eliminates the need to perform Network Address Translation (NAT), among others. Organizations should consider deploying IPv6 internally to take advantage of these capabilities.

IPv6 and RRAS

I’ve deployed Microsoft Always On VPN for customers using IPv6 numerous times. The following describes configuration settings required to support IPv6 in a Microsoft environment using a Windows Server Routing and Remote Access (RRAS) server.

To begin, open the Routing and Remote Access management console (rrasmgmt.msc) on the RRAS VPN server, then follow the steps below to enable IPv6 support for Always On VPN connections.

Note: The configuration below assumes that IPv6 is already deployed on the internal network, either natively or dual-stacked with IPv4.

IPv6 Remote Access

Perform the following steps to enable IPv6 remote access on the RRAS VPN server.

  1. Right-click the RRAS VPN server in the navigation tree and choose Properties.
  2. Check the box next to the IPv6 Remote access server on the General tab.

Prefix Assignment

Next, an IPv6 prefix must be assigned to each RRAS VPN server. This IPv6 prefix must be unique for each server and not in use anywhere else on the internal network. Unlike IPv4, IPv6 addresses cannot be assigned from the same prefix (subnet) as the VPN server’s internal network interface. With that, ensure that internal network IPv6 routing returns traffic for the assigned IPv6 prefixes to the corresponding VPN server.

Perform the following steps to assign an IPv6 prefix for VPN client use.

  1. Right-click the RRAS VPN server in the navigation tree and choose Properties.
  2. Select the IPv6 tab.
  3. Check the box next to Enable IPv6 Forwarding.
  4. If force tunneling is required (not recommended), check the box next to Enable Default Route Advertisement.
  5. Enter an IPv6 prefix in the IPv6 prefix assignment field. Again, ensure the IPv6 prefix is globally unique, and that internal network routing is configured to return traffic to the VPN server that owns the prefix.
  6. If your RRAS server is multi-homed, select the internal network interface from the Adapter drop-down list.

DHCP

Organizations with IPv6 deployed internally may use Microsoft Windows DHCPv6 or a dedicated DNS/DHCP/IP Address Management (IPAM) (DDI) solution like Infoblox. However, Windows Server RRAS does not support DHCPv6 for VPN client IP address assignment. Administrators must manually assign an IPv6 prefix per server. However, administrators can use DHCP alongside IPv6 prefix assignment for VPN client IPv4 addressing.

Limitations

While IPv6 may solve some problems for Always On VPN administrators, it has some limitations. Here are some crucial considerations for IPv6 and Always On VPN at the time of this writing.

Traffic Filters

You cannot use IPv6 when configuring traffic filters for Always On VPN. Specifying IPv6 elements in a traffic filter rule will prevent Always On VPN from working at all. More details here.

Intune and Routing

When split tunneling is enabled, Microsoft Intune will not accept IPv6 routes using the standard IPv6 subnet prefix of /64. The UI complains that “the value must be between 1 and 32”.

You can use the custom XML deployment option to configure Always On VPN to support split tunneling correctly as a workaround.

Additional Information

Overview of IPv6

Everything You Never Knew about NAT

Disabling IPv6 Breaks Windows Server RRAS

Microsoft Always On VPN Traffic Filters and IPv6

Discussing Microsoft and IPv6 on the IPv6 Buzz Podcast (Packet Pushers)

When Always On VPN Isn’t

Microsoft Always On VPN is a beautiful thing. VPN profiles are assigned to the user (and, optionally, their device). When users power up their device and log on, they are automatically connected to the corporate network and can access all the applications and data they need on-premises. Until recently, though, end users could disconnect the VPN. Why they would do this is beyond comprehension, but sadly, it happens all too often. When it does, it presents a problem for Always On VPN administrators because they must now rely on the user to re-enable this feature. And until they do, they often suffer productivity loss, and their devices may fall out of compliance.

Connect Automatically

When an Always On VPN profile is provisioned to a user (or a device), the VPN profile has the option to ‘Connect automatically’ enabled by default. Unfortunately, this setting is cleared if a user terminates the VPN.

This setting will remain cleared until the user rechecks the box to enable it. Until then, the VPN will no longer connect automatically.

Workarounds

Instead of relying on the grace of the end user to restore Always On functionality, administrators have a few options to correct this problem programmatically.

Intune Remediation

Administrators can use Intune Remediations to deploy a set of detection and remediation scripts I’ve published to update this setting. Now, administrators can enforce ‘Always On’ VPN connections with the assurance that if the user turns off this feature, it will be quickly re-enabled.

Detect-AutoTriggerDisabledProfile.ps1

Remediate-AutoTriggerDisabledProfile.ps1

SCCM

You can find a standalone version of this script here if you use System Center Configuration Manager (SCCM) or another systems management solution to manage your endpoints.

Clear-AutoTriggerDisabledProfile.ps1

AovpnTools

In addition, you will find the Clear-AutoTriggerDisabledProfile function is included in my AOVPNTools PowerShell module, which can be installed from the PowerShell gallery.

Install-Module -Name AOVPNTools -Force

Disable Disconnect Button

To avoid this pain in the future, Always On VPN administrators can prevent users from disconnecting the VPN using the UI by leveraging the DisableDisconnectButton option in ProfileXML. This setting is supported for both user and device tunnels on Windows 11 and later devices.

Additional Information

AOVPNTools PowerShell Module

AOVPNTools PowerShell Module on GitHub

Always On VPN and Intune Remediations