Always On VPN vs. Entra Private Access: Choosing the Right Access Model for Your Organization

The predominant solution for secure remote access today in the Microsoft ecosystem is Always On VPN. Always On VPN is based on traditional Virtual Private Network (VPN) technology originally developed in the mid-1990s. However, Microsoft recently introduced Entra Private Access, which is part of the Global Secure Access (GSA) Security Service Edge (SSE). Entra Private Access is an identity-centric Zero Trust Network Access (ZTNA) solution designed to replace traditional VPN solutions. It offers significantly improved security with granular resource access without dependency on on-premises infrastructure. This article outlines where each solution fits best and how organizations can transition safely between them.

Always On VPN

First introduced in Windows 8, Microsoft Always On VPN provides seamless, transparent, secure remote access using client-based VPN protocols such as Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). When establishing a VPN connection, a virtual network adapter is created, and an IP address is assigned to the interface to facilitate tunneled network communication with the internal network.

Architecture

Always On VPN requires substantial on-premises supporting infrastructure. In addition to the VPN servers themselves, administrators must also deploy authentication servers (RADIUS or NPS) and certificate services (AD CS). Administrators must manage public TLS certificates for SSTP connections. Also, larger deployments may require on-premises load balancers and/or cloud-based Global Server Load Balancing (GSLB) solutions. Further, additional configuration is needed to integrate Entra ID Conditional Access. Because this infrastructure must be publicly accessible by design, it becomes an attractive target for attackers. In addition, the complex infrastructure has many interdependencies, resulting in significant administrative overhead for network and security administrators.

Access Model

Most commonly, Always On VPN provides full network access to the internal network. Full network access is accomplished by configuring IP routing on the client to ensure internal client network subnets are routed over the VPN tunnel. In this model, clients are often implicitly trusted once connected. Once authenticated and authorized, users receive full, unfettered access to the internal network across all protocols and ports. This level of access introduces a significant security risk and does not adhere to modern zero-trust network access models. To address this, administrators must implement additional security controls internally (perimeter or DMZ firewalls) to restrict network access for Always On VPN clients.

Zero Trust Always On VPN?

Always On VPN includes support for traffic filters that can restrict network access and provide zero-trust-like access. However, these controls exist only on the client side, so an attacker with administrative access to the endpoint can easily bypass them. They should not be considered a reliable way to enforce zero trust for Always On VPN connections.

Entra Private Access

Entra Private Access is part of Microsoft’s Global Secure Access (GSA) Security Service Edge (SSE). It is a robust, cloud-based zero-trust network access (ZTNA) service that provides granular access to on-premises resources. It requires installing a client-side agent and one or more Private Network connectors on-premises to facilitate remote network access. Entra Private Access deeply integrates with Entra ID, so you can easily configure Conditional Access policies for any published resource, including multifactor authentication for legacy protocols such as SSH.

Limited Network Access

Unlike legacy VPNs, GSA does not create a virtual network interface when establishing a connection. Instead, GSA operates as a filter driver deep in the Windows networking stack, intercepting and rerouting network traffic bound for the internal network. The GSA client eliminates the complexities of IP address management, network routing, and firewalling. In addition, authentication and authorization are handled natively by Entra ID and Conditional Access.

Minimal Infrastructure

Entra Private Access is a cloud-based service with minimal on-premises supporting infrastructure requirements. Administrators must only deploy the Entra Private Network connector on one or more on-premises servers to facilitate remote access for Global Secure Access clients. The Entra Private Network is a lightweight software agent that requires little to no post-deployment support. The administrative burden is much lighter compared to Always On VPN.

Key Differences at a Glance

The table below highlights the most important architectural, security, and operational differences to help determine which solution best fits your environment.

