Entra Private Access Intelligent Local Access

Microsoft Entra Private Access, part of the Microsoft Global Secure Access (GSA) Security Service Edge (SSE), is a compelling new cloud-based Zero Trust Network Access (ZTNA) solution that offers enhanced security compared to traditional VPNs. Until recently, traffic for all defined applications flowed through the GSA tunnel regardless of the client’s location. This resulted in sub-optimal traffic flow when the client is on the same network as resources defined in Quick Access or Enterprise applications. Fortunately, Microsoft has introduced a new feature to address this crucial limitation.

Intelligent Local Access

Historically, DirectAccess used the Network Location Server (NLS) to determine network location. Always On VPN used Trusted Network Detection (TND) to accomplish this same task. GSA has lacked this critical feature since its initial release. Thankfully, Microsoft recently added Intelligent Local Access (ILA). This feature allows GSA to identify a trusted private network and bypass the client, routing traffic directly to the local resource.

How It Works

With GSA ILA, administrators define a Private Network in their GSA configuration. Administrators define a resource by FQDN along with DNS servers to use for name resolution. When the client resolves this FQDN to a matching IP address (CIDR or IP address range is accepted as well), the client will then bypass GSA for target resources defined in the policy.

Note: Authentication is still performed for access to GSA applications even when ILA indicates the client is on a private network. However, after successful authentication and the client satisfies any conditional access policies, traffic is forwarded directly to the resource rather than routed through the GSA tunnel.

Configure ILA

To configure ILA, open the Microsoft Entra admin center and follow these steps.

  1. Navigate to Global Secure Access > Connect > Private Networks.
  2. Select Add Private Network.
  3. Enter a name for the trusted network in the Name field.
  4. Enter the IPv4 address(es) of any DNS server(s) used for this network in the DNS servers field.
  5. Enter the fully qualified domain name (FQDN) of a resource on this network for name resolution in the Fully qualified domain name field (see below for additional information).
  6. Select an option from the Resolved to IP address type drop-down list. Options include IP address, IP address range (CIDR), and IP address range (IP to IP).
  7. Enter the expected name resolution result in the Resolved to IP address value field.
  8. Click Select applications below Target resource to exclude from GSA processing when on this network.
  9. Click Create.

ILA FQDN Recommendation

Technically speaking, the FQDN used by GSA for ILA can be any internal resource, even those included in Quick Access or Enterprise applications. Since the GSA client only attempts to resolve this name and doesn’t connect to it, administrators should configure a dedicated static DNS record with a dummy IP address for this purpose. A static DNS record ensures it won’t be overwritten, scavenged, or accidentally deleted. For example, administrators can create a DNS A record named ‘ILA’ that resolves to any IP address they choose, as long as it matches the IP address defined in the Private network configuration for GSA.

Troubleshooting

When confirming GSA client traffic bypass, using standard network troubleshooting tools isn’t sufficient. Here are a few examples.

Resolve-DnsName

Although the client is on a private network, Resolve-DnsName shows the IP address of the GSA address range of 6.6.x.x.

Ping (ICMP)

Interestingly, if you try to ping the FQDN, you’ll see that traffic bypasses the GSA client, as the response comes from the destination’s address.

By contrast, attempts to ping the FQDN outside the private network fail as the GSA client does not pass ICMP.

Advanced Diagnostics

The best way to confirm GSA client traffic bypass for private network resources is to use the Advanced diagnostics tool included with the GSA client. Click the GSA client icon in the notification area, then follow these steps to validate GSA client bypass when ILA is detected.

  1. Select the Troubleshooting tab in the navigation tree.
  2. Click Run Tool in the Advanced diagnostics tool section.
  3. Select the Traffic tab.
  4. Remove the Action == Tunnel filter.
  5. Click Start collecting.
  6. Initiate traffic to a Quick Access or Enterprise application configured for bypass when ILA detects a private network.
  7. Click Stop collecting.
  8. Review the log and note the Connection status for the traffic generated previously. It should indicate Bypassed when ILA detects a private network, as shown here.

Summary

With Intelligent Local Access now a feature of the Global Secure Access client, administrators can configure the client to bypass the GSA tunnel and access Quick Access and Enterprise applications directly for better performance, while still enforcing authentication and Conditional Access.

Additional Information

Enable Intelligent Local Access in Microsoft Entra Private Access

Entra Private Access Channels are Unreachable

Preventing Port Exhaustion on Entra Private Network Connector Servers

Microsoft Entra Private Access is a powerful zero-trust network access solution that is remarkably simple to install and configure. Administrators can quickly install the Global Secure Access (GSA) agent on their endpoints, then install the Entra Private Network Connector to enable secure remote access to private, internal resources. However, the ease with which Entra Private Access can be configured can potentially lead to connectivity issues in some scenarios. This post demonstrates how to diagnose port exhaustion issues and expand the available port range to address them.

Entra Private Network Connector

The Entra Private Network Connector is a key component of the Entra Private Access solution. The Private Network Connector is essentially the old Azure Application Proxy, enhanced to support TCP and UDP applications in addition to HTTP-based web applications. It is installed on an on-premises Windows server to provide GSA clients with access to internal data and applications.

