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 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 behaviour 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 a specific IPv6 address range (fd53:1c5a::/32). 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.
Solutions
If a web application containing Jamf Access Policy-protected assets fails to load or function correctly, there are four possible workarounds.
Option 3: Disable LNA completely (quick temporary solution with security tradeoff)
Option 4: Use * policy (quick permanent solution with security tradeoff)
Option 1: Add resources violating CORS into your Access Policy (recommended)
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 2: Configure Chrome allowed URLs for domains that violate CORS policy (recommended)
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 3: Disable LNA completely (quick temporary solution with security tradeoff)
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>
⚠️ This enterprise policy is temporary, and will be removed after M146.
⚠️ 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 4: 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