AspectAlways On VPNEntra Private Access
ArchitectureOn-premises VPN gateway(s)Cloud-based service
Access ModelFull network access via a routable IP address assigned to the endpointPer-resource zero-trust network access (ZTNA); no full network access
AuthenticationOn-premises AD or Entra ID (AD-synced accounts only)Entra ID (AD-synced or cloud-native)
Client SoftwareBuilt-in or third-partyGlobal Secure Access client
Tunneling ProtocolsIKEv2, SSTPgRPC
Network ExposureMust expose VPN servers to the public InternetNone. Private Network Connectors require outbound access only
GranularityAll protocols and ports (default)Application-level (FQDN, IP/port, IP range, CIDR blocks)
Conditional AccessRequires additional configurationNative per-app enforcement
Device-Based ConnectivityYes – device tunnel provides pre-logon connectivityNone
Infrastructure RequirementsVPN servers, RADIUS servers, internal PKI, AD, load balancers, GSLBEntra Private Network connector (minimum one server, two recommended for redundancy)
Device SupportWindows onlyCross-platform (Windows, macOS, iOS, Android)
LicensingIncluded in OS licenseAdditional per-user costs with Entra Suite or standalone Entra Private Access license

Advantages of Always On VPN for Domain-Joined Endpoints

Always On VPN integrates more naturally with classic Active Directory domain-joined Windows devices. Always On VPN includes features that Entra Private Access does not currently provide, which administrators may require to provide full support for their mobile devices.

Device Tunnel Support

The Always On VPN device tunnel provides machine-based pre-logon connectivity. The device tunnel ensures access to on-premises authentication services (domain controllers) before the user logs on to the endpoint. The device tunnel allows for logging in without cached credentials (e.g., for new users) and streamlines password changes. In addition, it ensures network access to support complete group policy processing for remote users. Entra Private Access is user-based only and does not include device-based connectivity. The device tunnel is one of the most significant functional gaps between Always On VPN and Entra Private Access.

Note: Although device-based connections are not currently available in Entra Private Access at the time of this writing, Microsoft may add the feature in the future.

Windows Native Integration

Always On VPN leverages the built-in Windows VPN client, which integrates deeply with the operating system. The Windows VPN client is mature and robust, supporting secure authentication protocols with certificates or smart cards. Always On VPN requires no additional client software. For Entra Private Access, administrators must deploy and manage a separate software component, the Global Secure Access client.

Full Network Access

The domain is a trust boundary, and domain-joined endpoints require broad network access to function. For example, domain-joined endpoints must have access to domain controllers, and most access those resources using several protocols and numerous different ports. In addition, these endpoints must be able to connect to a variety of other internal resources, such as DNS servers, certification authorities (CAs), revocation servers (HTTP, OCSP, LDAP), systems management servers, file shares, printers, and more. Furthermore, much of this access occurs via Remote Procedure Call (RPC) and Distributed COM (DCOM), which use ephemeral (dynamic) port ranges (49152-65535). Enforcing firewall policy to restrict access for remote domain-joined clients is challenging because these endpoints require significant resources.

So, if your managed endpoints are primarily domain-joined and depend on pre-logon network connectivity, Always On VPN remains the more mature and feature-complete choice today.

Why Entra Private Access is Ideal for Native Entra ID Joined Devices

Entra Private Access is designed around a cloud-first, identity-centric Zero Trust model and has explicit client and device requirements that align best with Entra ID joined devices.

Client Requirements

The Global Secure Access client required for Entra Private Access requires Windows devices to be Microsoft Entra-joined or Microsoft Entra hybrid-joined. Domain-joined only (non-hybrid) devices are not supported. Unlike the native VPN client built into Windows, the Global Secure Access client is a separate piece of software that administrators must install independently.

Per-App Zero Trust

Entra Private Access controls access using FQDNs or IPs (individual, ranges, or networks) and specific protocol/port combinations instead of full network routing. Per-app access aligns with the modern cloud-native device model by avoiding broad network exposure and evaluating every access request through Conditional Access (including device compliance, MFA for legacy protocols, and more). Unlike Always On VPN, the principle of least privilege is enforced at all times.

Simplified Management

Entra Private Access requires minimal on-premises supporting infrastructure. There’s no need for VPN servers, RADIUS servers, or complicated certificate services for VPN authentication. Entra Private Access natively uses Entra ID and Conditional Access, eliminating the need for certificate authentication.

Cross Platform

Entra Private Access provides cross-platform support. Not only does it support Windows clients (Enterprise or Professional editions), but it also supports macOS, iOS, and Android. Broad client support makes Entra Private Access a comprehensive, secure remote access solution for all your managed endpoints.

In summary, Entra Private Access provides a cleaner, more secure, and lower-management experience for organizations moving toward Entra ID joined device fleets, especially when combined with Microsoft Intune for management and Conditional Access policies for enhanced security.

