Docs / Deployment & Clients / Microsoft Entra Global Secure Access (GSA) with ScoutDNS
Browse Deployment & Clients
Deployment & Clients

Microsoft Entra Global Secure Access (GSA) with ScoutDNS

How to run ScoutDNS with Microsoft Entra Global Secure Access. Private Access works automatically on Windows Client 2.2.6 and later, and GSA Internet Access needs the ScoutDNS Block Page IPs added to its Custom Bypass.

Updated Sep 1, 2026 • 3 min read

The ScoutDNS Windows Client runs alongside Microsoft Entra Global Secure Access (GSA) as of Windows Client 2.2.6 with driver 1.0.0.22 or later. Each product keeps its own lane:

  • ScoutDNS handles endpoint DNS security and policy enforcement.
  • GSA Internet Access handles allowed internet and web traffic.
  • GSA Microsoft Access handles Microsoft traffic.
  • GSA Private Access owns its configured private namespaces and applications.

[!IMPORTANT] Customer action required when GSA Internet Access is enabled. Add the ScoutDNS Block Page IPs to the GSA Custom Bypass, following the steps below. Without this configuration, ScoutDNS DNS policy can return the correct blocked response while GSA’s cloud proxy retrieves the original website.

Private Access coexists automatically

GSA Private Access needs no ScoutDNS configuration. The client detects an active Private Access tunnel automatically and permits only the required GSA bootstrap and synthetic DNS paths, so private DNS and tunnel startup are not disrupted. Ordinary public DNS continues to resolve through ScoutDNS with policy enforced. If GSA disconnects, the exception is withdrawn automatically and restored when GSA reconnects. No manual domain or IP exclusions are required.

Internet Access needs the block-page bypass

When GSA Internet Access is enabled, its cloud web proxy can undo a DNS-level block. Without the bypass:

  1. ScoutDNS blocks a domain and returns a ScoutDNS Block Page IP.
  2. The browser connects to that IP while presenting the original hostname.
  3. GSA Internet Access captures the connection, and its cloud proxy resolves the hostname again.
  4. The real website may load despite the correct ScoutDNS DNS response.

With the bypass, GSA leaves the block-page connection alone and the ScoutDNS block page displays.

Configure the bypass

  1. Open the Microsoft Entra admin center.

  2. Go to Global Secure Access > Connect > Traffic forwarding.

  3. Under Internet Access policies, select View.

  4. Expand Custom Bypass and select Add rule.

  5. Configure the rule:

    Field Value
    Destination type IP subnet
    Destination (comma-separated, no spaces) 108.61.188.221/32,144.202.115.8/32,208.167.239.230/32
    Protocol TCP
    Ports 80,443
  6. Save, then allow 10-20 minutes for policy synchronization.

The bypass only excludes connections to the ScoutDNS block-page servers. DNS remains ScoutDNS-mediated, and all other allowed internet traffic continues through GSA.

Validate the configuration

After synchronization:

  1. Run ipconfig /flushdns.
  2. Open a new InPrivate browser window.
  3. Verify a known blocked domain resolves to one of the ScoutDNS Block Page IPs.
  4. Verify the ScoutDNS block page displays.
  5. Verify an allowed website still works and appears in GSA Advanced Diagnostics as acquired internet traffic.
  6. If you use them, verify the GSA Private and Microsoft channels remain healthy.

Troubleshooting

DNS tools show the correct ScoutDNS Block Page IP, but the browser loads the real website.

  • Confirm every production /32 entry from the bypass rule above is in GSA Custom Bypass.
  • Confirm the rule covers TCP ports 80 and 443.
  • Wait 10-20 minutes for synchronization.
  • Check GSA Advanced Diagnostics.
  • Flush DNS and retest in a new InPrivate session.

If the rule does not synchronize, Microsoft documents disabling and re-enabling the Internet Access profile to force a refresh.

Browser DNS leak tests

Browser DNS leak tests may report Microsoft resolvers, or a mix of Microsoft and ScoutDNS resolvers, while GSA Internet Access is enabled. GSA’s cloud proxy can perform additional remote hostname resolution for proxied web traffic, and that by itself does not mean endpoint DNS is bypassing ScoutDNS. Validate enforcement with a known blocked domain and the returned ScoutDNS Block Page IP, not the resolver names a browser leak test shows.

Microsoft references

Was this article helpful?
Still stuck? Open a ticket and we'll follow up by email.
Open a ticket
Last updated Sep 1, 2026