Updated for Chrome 146:
Chrome 146 introduces the LocalNetworkAccessIpAddressSpaceOverrides policy, which provides a simpler, more targeted solution for Jamf ZTNA deployments than the other workarounds described in this article.
Jamf recommends migrating to the new policy which is described in Option 1 below. Customers running Chrome 142–145 should continue to use Option 2 or Option 3.
Overview
This article explains and provides a workaround for Jamf Trust ZTNA users seeing security prompts in Chrome when browsing certain websites.
Who is affected?
This issue affects users running Chrome version 142 or later. The preferred solution mentioned below requires Chrome 146 or later.
The prompt appears when Chrome detects local network access, specifically when a public website loads resources routed through your Jamf Trust ZTNA Access Policies (via IPSec tunnels or Shared/Dedicated Internet Gateways).
Note: Since this is a generic Google Chrome feature, this behavior may also occur on sites without a ZTNA policy. Those pages likely do not follow the best practices defined by Google.
Why is this happening?
Common scenario:
A user visits a public website (like gmail.com) and that site tries to load content from a CDN or resource protected by a ZTNA Access Policy. Chrome treats this as a public site accessing a "local" resource and triggers the security prompt.
This behavior is part of Chrome's Local Network Access (LNA) feature, which states: "For the first milestone of Local Network Access, we consider a 'local network request' any request from the public network to a local network or loopback destination."
Detailed explanation:
Jamf ZTNA works by routing your traffic through a secure WireGuard tunnel using specific IP address ranges (IPv6: [fd53:1c5a::]/32=public, IPv4: 10.240.0.0/14). When you try to access a ZTNA-protected resource, Jamf returns a unique IP address from this range to route your traffic securely through the tunnel.
However, this IPv6 range falls within a larger address space (fc00::/7) that Chrome's Local Network Access feature identifies as "local" or "private" network addresses. This causes Chrome to interpret requests to ZTNA-protected resources as requests to a local network, even though they're actually going to legitimate, protected cloud resources.
The result:
Chrome triggers its security prompt as a precaution.
Chrome 146 Update:
Chrome 146 extends Local Network Access enforcement to WebRTC connections in addition to HTTP(S) requests. This may affect applications that use browser-based media, peer-to-peer features, or real-time communication routed through ZTNA-protected resources. All workarounds described in this article cover WebRTC connections when correctly applied.
Solutions
If a web application containing Jamf Access Policy-protected assets fails to load or function correctly, there are several possible workarounds.
Workflow Options | Chrome Versions | Notes |
Chrome 146 or later | Preferred solution if your organization can update versions. | |
Chrome 142-145 | Preferred solution if still using an older Chrome version. | |
Chrome 142-145 | Preferred solution if still using an older Chrome version. | |
Chrome 142-145 | Deprecated in Chrome 146. Quick fix but security tradeoff. | |
Chrome 142-146 | Quick permanent solution with security tradeoff |
Option 1: Use the LocalNetworkAccessIpAddressSpaceOverrides Chrome enterprise policy
Use the steps below to leverage the LocalNetworkAccessIpAddressSpaceOverrides Chrome enterprise policy with Chrome 146+ to instruct Chrome to treat the Jamf ZTNA address spaces (IPv6: [fd53:1c5a::]/32=public, IPv4: 10.240.0.0/14) as public. This eliminates LNA prompts and CORS preflight failures for all ZTNA-brokered traffic without modifying individual access policies or allowlists.
In Jamf Pro, navigate to Computers > Configuration profiles and click New.
Enter a name for the profile (for example, Chrome – ZTNA LNA Override).
Select the Application & Custom Settings payload and choose Upload.
Click +Add in the upper-right corner and enter
com.google.Chromeas the preference domain.Upload or paste the following PLIST content:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyLists-1.0.dtd">
<plist version="1.0">
<dict>
<key>LocalNetworkAccessIpAddressSpaceOverrides</key>
<array>
<string>[fd53:1c5a::]/32=public</string>
<string>10.240.0.0/14=public</string>
</array>
</dict>
</plist>Click Scope and add your target computers to the scope.
Click Save.
On a managed device, open Chrome and navigate to chrome://policy. Confirm
LocalNetworkAccessIpAddressSpaceOverridesis listed with Status: OK.
Note - The policy won’t take effect until the browser is fully restarted. So if end users are still seeing the prompt after the PLIST above is deployed, a browser reboot is required.
Option 2: Add resources violating CORS into your Access Policy
Open the affected application in Chrome browser.
Open Chrome Developer Console.
macOS: Press
Cmd + Option + JWindows/Linux: Press
Ctrl + Shift + J
Look for CORS error messages in the Console tab. They typically look like:
Access to script at 'https://[external-domain]' from origin 'https://[app-domain]' has been blocked by CORS policy: Permission was denied for this request to access the unknown address space.
Identify the blocked domain from the error message.
This is the domain shown in the 'Access to script at' portion.
Add the blocked domain to your Access Policy.
Include the appropriate wildcard pattern.
Consider if related domains might also be needed.
Make sure the Access Policy is set to Encrypt and route via ZTNA as per point 14 of Adding a New Custom Application.
Test the application to verify it now loads correctly.
Note: Some applications load resources from multiple external domains. You may need to repeat steps 3-5 if additional CORS errors appear.
Specific Example
Specific Example
Your company has domain *.atlassian.net routed via Access Policy and Jira Agile Poker does not load.
Open Jira Agile Poker via Chrome
Open the Developer Console
macOS: Press
Cmd + Option + J on macOSWindows/Linux: Press
Ctrl + Shift + J
Look for errors such as:
Problematic domain is
agile-poker-global.appfire.appAdd
*.appfire.cominto your Jira Access Policy.Page should load correctly now.
Option 3: Configure Chrome allowed URLs for domains that violate CORS policy
Open the affected application in Chrome browser.
Open Chrome Developer Console.
macOS: Press
Cmd + Option + JWindows/Linux: Press
Ctrl + Shift + J
Look for CORS error messages in the Console tab. They typically look like:
Access to script at 'https://[external-domain]' from origin 'https://[app-domain]' has been blocked by CORS policy: Permission was denied for this request to access the unknown address space.
Identify the blocked domain from the error message.
This is the domain shown in the 'Access to script at' portion.
Create Chrome Enterprise Policy or MDM configuration profile with Allowed URLs for Chrome.
Include the appropriate wildcard pattern.
Consider if related domains might also be needed.
Chrome Enterprise Policy within Google Admin
In the Chrome Enterprise Core go to Chrome Browser > Custom Configurations.
Select the target organizational unit.
In Configurations, add the following JSON configuration (replace with your URLs):
{
"LocalNetworkAccessAllowedForUrls": [
"https://externaldomain.com",
"https://[*.]externalwildacarddomain.com"
]
}Click Save.
Open chrome://policy and click Reload policies to confirm values apply.
Configuration profile for MDMs
Create plist configuration file and push this via MDM such as Jamf Pro to the machines with affected Chrome browser:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>LocalNetworkAccessRestrictionsEnabled</key>
<true/>
<key>LocalNetworkAccessAllowedForUrls</key>
<array>
<string>https://externaldomain.com</string>
<string>https://[*.]externalwildacarddomain.com</string>
</array>
</dict>
</plist>
Test the application to verify it now loads correctly.
Note: Some applications load resources from multiple external domains. You may need to repeat steps 3-5 if additional CORS errors appear.
Option 4: Disable LNA completely
⚠️ Warning: The LocalNetworkAccessRestrictionsTemporaryOptOut policy that may have been referenced as a quick workaround is removed in Chrome 146.
If your deployment uses this policy, migrate to Option 1 (LocalNetworkAccessIpAddressSpaceOverrides) or Option 2 before upgrading managed devices to Chrome 146.
You can create a plist with LocalNetworkAccessRestrictionsTemporaryOptOut. When this policy is set to Enabled, Local Network Access requests will only display warnings in Chrome DevTools due to Local Network Access checks failing. This Chrome policy can be managed through Admin console, or though an MDM configuration profile, detailed below.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>LocalNetworkAccessRestrictionsTemporaryOptOut</key>
<true/>
</dict>
</plist>
Security Trade-off: This workaround reduces your security protection by letting public websites access resources on your local network. While this creates some risk, it restores the same access level you had before Chrome's recent security update.
Option 5: Use * policy (quick permanent solution with security tradeoff)
Using * for the LocalNetworkAccessAllowedForUrls will effectively disable it. This Chrome policy can be managed through Admin console, or though an MDM configuration profile, detailed below.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>LocalNetworkAccessRestrictionsEnabled</key>
<true/>
<key>LocalNetworkAccessAllowedForUrls</key>
<array>
<string>*</string>
</array>
</dict>
</plist>
Security Trade-off: This workaround reduces your security protection by letting public websites access resources on your local network. While this creates some risk, it restores the same access level you had before Chrome's recent security update.
More Resources