Skip to main content
This article applies to all iframe-based embedded content in Curator, including Tableau dashboards and Page Builder iframes. While earlier versions of this guide focused on Tableau, Chrome’s Local Network Access restrictions affect any content loaded in an iframe.Curator applies a built-in mitigation to embedded iframes automatically (see Curator-side mitigation), but that mitigation alone does not resolve the issue in most affected environments — your IT team will usually also need to configure the browser policies described in Solutions for managed environments.

​
Overview

If you’re running Google Chrome 142 (or later) or Microsoft Edge 143 (or later), you may find that embedded content in Curator fails to load. Instead of seeing your Dashboard or embedded page, you might see a blank area where the content should appear. This happens because of a new security feature in Chromium browsers called Local Network Access restrictions (LNA). This feature blocks public websites from connecting to devices or services on your local network. While Curator and your analytics platforms use only public HTTPS endpoints, certain security tools on your computer can trigger this restriction and break embedded content.
Curator provides a server-side mitigation (the allow='local-network-access *; local-network *; loopback-network *' attribute on embedded iframes), but it cannot fully override the browser’s security checks. Your IT team will need to configure browser policies for a permanent fix.
Chrome is removing the temporary opt-out policy. Chrome 152 (released August 25, 2026) is the last version to support the LocalNetworkAccessRestrictionsTemporaryOptOut enterprise policy — Chrome 153 (scheduled for release on September 8, 2026) removes it. If your organization relies on this policy as a workaround, embedded content will stop loading as Chrome 153 rolls out to your managed devices — migrate to LocalNetworkAccessAllowedForUrls and the other policies in the Solutions for managed environments section now. Also note that Chrome moves to a two-week release cadence starting with Chrome 153, so browser-version-gated changes will arrive faster than they used to.Microsoft Edge has diverged from Chrome here: Edge keeps its equivalent opt-out policy until after Edge 156, giving Edge-managed environments more time to migrate.
You can read more about this feature in Chrome’s developer blog and Tableau’s documentation.

​
Symptoms

Example error message
You’ll know you’re experiencing this issue if you see:
  • You might see a blank area, loading screen, or error message where embedded content should appear.
  • Error messages in the browser saying a public page tried to connect to devices on the local network.
  • Content loads in other browsers - The same content works fine in Firefox, Safari, or older versions of Chrome/Edge.
  • Works on other devices - The content loads normally on personal devices that aren’t connected to your corporate network.

​
Why this happens

​
What is Local Network Access?

Chrome 142 (release notes) and Edge 143 (release notes) introduced Local Network Access (LNA) restrictions to protect users from malicious websites trying to access devices on their local network. When a public website tries to connect to these addresses, the browser will block or prompt:
  • Loopback addresses: 127.0.0.1, localhost
  • Private IP ranges: 10.x.x.x, 172.16-31.x.x, 192.168.x.x
  • Carrier-grade NAT ranges: 100.64.0.0 to 100.127.255.255 (commonly used by security products)
Starting with Chrome 145, the single Local Network Access permission was split into two more granular permissions: local-network (shown in the browser’s permission UI as Local Network) and loopback-network (shown as Apps on device). The original local-network-access permission name remains supported as an alias that covers both. You may see either naming in browser prompts and site-permission settings depending on the browser version. Today the restrictions apply to subresource requests, fetch() calls, and subframe navigation. Google and Microsoft have both stated that they plan to extend the restrictions to WebSockets, WebTransport, and WebRTC connections in a future release, so tools that currently escape the checks over those channels may start triggering prompts later.

​
Why does this affect Curator?

In most cases, Curator and your analytics platforms use only public HTTPS endpoints, so LNA shouldn’t be triggered. However, in corporate environments with certain security tools installed, those tools may create connections to local addresses while you’re using Curator. Common security tools that can trigger this issue: When one of these tools is running, your browser sees this as “public site (Curator) accessing local network” and applies LNA restrictions. If this happens while loading content in an iframe, you often won’t see a prompt—the embedded content will simply fail to load.

​
Who is affected

