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

Always On VPN Trusted Network Detection and Native Azure AD Join

Administrators deploying Microsoft Always On VPN are quickly learning that the native Azure Active Directory join (AADJ) model has significant advantages over the more traditional Hybrid Azure AD join (HAADJ) scenario. Native AADJ is much simpler to deploy and manage than HAADJ while still allowing full single sign-on (SSO) to on-premises resources for remote users. Intune even allows for the import of custom ADMX and ADML administrative templates, further reducing the dependency on on-premises Active Directory for device management.

Remote Management

Although devices aren’t joined to the domain, administrators may still wish to access those clients connected to their network for device discovery or to perform administrative tasks. However, when native AADJ clients connect via Always On VPN, the Public Windows firewall profile is assigned to the VPN tunnel adapter. The Public profile is, of course, more restrictive and blocks most management protocols by default.

Firewall Rules

While adding firewall rules to the Public profile to allow management protocols is possible, this isn’t recommended for security reasons. The Public profile is typically loaded when the device is on an untrusted network. Exposing management protocols on an insecure network is asking for trouble.

Domain Profile

Domain-joined or Hybrid AADJ endpoints will use the Domain Windows firewall profile. This profile is more permissive, allowing many standard management protocols by default. Also, administrators can add rules to allow additional access as required without increasing the risk for devices on untrusted networks.

Trusted Network Detection

So, the trick is to get a native AADJ endpoint to load the Domain profile for the VPN tunnel adapter when connected via Always On VPN. Trusted Network Detection is accomplished by using settings configured on the endpoint using the NetworkListManager Configuration Service Provider (CSP).

Intune and XML

There are two settings administrators can enable AADJ devices to detect a trusted network and load the Domain Windows firewall profile. Unfortunately, these settings can only be applied using Intune and the Custom XML template. Administrators will use the following OMA-URI settings.

AllowedTlsAuthenticationEndpoints

The AllowedTlsAuthenticationEndpoints policy setting defines the URL the device uses to validate a trusted network. The target must be an on-premises web server with a valid TLS certificate using HTTPS. The target must be a highly available internal resource inaccessible from the Internet. DirectAccess administrators will be quite familiar with this concept; it’s the Network Location Server (NLS)!

Use the following OMA-URI to configure the TLS authentication endpoint.

URI: ./Device/Vendor/MSFT/Policy/Config/
NetworkListManager/AllowedTlsAuthenticationEndpoints

String: <![CDATA[https://nls.corp.example.net]]>

ConfiguredTlsAuthenticationNetworkName

The ConfiguredTlsAuthenticationNetworkName policy setting is optional. Administrators can use this setting to provide a friendly name for the authenticated trusted network. The FQDN of the target resource (NLS) is used by default. However, using this setting overrides the default with something more meaningful.

Use the following OMA-URI to configure the TLS authentication network name.

URI: ./Device/Vendor/MSFT/Policy/Config/
NetworkListManager/ConfiguredTlsAuthenticationNetworkName

String: <Friendly network name>

Results

Once configured, you’ll find the Always On VPN tunnel adapter uses the Domain Windows firewall profile and an optional friendly network name.

Additional Information

Deploying Always On VPN with Intune using Custom XML and CSP

Always On VPN CSP Updates

Always On VPN and VpnStrategy with CSP