A team enables private networking on Microsoft Foundry, disables public access, wires up the private endpoints, and confirms DNS resolves. Then someone opens the chat playground in the portal and gets an error saying private networking is blocking access. Sometimes it works. Then it stops, and once it stops it stays stopped.

Meanwhile a PowerShell script hitting the exact same model endpoint returns a clean response every time. A container app using that Foundry resource as its model provider runs without complaint.

If you have seen this, the problem is almost certainly not in Azure. It is in the browser. Here is the full diagnostic path, because the wrong answer costs hours.

Figure 1. Same endpoint, same private IP, two different outcomes.

That difference is the whole puzzle, and it is also the answer. Hold onto it.

What gets ruled out first, and why none of it is the cause

This failure impersonates a networking problem convincingly. Work through the list anyway. You need it eliminated before the real cause is believable.

DNS resolution - Check every Foundry endpoint, not just one. 'A Foundry deployment surfaces several hostnames, including separate ones for OpenAI and other Azure AI service endpoints, and it is easy to validate one and assume the rest. Use Resolve-DnsName rather than nslookup, because it is more truthful about what is actually coming back. You are looking for a private IP on each one. If you get one, DNS is not your problem.

NSGs and route tables - Temporarily detach both from the VM subnet and from the subnet hosting your Foundry agents. If the error survives that, your rules are not the cause.

Proxies and TLS inspection - A fair suspicion wherever a forward proxy, a next-generation firewall, or a network virtual appliance sits in the path and terminates TLS. Test from a clean VM with no proxy configuration and no inspection agent on it. If the failure follows you there, the proxy is not it.

The firewall - Watch the flow logs during a failed request. No drops means no drops.

Diagnostic logs - Turn on diagnostics for both the Foundry resource and the project, because they log separately, then query them in Log Analytics while you reproduce the failure. Do not be misled by 403s that turn out to belong to unrelated public IPs.

At that point every layer is clean and the playground is still dead.

Figure 2. Five layers come back clean before the real clue shows up.

The clue everyone walks past

Open the browser developer tools and send a prompt from the playground.

If this were genuinely a private endpoint problem, you would see a 401. You will not. You will see CORS errors.

That distinction is the whole article. A CORS error is not a network reachability failure. It is the browser refusing to make a request it has already decided it does not like. The traffic is not being blocked somewhere in Azure. It is being blocked before it ever leaves the machine.

It also explains the asymmetry from Figure 1. A PowerShell script has no origin, so no origin-based check applies to it. A browser does. That is the entire difference between the API call that works and the playground that does not.

The cause: Local Network Access

Chromium added a security feature called Local Network Access. It stops a page served from a public origin making requests into private address space unless the user grants permission. The point is to prevent a malicious public website reaching into the machines and services on your internal network, which is the classic DNS-rebinding attack.

It arrived in Chromium 141, reached Chrome 142, and ships on by default in Microsoft Edge 143.

Now look at what private networking does to the Foundry portal. The playground is served from ai.azure.com, a public origin. With private networking enabled, your Foundry endpoint resolves to a private IP. So, the playground's own data-plane calls are a public origin reaching into private address space, which is exactly the pattern Local Network Access exists to stop. The browser does not know, and does not care, that both ends belong to you.

This also explains the intermittency. Local Network Access is a permission, and the prompt does not fire consistently across every site and situation. What looks like a flaky network is really a permission that got granted in one session and was never offered in the next.

Worth knowing this is not specific to Foundry. The same mechanism has been reported against Cosmos DB record browsing, Key Vault secret values, and Document Intelligence Studio. Any browser-based portal experience that talks to a private endpoint is a candidate.

Fixing it in three tiers

Figure 3. Three ways to fix it, and only one of them scales.

One user, right now - In Edge, go to Settings, then Privacy, search, and services, then Site permissions, then All permissions, then Local network access. Under the list of sites allowed to reach other devices on your local network, add https://ai.azure.com. Restart the browser. The playground works.

This is the right move for confirming your diagnosis and the wrong one to leave in place. It fixes one profile on one machine.

A fleet, properly - Two Edge policies matter, both under Administrative Templates, Microsoft Edge, Network settings.

LocalNetworkAccessAllowedForUrls is the one you want. Supported on Windows and macOS from Edge 140, Android from 144, it exempts matching origins from Local Network Access checks. It takes a list of URL patterns:

SOFTWARE\Policies\Microsoft\Edge\LocalNetworkAccessAllowedForUrls\1 = https://ai.azure.com

Scope it deliberately - A pattern like [*.]azure.com will clear this whole class of problem across Azure portal experiences, but it is a broad exemption, and your security team should agree to it rather than discover it.

Edge 146 added a companion, LocalNetworkAllowedForUrls, aimed specifically at local network endpoints. Where an origin matches several of these policies, the block lists take precedence over the allow lists, so make sure you are not fighting an existing deny rule.

LocalNetworkAccessRestrictionsTemporaryOptOut, supported from Edge 143, switches the restrictions off wholesale and downgrades failures to warnings in developer tools. There are two reasons not to reach for it. It disables a real security control everywhere, not just for Foundry. And it is explicitly temporary: it will be removed after Edge version 156, so anything you build on it has a deadline.

Whichever you pick, deploy it centrally through Intune or Group Policy. Walking each user through browser settings one at a time is not a fix, it is a support queue.

Resources

• Edge Browser Policy Documentation - Full reference for LocalNetworkAccessAllowedForUrls and related policies.
• Configure Edge policies with Intune - Step-by-step deployment guide.
• Microsoft Foundry private networking - Official documentation for private endpoint configuration.
• Chromium Local Network Access explainer - Technical specification for the security feature.

The lesson worth keeping

When a direct API call succeeds and the portal experience fails, stop debugging the network and start looking at the client.

That single test, script against browser, hitting the same endpoint, would have pointed straight at the answer. It separates "can this machine reach this endpoint" from "will this browser allow this page to reach this endpoint", and those are entirely different questions with entirely different owners.

The broader point is that private networking moves your services into private address space, and browsers now treat private address space as something to protect people from. That is a sensible security default. It also means every browser-based portal experience that talks to a private endpoint is now a candidate for this failure, and none of them will tell you that is what happened. You will get a CORS error, or a generic message about an error occurring while processing your request, and you will go looking through your route tables.

Next steps 

If you're hitting this now - Add ai.azure.com to your Local Network Access allowlist and confirm the fix.

If you manage a fleet - Open a change request to deploy LocalNetworkAccessAllowedForUrls via Intune or Group Policy before more users hit this.

If you're planning private networking - Add browser policy deployment to your rollout checklist alongside DNS and NSG configuration.