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

Windows Server DNS64 and IPv6 Only

Many organizations are modernizing their networks by migrating from legacy IPv4 to IPv6. The goal is to replace IPv4 with IPv6 entirely. However, even though an organization can successfully migrate to IPv6-only networks internally, they do not control networks outside its boundaries. In some cases, a host on an IPv6-only network may need to communicate with an IPv4 resource. Administrators must deploy an IPv6 transition technology to support this scenario. A common solution to address this need is DNS64 and NAT64.

What are DNS64 and NAT64?

DNS64 and NAT64, defined in RFCs 6147 and 6146, respectively, work together to ensure endpoints on an IPv6-only network can still communicate with IPv4-only resources. DNS64 enables IPv6-only clients to communicate with IPv4-only servers by synthesizing AAAA DNS records from A records. When an IPv6-only client queries a domain with only an IPv4 address (A record), the DNS64 server creates a synthetic IPv6 address by embedding the IPv4 address within an administrator-defined NAT64 IPv6 prefix. The default (referred to as ‘well known’) prefix is 64:ff9b::/96. In the example below, the IPv4-only resource ipv4.test-ipv6.com is resolved using the Cloudflare public DNS64 resolver.

Using the synthetic DNS64 address allows the client to send IPv6 packets to a NAT64 gateway, which translates them to IPv4 for the destination server. DNS64 ensures seamless address resolution for IPv6-only networks accessing IPv4 resources without requiring actual IPv6 addresses for the target.

Caveat