Licensing

Always On VPN and Entra Private Access use different licensing models.

Always On VPN

No per-user or per-device licensing required for Always On VPN. Always On VPN licensing is included with the Windows operating system license you already own.

Entra Private Access

Entra Private Access requires a separate license and incurs an additional per-user cost. It is included with the Microsoft Entra Suite license (~$12.00/user/month), or as a separate, standalone Entra Private Access license (~$5.00/user/month). You can learn more about Microsoft Entra licensing here.

Migration Path

Migrating from Always On VPN to Entra Private Access is low-risk. Using a phased approach, administrators can move from Always On VPN to Entra Private Access with minimal disruption. Start by planning for Entra Private Access (client agent deployment, connector placement, conditional access policies, etc.), then gradually deploy the solution, initially coexisting with Always On VPN but moving toward full deployment. Once complete, decommission the legacy VPN. Key steps include:

  1. Assess your resources, devices, and Entra ID licensing.
  2. Enable Entra Private Access, deploy one or two Private Network Connectors on-premises, and install the Global Secure Access client on devices.
  3. Configure access rules. Begin with Quick Access to replicate VPN-like behavior.
  4. Run both solutions side-by-side. Pilot with a small group, migrate apps/users incrementally, and enforce Conditional Access (including MFA for sensitive applications).
  5. Phase out and decommission Always On VPN once stable.

This approach reduces infrastructure overhead, delivers granular zero trust security, and aligns with a cloud-first identity strategy.

Summary

Microsoft Always On VPN provides reliable on-premises remote access for Windows devices using protocols such as IKEv2 and SSTP. Today, it remains the best choice for environments that use traditional Active Directory domain-joined devices, where pre-logon connectivity and broad network access are required. However, Always On VPN requires heavy infrastructure and typically grants risky full network access.

Entra Private Access is the preferred solution for organizations adopting a cloud-first, Zero Trust strategy with Entra ID joined endpoints. Its per-application access model, native Conditional Access enforcement, reduced infrastructure footprint, and cross-platform support make it ideal for modern managed endpoints where least-privilege access and simplified operations are priorities.

In practice, many organizations will benefit from running both solutions in parallel during a transition period, using Always On VPN to support domain-joined endpoints and Entra Private Access for modern, Entra-joined devices. Over time, as device fleets and applications modernize, Entra Private Access can progressively replace legacy VPN infrastructure while improving security posture and reducing operational complexity.

Ready to Modernize Your Remote Access Strategy?

Schedule a free one-hour consultation to review your current Always On VPN deployment, assess readiness for Entra Private Access, and identify a secure, practical migration path tailored to your environment. We’ll cover architecture considerations, device requirements, licensing implications, and common pitfalls—no obligation required. Fill out the form below to request more information and schedule your free consultation.

Additional Information

Microsoft Entra Private Access Intelligent Local Access (ILA)

Preventing Port Exhaustion on Entra Private Network Connector Servers

Microsoft Security Service Edge (SSE) Now Generally Available

Microsoft Entra Security Service Edge (SSE) on RunAs Radio

Absolute Secure Access and IPv6

Absolute Secure Access (formerly NetMotion Mobility) is a premium enterprise secure remote access solution with deep user and application insight supporting Windows, Mac, iOS (iPhone and iPad), and Android devices. Although Absolute Secure Access supports IPv6 for remote network connections and client IP address assignment, the latter is not enabled by default. Administrators must make additional changes to the configuration to assign IPv6 addresses to their clients so they can access resources inside the tunnel using IPv6.

DHCPv6 and SLAAC

Absolute Secure Access supports DHCPv6 and Stateless Address Autoconfiguration (SLAAC) methods for assigning IPv6 addresses to connected clients. Although IPv6 client addressing is not enabled by default, it is quick and easy to configure.

Note: Absolute Secure Access does not currently support static IPv6 prefix assignment.

Enable IPv6

To enable IPv6 global support for all Absolute Secure Access clients, open the Secure Access management console and navigate to Configure > Client Settings > Virtual Address > Allocation Method: IPv6. Administrators can choose to support either DHCPv6 alone or DHCPv6 and SLAAC. After making a selection, click the Apply button to save the changes.

Once configured, Absolute Secure Access clients will be assigned an IPv6 address and can access IPv6 resources over the Secure Access tunnel.

Split Tunneling

If you have configured the Absolute Secure Access policy for split tunneling, ensure you have included your internal IPv6 prefix(es) defined in the split tunneling policy.

Additional Information

NetMotion Mobility is now Absolute Secure Access

Absolute Secure Access Zero Trust Network Access (ZTNA)

What’s New in Absolute Secure Access v13

Absolute Secure Access Features and Capabilities

Absolute Secure Access Advanced Features In Depth

Enterprise Zero Trust Network Access (ZTNA) and VPN

Always On VPN and Interface Metrics

Always On VPN DNS Registration Update Available

In Windows, each network interface identified by the operating system is assigned a metric value. Interface metrics are settings that determine the priority or preference of network interfaces when there are multiple active network connections. The Windows networking stack uses these metrics to determine which network interface should be used for routing traffic when multiple network interfaces are available. Network interface metrics are critical for Always On VPN administrators to understand because they can impact how name resolution requests are processed when an Always On VPN connection is established.

Metric Values

By default, Windows automatically assigns metric values to network interfaces (including VPN interfaces) based on various factors, including the connection speed, link state, and interface type. It tries to select the most suitable interface for general internet connectivity.

Metrics and DNS

Windows will also use the network interface with the lowest metric value as the preferred interface for sending DNS queries by default. This means that DNS queries will be routed through the network interface with the lowest metric value, assuming it is available and connected. When an Always On VPN connection is established, DNS queries may fail or return unexpected results if the network interface metrics are not configured optimally.

Split DNS and Wired Ethernet

Split DNS (sometimes called ‘split brain DNS’) is when the DNS namespace is the same internally and externally. The most common scenario where interface metric settings interfere with DNS operation is when using split DNS and the endpoint is connected to the Internet with a wired Ethernet connection. In this scenario, the Ethernet interface will be assigned the same or lower interface metric value as the Always On VPN interface, which can yield unexpected results.

Viewing Metrics

Always On VPN administrators can view currently assigned interface metric values by running the following PowerShell command.

Get-NetIpInterface

Assigning Metrics

Most Always On VPN administrators will never have to change interface metric settings. However, if your implementation uses split DNS and some of your endpoints connect using wired Ethernet connections, you may need to update the interface metric settings to ensure proper DNS operation. Choose a setting for the interface metric value that is lower than the wired Ethernet interface. I’ve used a value of ‘3’ without issue for many years. Use one of the following methods to update the interface metric for Always On VPN connections.

PowerShell

Updating interface metric settings in Windows can be accomplished by running the Set-NetIpInterface PowerShell command.

Set-NetIpInterface -InterfaceAlias <connection name> -InterfaceMetric 3

Note: Using PowerShell to assign the interface metric is not persistent! While this method is suitable for local validation testing, you should use one of the following methods to implement this change permanently.

Rasphone.pbk

To assign the interface metric permanently, Always On VPN administrators can edit the following settings in the rasphone.pbk configuration file.

IpInterfaceMetric=3

Ipv6InterfaceMetric=3

Administrators can automate updating this setting using the Update-Rasphone.ps1 PowerShell script. In addition, the following scripts can be used with Microsoft Intune remediation.

Detect-DeviceIpv4InterfaceMetric.ps1

Remediate-DeviceIpv4InterfaceMetric.ps1

Detect-DeviceIpv6InterfaceMetric.ps1

Remediate-DeviceIpv6InterfaceMetric.ps1

Detect-Ipv4InterfaceMetric.ps1

Remediate-Ipv4InterfaceMetric.ps1

Detect-Ipv6InterfaceMetric.ps1

Remediate-Ipv6InterfaceMetric.ps1

DPC

Organizations using PowerON Platforms’ Dynamic Profile Configurator (DPC) to manage Always On VPN client configuration settings with Active Directory and group policy or Microsoft Intune can enable the VPN Tunnel Metric setting.

Additional Information

Get-NetIpInterface PowerShell Command

Set-NetIpInterface PowerShell Command

Managing Always On VPN Client Settings with DPC

Always On VPN DPC with Microsoft Intune

Always On VPN DPC Advanced Features

Always On VPN DPC Video Demonstration

PowerON Platforms Always On VPN Dynamic Profile Configurator (DPC)