So CLOUD-12835 - Guidance for the local network access request for our Atlassian cloud explains:
Around Chrome v142, Google introduced a new Local Network Access (LNA) permissions model. The key ideas: Any page (or iframe) that talks to local / private IPs (e.g. localhost, 127.0.0.1, 192.168.x.x, corporate RFC1918 ranges, device UIs, etc.) is now gated by an explicit permission. https://developer.chrome.com/blog/local-network-access
Around Chrome v142, Google introduced a new Local Network Access (LNA) permissions model. The key ideas:
https://developer.chrome.com/blog/local-network-access
My users and I have seen this, I guess because at work we use the 10.0.0.0 space.
What I'm curious about is, what is Atlassian doing that is triggering this?
Yes, I suppose I could open a ticket, but maybe there's some networking experts out here? I'm also posting because as this version of Chrome starts rolling out more widely, I'm sure others may come across this issue.
Hello @Darryl Lee
That prompt is super specific and it’s easy to blame “we use 10.0.0.0 at work”, but that’s not what Chrome is reacting to.
Chrome’s LNA prompt fires when the page (or something embedded in it) tries to make a request to a private address: 10.x, 192.168.x, 172.16–31.x, or localhost. It’s not about your client IP being private, it’s about the destination of a fetch/XHR/img/iframe being private.
So the real question becomes: what on a Jira page would ever call a private IP? In my experience it’s usually one of these:
An embedded app iframe (Marketplace / Connect / Forge) calling back to an internal service (CMDB, internal API, proxy, etc.). The browser attributes the prompt to the top-level origin (*.atlassian.net), so it looks like “Atlassian wants LAN access” even though the call may be coming from an embedded app.
Smart Links / embedded content pointing to internal URLs. One internal wiki page, image, iframe, or link preview to http://10.x... can trigger it when Jira tries to render/preview.
Browser extensions that enhance Jira and talk to localhost/internal endpoints. Seen this more than once.
Fastest way to confirm: open DevTools -> Network, reload, and filter for 10. / 192.168 / 172.16 / localhost. The request and the Initiator will tell you immediately whether it’s core Jira, an embedded app, a Smart Link, or an extension.
Practical guidance I’d give users:
If you don’t rely on internal integrations from Jira, Block is fine, Jira keeps working.
If you do, figure out what is triggering it first, then you can make a conscious call whether Allow is needed for that specific integration.
If you can share what endpoint shows up in the Network tab (even just the private IP/host and the initiator), I’m pretty sure we can pinpoint the exact trigger quickly.
Amazing answer! I'm looking forward to the reply what causes this in case I ever come across it.
@Philipp Sendek
This topic is really interesting. Besides administering, developing internally, and migrating Atlassian products, I also work in IT infrastructure and support. It’s always great when you can combine knowledge across areas. And to be honest, administering and developing Atlassian tools internally is increasingly moving toward system engineering rather than ‘just’ administration.
Thanks @Arkadiusz Wroblewski - awesome answer indeed.
Yes, I knew it wasn't just because we're on 10.0.0.0, however it would be interesting to know if it happens when users are not on designated "private" networks.
I know a little bit about CORS issues (mainly because after we moved to cloud, all of the Confluence iframe embeds that previously worked because internal sites were in all in the same domain broke. Yes, I know they finally fixed CLOUD-6999 but of course that was literally 3 months after our migrated.)
But I don't quite understand how *.atlassian.net" translates to LAN access. That still seems like an external address to me.
Interesting discussion here. Hrm, I wonder if we have something doing HTTPS traffic interception/rerouting.
https://support.google.com/chrome/a/thread/384022238/cors-issue-with-version-142-but-not-in-version-141?hl=en
It looks like you're new here. Sign in or register to get started.