While DNS64 is great for ensuring IPv4 access on IPv6-only networks, it has one critical limitation. The client must connect to a resource using a hostname or a fully qualified domain name. If a client attempts to connect to an IPv4 resource directly (e.g., https://172.16.21.12 or \\10.21.12.83\data), the resource will be unreachable. To address this limitation, the 464XLAT IPv6 transition technology must be used. For more information about 464XLAT, see my previous article, Windows Server DHCP and Option 108.

Enterprise DNS64

While there are public DNS64 resolves from Cloudflare, Google, and others, they aren’t helpful when trying to resolve internal hostnames in the enterprise. Organizations must deploy their own private DNS64 services in this scenario.

Windows Server and DNS64

Today, Windows Server does not natively support DNS64. Organizations are advised to use an enterprise DNS solution such as Infoblox or BlueCat for DNS64 services. Alternatively, administrators can deploy BIND DNS on the Linux platform of their choice. DNS64 is supported in BIND 9.8.0 and later.

DNS64 Proxy

To support testing and evaluation (and perhaps production deployment for smaller organizations), it is possible to configure any supported version of Windows Server to serve as a DNS64 proxy. In this scenario, a Windows Server is configured as a DNS64 server, but the server itself is not an actual DNS server. It does not have a DNS database or zone file; it is not authoritative for any zones and can’t perform conditional forwarding. It simply forwards DNS queries to the servers defined on its own network interface.

Windows Server DNS64 Configuration

The DNS64 service must be installed using PowerShell and the Set-NetDnsTransitionConfiguration command. Administrators will define some variables, configure DNS64, and create firewall rules to allow DNS traffic inbound to the server.

Configure DNS64

On a Windows Server member server (domain-join is optional), open an elevated PowerShell command window and run the following commands.

# Define variables
$AcceptInterface = ‘Ethernet’ # The interface name or alias that will accept DNS64 traffic
$SendInterface = ‘Ethernet’ # The interface name or alias that will send DNS64 traffic
$Nat64Prefix = ’64:ff9b::/96′ # The NAT64 prefix

# Configure DNS64
Set-NetDnsTransitionConfiguration -State Enabled -AcceptInterface $AcceptInterface -SendInterface $SendInterface -PrefixMapping “$Nat64Prefix,0.0.0.0/0” -PassThru

Configure Windows Firewall

Run the following PowerShell commands to configure the Windows Firewall to allow inbound DNS requests.

# Create firewall rules to allow DNS64 traffic inbound
New-NetFirewallRule -Name ‘DNSSrv-DNS-UDP-In’ -DisplayName ‘DNS (UDP, Incoming)’ -Description ‘Inbound rule to allow remote UDP access to the DNS64 service.’ -Group ‘DNS64 Service’ -Protocol UDP -LocalPort 53 -Direction Inbound -Profile Any -Action Allow -Enabled True

New-NetFirewallRule -Name ‘DNSSrv-DNS-TCP-In’ -DisplayName ‘DNS (TCP, Incoming)’ -Description ‘Inbound rule to allow remote TCP access to the DNS64 service.’ -Group ‘DNS64 Service’ -Protocol TCP -LocalPort 53 -Direction Inbound -Profile Any -Action Allow -Enabled True

GitHub

For reference, I’ve posted the relevant commands for configuring DNS64 on Windows Server on GitHub here.

DNS64 Testing

Once DNS64 is configured on the Windows Server, administrators can test operation by sending a DNS query for an IPv4-only resource to the DNS64 server using the following PowerShell command.

Resolve-DnsName -Name ipv4.test-ipv6.com -Server <DNS64 server IPv6 address>

For example.

Resolve-DnsName -Name ipv4.test-ipv6.com -Server 2001:579:6024:510::64

The DNS64 server responds with the native IPv4 address along with the synthesized IPv6 address. However, if the target resource has only an IPv6 address or has both IPv4 and IPv6 addresses, both are returned, as shown below.

Summary

DNS64 and NAT64 are essential tools for enabling communication between IPv6-only networks and IPv4 resources. While public resolvers exist, enterprises often need their own DNS64 service for internal hostname resolution. Windows Server does not natively support DNS64, but administrators can configure it as a DNS64 proxy for testing and smaller deployments. In this scenario, Windows Server can provide DNS64 functionality, helping organizations transition toward IPv6-only networks while maintaining access to legacy IPv4 systems.

Additional Information

IPv6 Transition Technology Options – IPv6 Buzz Podcast

Set-NetDnsTransitionConfiguration

RFC 6146 – NAT64

RFC 6147 – DNS64

RFC 6877 – 464XLAT

Windows Server DHCP and Option 108

What is IPv6?

Microsoft Security Service Edge Now Generally Available

A few weeks ago, Microsoft announced the general availability of its Security Service Edge (SSE) offering, Global Secure Access (GSA). GSA encompasses Entra Internet Access, a cloud-based Secure Web Gateway, and Entra Private Access, a Zero Trust Network Access (ZTNA) solution for accessing private data and applications on-premises.

ZTNA vs. VPN

Entra Private Access will be a compelling alternative to traditional VPN solutions such as Windows Always On VPN. Where traditional VPNs grant the endpoint an IP address on the internal network, Entra Private Access provides more granular access and does not require the device to be directly connected to the network.

GSA Client

Administrators must install the GSA client on all endpoints using Entra Internet Access or Entra Private Access. Today, the client is available for Windows and Android devices. iOS and macOS clients are forthcoming.

Private Network Connector

The Entra Private Access solution relies on the Entra Private Network Connector. The Entra Private Network Connector is a software component installed on-premises that provides remote access connectivity. Previously, it was called the Azure AD Application Proxy. Essentially, it is the same technology extended to support TCP and UDP network access in addition to HTTP.

Limitations

Entra Private Access is the way of the future for secure remote access. However, today, there are still some important limitations associated with this technology.

Private DNS

Although Microsoft announced general availability for Entra Private Access, it still lacks the private DNS feature many organizations require to provide feature parity with their existing VPN. This feature is still in private preview at the time of this writing. Hopefully, Microsoft will release this feature soon.

Device Connection

Entra Private Access does not support device-based connections. This limits its capabilities for domain-joined devices. If your organization uses hybrid Entra join today, consider sticking with Always On VPN until you move to native Entra joined endpoints.

Licensing

Global Secure Access (Entra Private Access and Entra Internet Access) are included in the Microsoft Entra Suite license. More information about Entra licensing can be found here.

Additional Information

Microsoft Global Secure Access Now Generally Available

Microsoft Entra Global Secure Access (GSA) Overview

Microsoft Entra Security Service Edge (SSE) on the RunAs Radio Podcast

Microsoft Entra Plans & Pricing