Network Connectivity

The GSA client is not a virtual network adapter like most traditional VPN clients. Instead, the GSA client installed on the client operates as a filter driver in the network stack, selectively intercepting traffic and tunneling it over the GSA tunnel based on configured policy. As such, it does not appear as a network adapter in the operating system and does not have its own IP address.

Translation

When traffic from the GSA client is routed over the Entra Private Network Connector, the traffic egressing from the connector server to the internal network is effectively translated. That is, the source IP address of traffic destined for an internal resource is the connector server’s IP address, not the client’s original source IP address.

Port Exhaustion

The ephemeral port range on Windows servers spans from 49152 to 65535, leaving only 16,384 ports available. This can easily be exhausted when many clients are connected to a single Entra Private Network Connector server. This pool can also be depleted by poorly written or badly behaving applications that needlessly open many socket connections to internal resources.

Troubleshooting

Administrators can view the ephemeral port configuration for both TCP and UDP by running the following commands.

netsh.exe interface ipv4 show dynamicportrange protocol=tcp

netsh.exe interface ipv4 show dynamicportrange protocol=udp

To determine if port exhaustion is an issue, open an elevated PowerShell command window and run the following command.

Get-NetTcpConnection | Where-Object State -match ‘established’ | Measure-Object

Next, run the following PowerShell command to identify the number of ports consumed exclusively by the Entra Private Network Connector.

$ProcessId = Get-CimInstance -ClassName win32_service | Where-Object Name -eq ‘WAPCSvc’ | Select-Object -ExpandProperty ProcessID

Get-NetTCPConnection | Where-Object { $_.State -match ‘established’ -and $_.OwningProcess -eq $ProcessId } | Measure-Object

If the number of ports consumed by the Entra Private Network Connector approaches the upper limit of available ports, administrators should increase the ephemeral port range to ensure the connector server operates reliably.

Note: Use the Get-NetUdpEndpoint PowerShell command to monitor UDP port consumption on Entra Private Network Connector servers.

Resolution

To increase the ephemeral port range on the Entra Private Network Connector server, open an elevated command window and run the following commands.

netsh.exe interface ipv4 set dynamicportrange protocol=tcp startport=10000 numberofports=55535
netsh.exe interface ipv4 set dynamicportrange protocol=udp startport=10000 numberofports=55535
netsh.exe interface ipv6 set dynamicportrange protocol=tcp startport=10000 numberofports=55535
netsh.exe interface ipv6 set dynamicportrange protocol=udp startport=10000 numberofports=55535

Running these commands will increase the number of available ephemeral ports on the server to more than 50,000, well above the default. In most cases, this should be sufficient to handle many GSA client connections. However, administrators are cautioned to monitor port usage on the Entra Private Network Connector servers to ensure continued reliable operation. It may be necessary to deploy additional connector servers to process the existing workload.

Summary

Entra Private Network Connectors can exhaust the default 16,384-port ephemeral range when many GSA clients access internal TCP/UDP resources. Administrators can diagnose the issue by filtering Get-NetTCPConnection results by the WAPCSvc process, then expanding the range to over 50,000 ports using netsh.exe, as shown above. Monitor usage continuously in high-load environments to ensure consistent and stable access. And if you find you need more than 50,000 ports per server, it’s probably time to deploy additional connector servers. 😊

Additional Information

Microsoft Entra Private Access

Entra Private Access Channels are Unreachable

Microsoft Entra private network connectors

Techmentor Conference at Microsoft HQ 2025

I’m very excited to announce that I will be attending the annual Techmentor Conference at the Microsoft HQ campus in Redmond, Washington, this year. The event takes place August 11-15, 2025. The Techmentor Conference is one of my favorite IT pro conferences because it offers unparalleled access to experts worldwide. I will deliver two presentations at this year’s event. I hope you’ll join me!

Entra Private Access

On Tuesday, August 12, 2025, I will be presenting a session on Zero Trust Network Access with Microsoft Entra Private Access. ZTNA is the future of remote access and provides many security and operational benefits over traditional client-based VPN technologies.

T11 – Zero Trust Network Access with Entra Private Access

Cloud PKI for Intune

On Wednesday, August 13, 2025, I’ll discuss Simplified Certificate Management with Microsoft Cloud PKI for Intune. As organizations integrate cloud-native devices in their environments, administrators must solve the problem of issuing and managing certificates for users and devices that are not domain-joined. Cloud PKI for Intune is an excellent solution that provides deployment flexibility to address these unique and specific requirements.

W10 – Simplified Certificate Management with Cloud PKI for Intune

Register Now

Registration for the event is open now. Use the promo code HICKS and receive $500.00 off the price of admission. Don’t miss this excellent opportunity to learn from the best. Register today!

Additional Information

Techmentor Conference at Microsoft HQ 2025

Techmentor Conference at Microsoft HQ 2025 – Session List

Microsoft Entra Private Access

Microsoft Cloud PKI for Intune