Status: Informational / Action Recommended

Applies to: Zscaler Private Access (ZPA) 

What is changing?

Google is enabling a new Local Network Access (LNA) permission in Chrome 142. When a web page (a public origin) tries to talk to something Chrome thinks is on the local / non-public network, Chrome will now show a banner like:

“Look for and connect to any device on your local network?”

If the user clicks Block, Chrome will stop that page from reaching the target. This is a browser change, not a Zscaler change. It is designed to reduce CSRF attacks against local devices and stop local-network fingerprinting. 

Chrome’s implementation considers requests from a public site to certain non-public address spaces as “local.” In our internal testing, requests destined for synthetic IP addresses used by ZPA 100.64.0.0/10 (RFC 6598 shared address space) can also hit this new prompt. If the user chooses Block, the browser will not complete the connection, and the ZPA application will fail to load, preventing access to private applications.

Customer impact

• Who is affected:
  • End users on Chrome 142 and new browsers on all supported Operating Systems accessing ZPA private web-based applications which use the 100.64.0.0/10 synthetic address.
  • Environments where ZPA is used from an in-browser workflow (for example: a SaaS page, IT portal, or ZPA-fronted web app that causes the browser to talk to a ZPA IP).
• What users will see:
  • A new browser popup requesting permission to connect to any device on the local network..
  • If the user hits Block, the ZPA app (or part of it: helper, download, client-side call) will fail – typical symptoms are: page never loads, inline tool fails to launch, console shows a network error, or the app behaves as if ZPA isn’t reachable.
• Why this matters for ZPA:
  • ZPA uses a predictable, non-Internet-routable range (100.64.0.0/10). Chrome’s new LNA logic is conservative and may treat this as “local,” so user choice becomes part of app reachability.
  • A single Block on first prompt can persist as a site permission, so all later ZPA calls from that origin will also fail until the permission is cleared. 

Zscaler services/products impacted

ZPA – private applications delivered via Zscaler that resolve or are reached over 100.64.0.0/10.

Not impacted: ZIA, ZDX, and Internet-bound traffic are not affected by this Chrome feature.

What Zscaler is doing

Monitoring the Chrome 142 rollout and validating the exact address-space matching behavior for 100.64.0.0/10 across OS’s and managed/unmanaged Chrome.

What customers should do now (action required)

• Pre-allow Zscaler/ZPA origins in Chrome/Edge policy
  • Chrome / Chromium: use the enterprise policy group “Local Network Access settings → Allow sites to make requests to local network endpoints.” Chrome configuration parameter and examples.
  • Add the corporate origins that host your ZPA-fronted apps / portals (for example: your SSO page, your internal app portal, or any domain that, when loaded, triggers a call to 100.64.0.0/10).
  • This stops Chrome from asking the user, so ZPA traffic won’t be blocked by user choice. 
• Tell users to click “Allow”
  • Publish a short comms note: “If Chrome asks to connect to your local network while you’re opening corporate/ZPA apps, click Allow. Clicking Block can break the app.”
  • Include a screenshot of the prompt (from the Chrome blog). 
• If someone already clicked Block:
  • Ask them to go to chrome://settings/content/localNetworkAccess and remove the deny entry for your corporate origin; reload and approve. (Same path in Edge: edge://settings/content/localNetworkAccess.) 
• Test ahead of time
  • On a pilot device, set the flag (Chrome 138+) to force LNA and verify that your ZPA app still works after allowing. This mirrors what Google recommends. 
• For unmanaged / BYOD users:
  • Include the above instructions in your ZPA onboarding or in your IT service portal so the first prompt doesn’t lead to a support ticket.

FAQ

Q: Why is Chrome treating 100.64.0.0/10 like it’s local?

Because Chrome 142 is protecting any traffic it thinks is going to a non-public / non-Internet endpoint. ZPA intentionally uses an RFC 6598 shared address space (100.64.0.0/10) that isn’t routed on the Internet, so it ends up looking like a “local” destination to the browser. This is expected with LNA. 

Q: Can Zscaler bypass this in the cloud?

No. This is enforced in the user’s browser before the request is sent. Only the browser (or the enterprise policy that manages it) can allow it. Zscaler will continue to deliver the app once the browser sends the traffic.

Q: Is there a short-term workaround?

Yes. Centrally allow the relevant origins; or instruct users to Allow; or (temporarily) stay on Chrome 141 while you roll out policy. Long-term, Google’s direction is clearly to keep LNA on.