You’ll see this issue if:
  1. You’re using Google Chrome 142 (or later) or Microsoft Edge 143 (or later)
  2. Your organization uses security tools like those listed above that rely on local addresses or carrier-grade NAT ranges
  3. You’re accessing Curator on a managed corporate device
If you’re using Firefox, Safari, or older versions of Chrome/Edge, you typically won’t see this issue.

​
Quick troubleshooting for end users

If embedded content isn’t loading in Curator, try these quick checks:
  1. Test in another browser - Try Firefox or Safari to see if the content loads normally. If it does, this confirms an LNA issue.
  2. Check your browser version
    • In Chrome: Go to chrome://settings/help
    • In Edge: Go to edge://settings/help
    • If you see version 142+ (Chrome) or 143+ (Edge), LNA may be the cause
  3. Test on a different device - Try accessing Curator from a personal device or home network. If it works there, the issue is related to your corporate security tools.
  4. Contact your IT team - Share this article with them. They’ll need to configure browser policies to fix the issue permanently.

​
Diagnostic steps for IT teams

If users are reporting blank or failed embeds, follow these steps to confirm this is an LNA issue:

​
Step 1: Confirm the environment

Check that:
  • Users are on Chrome 142+ or Edge 143+
  • Affected devices are managed corporate machines
  • Users have security tools installed (Zscaler, Duo Desktop, Okta FastPass, Box Tools, or similar)

​
Step 2: Inspect the browser console

On an affected computer:
  1. Open Curator and navigate to a page with embedded content that’s failing to load.
  2. Open Developer Tools in the browser:
    • Chrome: Press F12 or Ctrl+Shift+I (Windows) / Cmd+Option+I (Mac)
    • Edge: Press F12 or Ctrl+Shift+I (Windows) / Cmd+Option+I (Mac)
  3. Click the Network tab in Developer Tools.
  4. Reload the page and look for failed requests:
    • Look for error messages mentioning Local Network Access
    • Check for remote addresses in these ranges:
      • 127.0.0.1 or localhost
      • 10.x.x.x, 172.16-31.x.x, 192.168.x.x
      • 100.64.0.0 to 100.127.255.255 (used by Zscaler and others)
  5. For failed requests, check the Initiator or Origin column to see which site initiated the request.

​
Step 3: Capture diagnostic information

Take screenshots or note:
  • The full URL of any failing requests
  • The remote IP address and port
  • Which security tool is involved (based on the URL/IP)
  • The browser version
This information will help you determine which domains to allowlist in browser policies.

​
Solutions for managed environments

For corporate-managed Chrome and Edge browsers, your IT team needs to configure Local Network Access policies to allowlist trusted domains.

​
For Google Chrome

Your IT team should configure Chrome enterprise policies (full policy list) using your management platform (Group Policy, Jamf, Intune, etc.). Key policies (atomic group documentation):
  • LocalNetworkAccessAllowedForUrls - List of domains allowed to make local network requests without prompting
  • LocalNetworkAccessBlockedForUrls - List of domains blocked from local network access
  • LocalNetworkAccessIpAddressSpaceOverrides (Chrome 146+) - Reclassifies IP ranges as public, local, or loopback. This is the cleanest fix when a security tool’s address range (such as Zscaler’s carrier-grade NAT range) is being misclassified as local — see below.
  • LocalNetworkAccessPermissionsPolicyDefaultEnabled (Chrome 146+) - Lets cross-origin iframes inherit the Local Network Access permission granted via LocalNetworkAccessAllowedForUrls, for cases where an allowlisted site still fails because an iframe in the chain lacks the allow attribute
  • LocalNetworkAccessRestrictionsTemporaryOptOut - Temporary opt-out (last supported in Chrome 152; removed in Chrome 153, scheduled for September 8, 2026)
If the diagnostic steps above show failing requests to addresses in the 100.64.0.0 – 100.127.255.255 range (Zscaler and similar tools), the most targeted fix is to reclassify that range as public with LocalNetworkAccessIpAddressSpaceOverrides. The policy takes a list of strings, each in [cidr]=[public|local|loopback] form:
These are the exact values Zscaler’s own advisory recommends for ZPA (IPv4 and IPv6 respectively). This stops the browser from treating the security tool’s traffic as local network access at all, so no prompts appear and no per-site allowlisting is needed.
The override removes Local Network Access protection for everything in the reclassified range, not just the security tool’s traffic. Before applying it, confirm that your organization does not host internal services in the 100.64.0.0/10 (RFC 6598) space that should stay protected — if it does, scope the override to the narrower subranges your security product actually uses instead of the full range.

​
Example configuration

In JSON format for Chrome policy:
The JSON examples on this page use Chrome’s managed-policy JSON format, where the policy value is the array itself — for example a file in /etc/opt/chrome/policies/managed/ on Linux. On Windows, configure the same policies through Group Policy or the registry (each list entry becomes a numbered value under the policy key), and on macOS through a configuration profile. Your management platform (Intune, Jamf, Google Admin console) may present these as list fields instead — enter one entry per line.
Replace the example domains with:
  • Your Curator portal URL(s)
  • Your Tableau Server or Tableau Cloud URL(s)
  • Any identity provider domains if you use SSO
To verify the policy is working:
  1. On a managed computer, open Chrome and navigate to chrome://policy
  2. Search for “LocalNetworkAccess” in the policy list
  3. Verify that your LocalNetworkAccessAllowedForUrls policy appears with the correct domains
If the allowlist alone doesn’t fix it: The LocalNetworkAccessAllowedForUrls policy applies to the top-level site making the request. When the actual local network request happens inside an iframe (which is how Curator embeds content), the iframe also needs the local-network-access permissions-policy attribute — Curator adds this automatically (see Curator-side mitigation), so keep the Local Network Access for Embedded Content Portal Setting enabled even after configuring browser policies. If embeds still fail with the allowlist in place, enable LocalNetworkAccessPermissionsPolicyDefaultEnabled alongside LocalNetworkAccessAllowedForUrls so iframes inherit the permission. Temporary workaround:
Chrome 152 is the last version to support the LocalNetworkAccessRestrictionsTemporaryOptOut policy — Chrome 153 (scheduled for release on September 8, 2026) removes it permanently. Do not build new workarounds on it; use LocalNetworkAccessAllowedForUrls and LocalNetworkAccessIpAddressSpaceOverrides instead. The policy remains available in Microsoft Edge until after Edge 156 (see the Edge section below).

​
For Microsoft Edge

Edge has equivalent policies (policy documentation) that work the same way. Key policies: Microsoft also publishes a detailed adaptation guide with policy guidance for common scenarios (carrier-grade NAT ranges, cross-origin iframes, and allowlists that don’t take effect): Adapting your website for new Local Network Access restrictions in Microsoft Edge.

​
Example Edge configuration

In Group Policy:
  1. Navigate to Administrative Templates > Microsoft Edge > Network settings
  2. Open the Allow sites to make requests to local network endpoints setting (LocalNetworkAccessAllowedForUrls)
  3. Enable the policy and add your domains:
    • https://your-curator-domain.com
    • https://your-tableau-server.com
  4. Click OK and apply the policy
Temporary workaround:
Chrome removes LocalNetworkAccessRestrictionsTemporaryOptOut in Chrome 153 (scheduled for September 8, 2026), but Microsoft has postponed Edge’s removal: the policy remains available until after Edge 156. Use the extra time to migrate to LocalNetworkAccessAllowedForUrls (plus LocalNetworkAccessIpAddressSpaceOverrides where a security tool’s address range is the trigger) — don’t wait for the removal to land.
If needed during transition, you can set Local Network Access restrictions (LocalNetworkAccessRestrictionsEnabled) to Disabled. This should only be used temporarily while you configure the proper allowlist.

​
Temporary workaround for individual users

If you need immediate access while your IT team configures the policies, you can temporarily disable Local Network Access checks in your browser.
This is a temporary workaround only. Your IT team should implement the browser policies above for a permanent solution. This setting may be reset when your browser updates or if your IT team enforces policies. The flag still exists as of Chrome 152, but Google may remove it in any future release — and with Chrome shipping a new version every two weeks starting with Chrome 153 (September 2026), that can happen with little notice.

​
Chrome flags workaround

  1. Open Chrome and go to chrome://flags/ in the address bar.
  2. Search for “Local Network Access” in the search box at the top.
  3. Find the Local Network Access Checks flag and click the dropdown next to it.
  4. Select Disabled from the dropdown.
  5. Click the Relaunch button that appears at the bottom of the page to restart Chrome.

​
Edge flags workaround

  1. Open Edge and go to edge://flags/ in the address bar.
  2. Search for “Local Network Access” in the search box at the top.
  3. Find the Local Network Access Checks flag and click the dropdown next to it.
  4. Select Disabled from the dropdown.
  5. Click the Restart button that appears at the bottom of the page to restart Edge.
After restarting, try accessing the embedded content in Curator again. It should load normally.

​
Curator-side mitigation

Curator includes a server-side mitigation for Local Network Access restrictions. Starting with version 2025.12-03, Curator adds an allow permissions-policy attribute to iframes that embed content. This attribute signals to the browser that the iframe is expected to make local network requests, which can prevent LNA from silently blocking embedded content. The attribute now carries all three permission tokens — local-network-access *; local-network *; loopback-network * — covering Chrome/Edge 142-144 (which use the original local-network-access name), Chrome 145+ (which split it into local-network and loopback-network), and any future version that drops the legacy alias. Browsers ignore tokens they don’t recognize, so the widened attribute is harmless on Firefox, Safari, and older Chromium versions.
Upgrading Curator alone does not resolve this issue in most affected environments. The allow attribute only delegates the Local Network Access permission into the embed iframe — it is a prerequisite for the embed to work, not a grant of access. Whether the request is actually allowed is still decided by the browser, through the user permission prompt or your IT team’s enterprise policies. If a security tool on the device is triggering LNA restrictions, the browser policies in Solutions for managed environments are still required after upgrading.
This mitigation has been rolled out in stages:
  • Tableau V3 embeds: The local-network-access attribute was added in Curator version 2025.12-03.
  • Page Builder iframes: The attribute was extended to Page Builder iframes in Curator version 2026.02-04.
If you are running Curator 2026.02-04 or later, all iframe-based embeds include this attribute automatically.

​
Configuring Local Network Access

The allow attribute is controlled by the Local Network Access for Embedded Content toggle in Portal Settings (General tab). This setting is enabled by default, preserving the existing behavior. Administrators who want to disable the attribute — for example, in deployments where embedded content does not require local network access — can turn off the toggle. When disabled, the allow attribute is omitted from all embedded content iframes.
The allow attribute helps the browser handle LNA preflight checks correctly, but it does not replace browser policy configuration. If your users’ security tools trigger LNA restrictions, your IT team should still configure LocalNetworkAccessAllowedForUrls as described in the Solutions for managed environments section.The reverse is also true: browser allowlist policies apply to the top-level site, and Chromium browsers still require the iframe to carry the permissions-policy attribute (unless your IT team has also enabled LocalNetworkAccessPermissionsPolicyDefaultEnabled, which lets iframes inherit the permission). Leave this toggle enabled even after your IT team configures browser policies — disabling it can break embeds for users on Chrome 142+ / Edge 143+ wherever that inheritance policy is not in place.

​
Consider switching to Connected Apps

If your Curator system is currently using Tableau Default or Trusted Tickets for Tableau authentication, switching to Connected Apps may reduce embedding issues related to Local Network Access restrictions. Older authentication methods like Trusted Tickets involve multiple redirects between Curator, Tableau Server, and your identity provider during the embed process. Each redirect is an opportunity for the browser to detect a local network request and apply LNA restrictions, especially when security tools like Zscaler intercept those redirects. Connected Apps use a JWT-based authentication flow that authenticates directly with Tableau without intermediate redirects or local network interactions during the auth handshake. This significantly reduces the chance that LNA restrictions will be triggered during the embed process.

​
Additional vendor-specific guidance

If you’ve identified which security tool is causing the issue, these vendor guides may help your IT team configure both the browser policies and the security tool itself: