GSA macOS client randomly blocks general internet access - DNS responses dropped for non-policy hostnames

Question

GSA macOS client randomly blocks general internet access - DNS responses dropped for non-policy hostnames

Alex 45

Summary

With the GSA client running on macOS, users are randomly unable to reach general internet sites (e.g. google.com) in browsers and other applications. Quitting the GSA client restores connectivity immediately. Reproducible across multiple client versions and network conditions.

Environment

GSA client versions observed: 1.1.25111702 and 1.1.26030601 (issue occurs on both)
OS: macOS
Tenant region: AU
Reproduced on Wi-Fi and tethered (iPhone Personal Hotspot) uplinks

Symptom

Users report that sites like google.com fail to load and CLI tools fail with connection errors when the GSA client is running. The failure is not limited to a specific app or protocol — it affects any general internet destination that isn’t covered by the assigned forwarding profile rules or the Microsoft-managed skip list.

Relevant log excerpts

DNS queries for affected hostnames are intercepted by the client, resolved successfully upstream, but the flow is then closed with zero datagrams and the calling application never receives a response. Example for an arbitrary non-policy hostname:


[Info][AppProxyProvider]: UDP Flow Decision: Tunnel for DNS traffic for appID=[<redacted>]

[Verbose][TransparentFlowManager]: DNS_FILTER flow read remoteHostname <redacted>

[Verbose][NAAS_DNS_RESOLVER]: Actual DNS response for host:<redacted> found as :<public-ip>

[Verbose][DontAcquireFqdnMsg]: FQDN: <redacted> is not part of the forwarding profile and will not be acquired.

[Warning][TransparentFlowManager]: UDP datagram count mismatch or empty — datagrams: 0, endpoints: 0

[Info][TransparentFlowManager]: Stopping flow <id>. Error: (null)

[Info][NAAS_BL]: HostnameNotAcquiredEvent - "ipAddress":"0.0.0.0" "hostName":"<redacted>" "originalIpAddress":"<public-ip>"

[Verbose][NAAS_DNS_RESOLVER]: Unable to extract magic ip for hostname <redacted>

Same sequence seen across many different hostnames (Google, Apple DNS gateways, Akamai CDN, Cloudflare, third-party APIs) and on both client versions.

Workaround

Quitting the GSA client restores connectivity. No other reliable workaround found.

Request

Please advise on the cause and the recommended configuration or fix. Full client logs available on request.

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-04-21T07:03:12.7366667+00:00
Hey Alex, thanks for all the detail. From your logs it looks like the macOS GSA client is intercepting DNS for any hostname not in your forwarding profile or the MS-managed skip list, resolving it upstream, then immediately closing the flow (“UDP datagram count mismatch or empty” + “DontAcquireFqdnMsg”). In effect, non-policy DNS queries never make it back to the OS resolver—so apps just hang until you quit the GSA client.

Cause

• By design the GSA client only “acquires” (intercepts) FQDNs that match your traffic-forwarding profile or the built-in skip list. Everything else is explicitly dropped, but in versions 1.1.25111702/1.1.26030601 there’s a bug where non-acquired DNS never falls back to normal resolution.

Recommended fix / workarounds

Upgrade the macOS client to the latest 1.1.x release. Microsoft has a patch in a newer build that restores true bypass for non-policy DNS queries.

Disable any secure DNS (DoH/DoT) on the Mac or in Safari so you’re on plain UDP 53. The GSA client doesn’t support encrypted DNS and it can make troubleshooting even harder. – Run scutil --dns | grep nameserver and nc -zv <dns-server> 853 to verify.

In System Settings → Network → Filters & Proxies, make sure the Global Secure Access Network Extension and Transparent Proxy are still enabled (and have permission).

(Optional) As a temporary profile tweak, add a catch-all FQDN rule (e.g. *) in your forwarding profile and set it to “Bypass.” That explicitly tells the client “don’t intercept these DNS names.”

Let me know if after upgrading and disabling secure DNS you still see those “flow stopped” messages. If you can share screenshots or the Health Check output (Advanced Diagnostics → Health Check tab) and the result of

systemextensionsctl list | grep com.microsoft.naas

we can confirm the extension is loaded correctly and drill in further.

