Why does Atlassian want to access to other devices on my local network?

[Darryl Lee]

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

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.

[Arkadiusz Wroblewski · Accepted solution]

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.

[Philipp Sendek]

Amazing answer! I'm looking forward to the reply what causes this in case I ever come across it.

[Arkadiusz Wroblewski]

@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.

[Darryl Lee]

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

[Arkadiusz Wroblewski]

@Darryl Lee 

You’re thinking in the right direction.

*.atlassian.net is still 100% an external address. There’s nothing “LAN” about it by itself. When Chrome talks about “private network” behavior, it’s usually about what the browser detects in the request path, not the literal hostname.

And that’s where your suspicion makes sense: HTTPS interception / SSL inspection / corporate proxy can make a public request behave like it’s going through an internal/private hop. If something is terminating TLS and reissuing traffic (or routing through an internal proxy/VPN path), Chrome can start applying stricter rules and you get weird, inconsistent CORS-ish symptoms that vary by network.

So the fastest way to sanity-check it isn’t debating the domain, it’s testing the path:

Try the same thing off-network (mobile hotspot / home Wi-Fi). If it works there, it’s almost certainly the corporate proxy/VPN layer.

Check dev tools Network/Security:

if you see cert differences or headers that hint at a security appliance, that’s another strong signal.

Ask your network/security folks directly: “Are we doing SSL inspection for Atlassian domains?” That’s often the smoking gun.

So yeah… Atlassian didn’t become “LAN”. Your network can make it look that way to the browser, and modern Chrome versions are getting more aggressive about it.