Entra Private Access: app works by IP but fails by FQDN with ERR_CONNECTION_RESET

Bakr Mostafa 0 Reputation points
2026-10-06T20:37:00.57+00:00

Hello,

We are currently testing Microsoft Entra Private Access using Quick Access for internal applications.

 

During testing, we observed the following behavior:

Accessing the private application using its internal IP address works successfully through Global Secure Access.

Accessing the same application using its FQDN does not work.

Private DNS is enabled in Quick Access, and the required internal DNS suffix is configured.

In the Global Secure Access Client Advanced Diagnostics, the FQDN traffic is detected as Private Access with Action = Tunnel, which indicates that GSA is acquiring the traffic.

However, the GSA Client Health Check shows NRPT rules set: False.

 

Example:

Internal IP:443 → Working

Internal FQDN:443 → Not working

Could the NRPT rules set: False status be causing the FQDN access issue?

Also, what would be the recommended troubleshooting steps to determine whether the issue is related to Private DNS/NRPT, connector-side DNS resolution, or application-level FQDN handling? or what could be causing the access issue?

Microsoft Security | Microsoft Entra | Microsoft Entra Private Access
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-10-06T20:37:22.09+00:00

    Yes. NRPT rules set: False can explain why access by FQDN fails even when access by IP works.

    With Entra Private Access Quick Access, Private DNS works by adding a DNS suffix in Quick Access, which causes the client to generate a Name Resolution Policy Table (NRPT) entry for that suffix and send matching FQDN DNS queries to the Global Secure Access edge. If that NRPT entry is not present, FQDN queries might not be redirected through Private DNS correctly, even though IP-based traffic can still work.

    A practical troubleshooting path is:

    1. Verify the DNS suffix configuration in Quick Access.
      • In Quick Access, confirm Private DNS is enabled.
      • Confirm the configured suffix exactly matches the application FQDN suffix.
      • Private DNS applies to any FQDN ending with the configured suffix.
    2. Validate that the application FQDN is being acquired by the client.
      • In the Windows Global Secure Access client, open Advanced Diagnostics.
      • Select Forwarding profile.
      • Expand Private access rules and confirm the application FQDN appears there.
      • Then go to Traffic → Start collecting.
      • Browse to the application.
      • Stop collecting and confirm:
        • Destination FQDN shows the application
        • Channel is Private Access
        • Action is Tunnel Since this already shows Private Access and Tunnel, traffic acquisition is occurring.
    3. Focus on DNS path validation.
      • The expected Private DNS flow is:
        • client matches the suffix through NRPT
        • query goes to the DNS proxy at the GSA edge
        • if not cached, the edge forwards to the Connector
        • the Connector sends the query to the DNS servers configured on that connector server
      • Because of this flow, a failure can still occur after traffic is acquired if the connector-side DNS server cannot resolve the FQDN correctly.
    4. Check connector-side DNS resolution.
      • On the connector server, verify the operating system DNS server configuration is correct.
      • Test whether the connector server can resolve the affected application FQDN using its configured DNS servers.
      • Also test connectivity from each connector server to the affected back-end application. If connector DNS resolution fails, Private DNS resolution for the client will fail as well.
    5. Check whether the issue is application-side FQDN handling.
      • If DNS resolution succeeds and the tunnel is used, check the application logs.
      • Validate whether the application behaves differently when accessed by hostname versus IP.
      • This is especially relevant for HTTPS applications where host-based behavior can differ by FQDN.
    6. Check known client-side prerequisites that can interfere with name-based acquisition.
      • Ensure encrypted DNS is disabled.
      • Ensure IPv6 is disabled or the client is configured to prefer IPv4 over IPv6 where applicable, because Global Secure Access does not yet support traffic acquisition for destinations with IPv6 addresses.
      • For source IP anchoring validation, Microsoft also calls out disabling QUIC, IPv6, and encrypted DNS during troubleshooting.
    7. Validate general client health.
      • Confirm the user is signed in to the same Microsoft Entra tenant that the device is joined to.
      • Verify the client is not disabled by policy.
      • Restart the client and recheck health status.
      • Review Event Viewer for client errors.

    What the current symptoms suggest:

    • IP works, FQDN fails strongly points to name resolution rather than basic Private Access connectivity.
    • Traffic shows Private Access / Tunnel means the client is acquiring the destination.
    • NRPT rules set: False points to a likely Private DNS client-side issue.
    • If NRPT is corrected and the issue remains, the next most likely cause is connector-side DNS resolution.
    • If DNS is confirmed working end-to-end, the remaining likely area is application behavior specific to hostname access.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.