> ## Documentation Index
> Fetch the complete documentation index at: https://docs.curator.interworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Chrome and Edge Embedding Issues (Local Network Access)

> Troubleshoot embedded content that fails to load in Chrome 142+ or Edge 143+ due to Local Network Access restrictions

> [!NOTE]
>
> 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](#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](#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.

> [!WARNING]
>
> 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.

> [!WARNING]
>
> **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](#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](https://developer.chrome.com/blog/local-network-access)
and [Tableau's documentation](https://help.salesforce.com/s/articleView?id=005228129\&language=en_US\&type=1).

***

## Symptoms

![Example error message](https://mintcdn.com/interworks/_6bZwZCU9DQSfvhE/assets/images/embedding_using_analytics/tableau_dashboards/unknown-auth-error.png?fit=max\&auto=format\&n=_6bZwZCU9DQSfvhE\&q=85\&s=9781ee6d7770e7e6dbab8f464849dac4)

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](https://developer.chrome.com/release-notes/142#local_network_access_restrictions)) and Edge 143
([release notes](https://learn.microsoft.com/en-us/microsoft-edge/web-platform/release-notes/143#local-network-access-from-non-secure-contexts))
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:

* **[Zscaler Client Connector or ZPA](https://trust.zscaler.com/posts/26216)** - Uses IP range `100.64.0.0` and higher
  for internal routing
* **[Duo Desktop](https://help.duo.com/s/article/9470)** - Runs a local helper service
* **[Okta FastPass](https://support.okta.com/help/s/article/configure-chrome-to-suppress-the-local-network-access-prompt-for-okta-fastpass)**
  \- Uses local authentication components
* **[Box Tools](https://support.box.com/hc/en-us/articles/45163820905107)** - Connects to local services
* **Other DLP or endpoint security agents** - May expose local HTTP services

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](https://chromeenterprise.google/policies))
using your management platform (Group Policy, Jamf, Intune, etc.).

**Key policies** ([atomic group documentation](https://chromeenterprise.google/policies/atomic-groups)):

* `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)

#### Recommended fix for Zscaler and other carrier-grade NAT tools

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:

```json theme={null}
{
  "LocalNetworkAccessIpAddressSpaceOverrides": [
    "100.64.0.0/10=public",
    "[fc00::6440:0]/112=public"
  ]
}
```

These are the exact values [Zscaler's own advisory](https://trust.zscaler.com/posts/26216) 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.

> [!WARNING]
>
> 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:

```json theme={null}
{
  "LocalNetworkAccessAllowedForUrls": [
    "https://your-curator-domain.com",
    "https://your-tableau-server.com"
  ]
}
```

> [!NOTE]
>
> 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.

> [!NOTE]
>
> 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](#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:**

> [!WARNING]
>
> 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](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-policies)) that work the same way.

**Key policies:**

* [`LocalNetworkAccessRestrictionsEnabled`](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/localnetworkaccessrestrictionsenabled)
  \- Enable or disable the restriction
* [`LocalNetworkAccessAllowedForUrls`](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/localnetworkaccessallowedforurls)
  \- Allowlist specific domains
* [`LocalNetworkAccessIpAddressSpaceOverrides`](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/localnetworkaccessipaddressspaceoverrides)
  (Edge 146+) - Reclassify IP ranges (e.g., `100.64.0.0/10=public` for Zscaler's carrier-grade NAT range)
* [`LocalNetworkAccessPermissionsPolicyDefaultEnabled`](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/localnetworkaccesspermissionspolicydefaultenabled)
  (Edge 146+) - Let iframes inherit the permission granted to allowlisted top-level sites
* [`LocalNetworkAccessRestrictionsTemporaryOptOut`](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/localnetworkaccessrestrictionstemporaryoptout)
  \- Temporary opt-out (available until after Edge 156)

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](https://learn.microsoft.com/en-us/deployedge/ms-edge-local-network-access).

#### 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:**

> [!WARNING]
>
> 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.

> [!WARNING]
>
> 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.

> [!WARNING]
>
> **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](#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.

> [!NOTE]
>
> 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](#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:

* **Tableau:** [Embedded Tableau views fail to load after Chrome 142](https://help.salesforce.com/s/articleView?id=005228129\&language=en_US\&type=1)
* **Zscaler:** [Chrome 142 Local Network Access Advisory](https://trust.zscaler.com/posts/26216)
* **Duo Desktop:** [Chrome 142 and Edge 143 Changes](https://help.duo.com/s/article/9470)
* **Okta FastPass:**
  [Configure Chrome for Local Network Access](https://support.okta.com/help/s/article/configure-chrome-to-suppress-the-local-network-access-prompt-for-okta-fastpass)
* **Box Tools:** [Allow Local Network Access in Chrome and Edge](https://support.box.com/hc/en-us/articles/45163820905107)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.