Entra Private Network Connector Session Persistence

The Microsoft Entra Private Network Connector is a lightweight on-premises software agent that enables Microsoft Entra Private Access to forward Global Secure Access (GSA) client traffic to internal resources. In environments with multiple connectors, traffic is normally distributed across available connectors in a connector group. While this improves resiliency and load distribution, it can create challenges for applications that rely on a consistent connector source IP address.

Stateless Connectors

By default, requests are distributed randomly among the available connectors in a connector group. Traffic forwarded to the internal resource uses the connector server’s IP address as its source. Consequently, separate connections from the same user and device can reach the application through different connectors. Importantly, session state is not shared among connectors in a connector group. As such, applications that associate session state with the source IP address may reject or interrupt these connections.

Why Session Persistence Matters

In some scenarios, an internal application might allow access only from specific connector IP addresses or associate an authenticated session with the source IP address. Random connector selection can cause subsequent connections to arrive from a different address, potentially interrupting the session. Session persistence reduces this risk by consistently using the same connector for the user and device.

Session Persistence

Microsoft recently introduced session persistence for Entra Private Access applications. When enabled, requests from the same user and device are consistently routed to the same connector for the duration of the session. This helps maintain a consistent connector egress IP address for applications that depend on source IP addresses for authentication, authorization, or session management.

Traffic Routing

The connector traffic routing method is configured on a per-application basis. Traffic routing methods can be defined on Quick Access or Enterprise applications, and the setting can be configured on the Network access properties tab. Administrators have two options: Random or Session Persistence.

Random

This is the default behavior for the Private Network connector. All new connections are distributed randomly among connectors in the connector group.

Session Persistence

Selecting the Session Persistence option consistently routes requests from the same user and device to the connector on which the session was established.

Connector Routing Method Comparison

The following table summarizes these configuration options.

Routing MethodBenefitsConsiderations
RandomBetter distribution across connectors in a connector groupSource IP address may change between connections
Session PersistenceConsistent connector egress IP addressMay not distribute sessions as evenly as the Random method

Failover

If the preferred connector becomes unavailable, subsequent traffic may be routed through another available connector. Applications that depend on the connector’s source IP address might require the user to establish a new session.

GSA Applications Only

Session persistence applies only to Global Secure Access applications. It is not supported for applications published using Microsoft Entra Application Proxy.

Summary

By default, Microsoft Entra Private Access distributes requests randomly among available connectors. Although this provides load distribution, it can create problems for applications that depend on a consistent connector source IP address. Session persistence addresses this issue by consistently routing traffic from the same user and device through the same connector for the duration of the session. This feature applies only to Global Secure Access applications and is not supported for Microsoft Entra Application Proxy applications.

Additional Information

Entra Private Network Connector Overview and Deployment Strategies

Preventing Port Exhaustion on Entra Private Network Connector Servers

Microsoft Entra Private Network Connector Groups

Entra Global Secure Access (GSA) Client Intune Deployment PowerShell Script

The Microsoft Entra Global Secure Access (GSA) client is commonly deployed using Microsoft Intune. To deploy the client as an Intune Win32 app, administrators package the installer and a PowerShell installation script into an .intunewin file. Microsoft provides a sample PowerShell script that creates a log, configures Windows to prefer IPv4 over IPv6, and launches the installer. However, the sample has several limitations that can make it unreliable in production environments. To address these shortcomings, I’ve refactored the code to make it more robust and better aligned with enterprise deployment best practices.

Script Improvements

Microsoft’s PowerShell script for installing the GSA client has several significant limitations. My refactored version includes the following improvements.

  1. Preserved the existing DisabledComponents setting. Microsoft’s example overwrites the entire registry value, potentially removing previously configured settings. My version sets the 0x20 bit to prefer IPv4 while preserving any other flags already present.
  2. Validates the installer’s Authenticode signature. My revised script verifies that the installer has a valid Authenticode signature and that the signing certificate identifies Microsoft Corporation as the publisher.
  3. Preserves the pending reboot state. My script records when the registry setting was changed and compares that timestamp with the device’s last boot time. If the device has not restarted, subsequent runs continue to return exit code 3010, even if an earlier installation attempt failed.
  4. Expanded exit-code handling. The script writes a timestamped PowerShell transcript to the Intune Management Extension log directory, allowing it to be included with collected Intune diagnostics. Logging failures do not prevent the installation from continuing.
  5. Intune-integrated logging. I’ve updated the script’s logging to use the Intune Management Extensions logs folder, so logs are captured by Intune’s diagnostics collection. Each run of the script generates its own timestamped log file, making troubleshooting easier. Also, logging failures never block installation.
  6. Best practice alignment. I’ve added comment-based help, culture-invariant timestamps, and a $PSScriptRoot guard with a clean error to handle script execution issues. In addition, the script is digitally signed to support environments that enforce signed-script execution policies.

GitHub

I’ve published my refactored GSA client installation script on GitHub. You can download the script here:

https://github.com/richardhicks/gsa/blob/main/Install-GSAClient.ps1

Note: The script expects the installer to be named GlobalSecureAccessInstaller.exe. However, downloaded installers typically include the version number in the filename, such as GlobalSecureAccessInstaller_<version>.exe. Before creating the .intunewin package, either rename the installer or update the $InstallerName variable in the script.

Contribute

Suggestions and contributions are welcome. If you have ideas for making the GSA client deployment more robust or reliable, please submit a pull request on GitHub.

Summary

Microsoft provides a PowerShell script to deploy the Entra GSA client via Intune, but it has several limitations. This refactored version preserves existing registry settings, validates the installer, improves reboot and exit-code handling, integrates logging with Intune diagnostics, and better aligns with enterprise deployment best practices.

Additional Information

Install-GSAClient.ps1 PowerShell Script on GitHub

Prepare Win32 App Content for Upload to Microsoft Intune

Install the Global Secure Access Client for Microsoft Windows

Entra Internet Access TLS Inspection and Always On VPN: Troubleshooting SSTP Connection Failures

Microsoft Entra Global Secure Access (GSA) is a cloud-based Security Service Edge (SSE) solution that includes Entra Private Access to provide zero-trust network access to private data and applications, and Entra Internet Access to provide security controls for general internet access. Entra Internet Access includes features such as web content filtering, AI prompt controls, TLS inspection, and more. Entra Private Access and Entra Internet Access share a common client: the Global Secure Access Client.

TLS Inspection

TLS inspection is a powerful feature of Entra Internet Access that allows inspection and policy enforcement for encrypted internet traffic. It enables more thorough inspection and is required for features such as AI prompt policies. When TLS inspection is enabled, the TLS connection from the target server (origin server) is terminated by the Entra service. A new session is created between the cloud and the endpoint using a dynamically generated TLS certificate issued by Entra. As Entra holds the private key for this certificate, it can decrypt and inspect traffic as necessary.

Always On VPN

Recently, a customer asked me to help troubleshoot an Always On VPN user tunnel connectivity issue. The problem began shortly after deploying the Global Secure Access client with TLS inspection enabled. Administrators had configured the default TLS inspection policy to inspect traffic for all websites.

User Tunnel Failures

Attempts to manually start the Always On VPN user tunnel resulted in a failed connection attempt with the following error message.

Error 0x800704D4: The network connection was aborted by the local system.

Event Logs

Reviewing the client event logs revealed numerous Event ID 20227 entries from the RasClient source with the following error message.

The user DOMAIN\User dialed a connection named [connection name] which has failed. The error code returned on failure is -2147023660.

Note: Error code -2147023660 is the decimal equivalent of 0x800704D4.

Troubleshooting

Initial testing with Test-NetConnection confirmed that TCP port 443 on the VPN server was reachable. However, using Get-TlsCertificate revealed the real problem.

Although the certificate subject matched the VPN server, the issuer did not. Instead of the VPN server’s issuing CA, the certificate had been issued by Microsoft Entra Global Secure Access, confirming that TLS inspection was intercepting the connection.

SSTP and TLS Inspection

The Secure Socket Tunneling Protocol (SSTP) is a Microsoft proprietary VPN transport that uses HTTP for tunneling and TLS for security. Unlike a web browser, which can establish a new trusted TLS session with an inspection proxy, SSTP validates the VPN server’s certificate as part of establishing the VPN tunnel. Any certificate substitution, even by a trusted TLS inspection service, changes the server certificate thumbprint and causes SSTP validation to fail.

Workaround

The solution is to create a TLS inspection exclusion policy to exempt inspection for the VPN server FQDN(s), as shown here.

Summary

Microsoft Entra Internet Access TLS inspection can unintentionally interfere with Always On VPN deployments that use SSTP. Because TLS inspection replaces the VPN server’s certificate with one issued by Microsoft Entra, SSTP detects the certificate mismatch and terminates the connection. If you use Always On VPN with Entra Internet Access, configure a TLS inspection exclusion for your VPN server FQDNs to prevent interception while preserving TLS inspection for general internet traffic.

Additional Information

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

What is Microsoft Entra Global Secure Access?

Microsoft Entra Internet Access

Microsoft Entra Private Access

Always On VPN SSTP and 47-Day TLS Certificates

Always On VPN SSTP and HSTS