Reference list

• Troubleshoot the Global Secure Access client for macOS: Health check tab

https://learn.microsoft.com/entra/global-secure-access/troubleshoot-global-secure-access-client-macos-health-check

• Known limitations for Global Secure Access (macOS client DNS)

https://learn.microsoft.com/entra/global-secure-access/reference-current-known-limitations?tabs=macos-client

• Proxy configuration examples for GSA

https://learn.microsoft.com/entra/global-secure-access/how-to-install-windows-client#proxy-configuration-example

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.
Alex 45 Reputation points

2026-04-22T01:08:25.9266667+00:00
Hi Rukmini,
Thanks for the reply - a few things:

Secure DNS: Not in use. scutil --dns | grep nameserver returns only plain UDP/53 entries (local resolver + GSA's 240.0.3.3 private DNS). No DoH/DoT profile installed, no app-level DoH configured. The bug reproduces on plain UDP/53, which the logs also show.

System extensions: Output of systemextensionsctl list:

com.microsoft.globalsecureaccess.tunnel (1.1.26030601) [activated enabled]

Catch-all bypass rule: Which profile would this go in? We have Private Access and Microsoft Traffic assigned. Microsoft Traffic is MS-managed, and Private Access rules only support Forward actions as far as I can see. Internet Access is not licensed in our tenant.

Patched client version: You mentioned a newer build with the fix. We're already on 1.1.26030601 which was the latest at time of capture.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-04-22T07:09:16.1666667+00:00

Alex, Thank you for sharing the details will check internally and get back to you!
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-04-24T07:25:59.0066667+00:00

Alex, Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Alex 45 Reputation points

2026-04-28T22:42:18.5333333+00:00

Hi Rukmini,
Yes - at least I now know that there is no fix and we will disable GSA for these scenarios. Where do I go about asking Microsoft for the patched client?

Thanks,
Raja Pothuraju 47,820 Reputation points Microsoft Employee Moderator

2026-04-29T00:58:25.88+00:00

@Alex, I encourage you to provide feedback directly to the Azure Product Group regarding this feature request. You can do so via the Azure Feedback Forum, which allows users to suggest new features, propose enhancements for existing ones, and share general feedback. Additionally, you can vote for existing ideas to help prioritize their implementation or submit your own suggestions.

Answer accepted by question author

Rukmini 43,915 Microsoft External Staff Moderator

Alex, The macOS GSA client versions 1.1.25111702 and 1.1.26030601 have a known bug that causes this problem. General websites fail because the client intercepts DNS queries that are not in your forwarding profile or Microsoft-managed skip list and drops them rather than falling back. Why there isn't a catch-all bypass: Only Forward actions are supported by Private Access. Microsoft Traffic can only be read. There is no license for internet access.

Solutions: For general internet access while GSA operates, use a secondary network interface (Wi-Fi, tethering). When visiting non-policy websites, temporarily exit the GSA client. To restore non-acquired DNS bypass, ask Microsoft for the patched 1.1.x client.

0 comments

1 additional answer

Your answer

Alex 45 Reputation points

2026-04-22T01:08:25.9266667+00:00

Hi Rukmini,
Thanks for the reply - a few things:

Secure DNS: Not in use. scutil --dns | grep nameserver returns only plain UDP/53 entries (local resolver + GSA's 240.0.3.3 private DNS). No DoH/DoT profile installed, no app-level DoH configured. The bug reproduces on plain UDP/53, which the logs also show.

System extensions: Output of systemextensionsctl list:

com.microsoft.globalsecureaccess.tunnel (1.1.26030601) [activated enabled]

Catch-all bypass rule: Which profile would this go in? We have Private Access and Microsoft Traffic assigned. Microsoft Traffic is MS-managed, and Private Access rules only support Forward actions as far as I can see. Internet Access is not licensed in our tenant.

Patched client version: You mentioned a newer build with the fix. We're already on 1.1.26030601 which was the latest at time of capture.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-04-22T07:09:16.1666667+00:00

Alex, Thank you for sharing the details will check internally and get back to you!
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-04-24T07:25:59.0066667+00:00

Alex, Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Alex 45 Reputation points

2026-04-28T22:42:18.5333333+00:00

Hi Rukmini,
Yes - at least I now know that there is no fix and we will disable GSA for these scenarios. Where do I go about asking Microsoft for the patched client?

Thanks,
Raja Pothuraju 47,820 Reputation points Microsoft Employee Moderator

2026-04-29T00:58:25.88+00:00

@Alex, I encourage you to provide feedback directly to the Azure Product Group regarding this feature request. You can do so via the Azure Feedback Forum, which allows users to suggest new features, propose enhancements for existing ones, and share general feedback. Additionally, you can vote for existing ideas to help prioritize their implementation or submit your own suggestions.

Answer 1

Cause: The behavior matches known Global Secure Access macOS client limitations around DNS handling when FQDN-based rules are used and DNS is encrypted or otherwise not visible to the client. For destinations not in the forwarding profile, the client must still see and pass through DNS responses. When DNS is encrypted (Secure DNS / DoH / DoT) or handled in a way the client cannot process, the client intercepts the DNS flow, determines the FQDN is “not acquired,” and then terminates the UDP flow without delivering the response back to the application. This results in random loss of general internet connectivity for non-policy hostnames while the client is running.

On macOS specifically:

The client requires visibility into DNS queries to acquire traffic by FQDN.
If Secure DNS is enabled in the OS or browser and the DNS server supports Secure DNS, the client does not tunnel traffic set to be acquired by FQDN, and DNS handling can fail for non-acquired FQDNs.
Health checks explicitly require that the DNS server used by macOS not support Secure DNS when FQDN rules are present.

The log sequence shown:

DNS query is intercepted and resolved upstream.
The client decides the FQDN is not part of the forwarding profile (DontAcquireFqdnMsg).
The UDP flow is then stopped with zero datagrams delivered back to the app (UDP datagram count mismatch or empty).
A HostnameNotAcquiredEvent is logged, indicating the hostname is not acquired and no usable “magic IP” is returned.

This is consistent with the documented behavior when DNS is encrypted or otherwise incompatible with the client’s FQDN-based interception logic.

Recommended configuration and fix:

Disable Secure DNS / encrypted DNS wherever present
- Ensure the DNS server configured on macOS does not support Secure DNS (DoH/DoT/DNSSEC). The macOS client documentation and health checks explicitly require this when using FQDN rules.
- If browsers (for example, Edge, Chrome, Firefox) have Secure DNS or DNS-over-HTTPS enabled, disable it so DNS queries go through the OS resolver that the client can inspect.
Verify DNS configuration on macOS
- Run the documented DNS checks to confirm the DNS server and encryption status:
  - scutil --dns | grep 'nameserver\[[0-9]*\]' to see which DNS servers are in use.
  - Use nc -zv <dns-ip> 853 to verify that DNS over TLS is not in use (connection should be refused if DNS is not encrypted).
- Ensure the “Is DNS encrypted” health check in the macOS client shows that DNS is not encrypted when FQDN rules are configured.
Align forwarding profile rules with DNS behavior
- If FQDN-based rules are required, they must operate with DNS that the client can read (unencrypted, OS-level DNS). Once Secure DNS is disabled and a compatible DNS server is used, the client can correctly:
  - Rewrite responses to “magic IPs” for acquired FQDNs.
  - Pass through responses unchanged for non-acquired FQDNs (general internet sites).
Use the macOS Health Check and diagnostics
- Open the Global Secure Access macOS client’s Advanced Diagnostics Tool and Health check tab to validate:
  - DNS server IP is correctly configured and reachable.
  - “Magic-IP received for EDS” and “Tunneling succeeded” tests pass.
  - “Is DNS encrypted” reflects the expected (non-encrypted) state when using FQDN rules.
- If health checks still fail after DNS changes, export logs from the Troubleshooting tab and engage Microsoft Support as directed in the health check guidance.
As a temporary mitigation
- If disabling Secure DNS is not immediately possible, consider avoiding FQDN-based rules for affected traffic and using IP-based rules instead, as IP-based acquisition is explicitly not affected by the Secure DNS limitation on macOS.

Once Secure DNS is disabled and a non-encrypted DNS path is used, the client should stop dropping DNS responses for non-policy hostnames, and general internet access should remain stable while the GSA client is running.

References: