Requests resolving differently within a network getting blocked

[RivenSkaye]

At $employer we host one subdomain from an on-site server, that within the local network gets resolved to its local address (e.g. 192.168.60.42). Our normal website will sometimes load images from this subdomain, which gets blocked by Chrome when viewing the page from within the network. For all intents and purposes, this is a normal domain getting resolved (subdomain.example.com). Because it resolves to a local address, Chrome immediately blocks the request and prompts the user. For non-technical employees this raises questions (and sometimes seems alarming).

Once the popup appears, the <img> element's onerror handler will always be run, even when permission is granted. This raises even more questions as the image elements go from an empty square into an error/broken image state and it is entirely invisible to the user what the LAN access request is for then.

Perhaps it'd make sense to exclude (other) subdomains of the current domain from getting flagged for this¹, or to not block in situations where CORS would allow the GET request and the MIME type is e.g. image/* or similar. To prevent letting the initial request go through with whatever side effects this has, possibly consider making a HEAD² request to the resource to check this.

¹: considering example.com as before, allow any directionality between *.example.com, example.com, very.deeply.nested.subdomain.example.com, so long as the domain portion itself is the same.
²: Output of a HEAD request for one of the affected files:

HTTP/2 200
content-length: 71542
content-type: image/jpeg
last-modified: Mon, 21 Nov 2022 20:00:00 GMT
accept-ranges: bytes
etag: "0602bd6e3fdd81:0"
server: REDACTED
date: Fri, 05 Dec 2025 10:37:08 GMT

Assuming the local resource is not compromised (LAN Access is aimed at protecting local resources after all), it should be fair to assume it reports honest data. Resources not supporting HEAD requests might need different handling (fall back to matching the request URI? Or display the popup as the resource cannot be verified?)

[hubertchao]

Once the popup appears, the <img> element's onerror handler will always be run, even when permission is granted. This raises even more questions as the image elements go from an empty square into an error/broken image state and it is entirely invisible to the user what the LAN access request is for then.

This is interesting and I haven't heard that before. Are you saying that if the permission prompt appears, the image never loads even if the permission is granted (and therefore to load the image properly requires the user to reload the page)?

Perhaps it'd make sense to exclude (other) subdomains of the current domain from getting flagged for this¹, or to not block in situations where CORS would allow the GET request and the MIME type is e.g. image/* or similar.

¹: considering example.com as before, allow any directionality between *.example.com, example.com, very.deeply.nested.subdomain.example.com, so long as the domain portion itself is the same.

Consider a public page thisissafe.com, which is loaded through a public IP, then then say loads a tracking pixel from tracking.thisissafe.com which DNS resolves to a local IP (or even to localhost). This matches your usage, but would result in a LNA request bypassing the permission prompt. This could even happen with the tracking pixel being on the same domain as the public page (via DNS rebinding attacks).

To prevent letting the initial request go through with whatever side effects this has, possibly consider making a HEAD² request to the resource to check this.

How would this be different from the preflight requests from PNA?

[RivenSkaye]

This is interesting and I haven't heard that before. Are you saying that if the permission prompt appears, the image never loads even if the permission is granted (and therefore to load the image properly requires the user to reload the page)?

That's exactly what was happening for me on latest Chrome, yes. It seems like the popup preventing the media load is already triggering something that resembles an error enough to trigger it. Next chance I get I'll try and dump whatever it is that the handler receives.

Consider a public page thisissafe.com, which is loaded through a public IP, then then say loads a tracking pixel from tracking.thisissafe.com which DNS resolves to a local IP (or even to localhost). This matches your usage, but would result in a LNA request bypassing the permission prompt. This could even happen with the tracking pixel being on the same domain as the public page (via DNS rebinding attacks).

DNS rebinding is a factor I hadn't considered yet. That indeed makes sense to want to prevent.

How would this be different from the preflight requests from PNA?

Good question, I'm not very familiar with either spec personally. A quick look makes this indeed seem just as abusable simply by doing something else with a HEAD than with GET. Scratch that suggestion I suppose.

[christhompson]

Yeah DNS rebinding attacks are a big one (or not even rebinding -- a public evil.com shouldn't be able to make requests to your local network just because they use will-point-to-known-vulnerable-or-colluding-address.evil.com) that makes it hard or impossible to distinguish.

Because it resolves to a local address, Chrome immediately blocks the request and prompts the user. For non-technical employees this raises questions (and sometimes seems alarming).

If you are able to use enterprise policy (i.e., either the machines or the profiles are managed) you can use https://chromeenterprise.google/policies/#LocalNetworkAccessAllowedForUrls to auto-grant the permission so employees do not see the prompt.

That's exactly what was happening for me on latest Chrome, yes. It seems like the popup preventing the media load is already triggering something that resembles an error enough to trigger it. Next chance I get I'll try and dump whatever it is that the handler receives.

I tried some toy examples and couldn't repro in Chrome Stable or Beta. If you are able to repro or share more details, please file a Chromium bug (we can also restrict visibility after you file if you need to share non-public information for us to investigate), since this sounds like it is probably Chromium-specific.