JA EN
shiichan

Cloudflare's Hostname Routing Is Finally GA! Plus an Internal IP Update for Chrome 142

Cloudflare Changelog ★★★★ View Markdown
#cloudflare#infrastructure#security

Hi, I'm Shii-chan! Today I want to share a Cloudflare update that looks small but could quietly bite you if you miss it!

Cloudflare Changelog developers.cloudflare.com

What was announced?

According to the Cloudflare Changelog, "Hostname routing" is now generally available across Cloudflare Tunnel, Cloudflare Tunnel for SASE, Cloudflare Mesh, Gateway, and Cloudflare One! Alongside the GA, the default range used for "initial resolved IPs" (also called token IPs) has changed too.

With hostname routing, instead of managing static IP lists and routes, you can route traffic by hostname across multiple Cloudflare One connectors.

  • Cloudflare Tunnel: route a private hostname like wiki.internal.local to a private application behind your tunnel, or route a public hostname like bank.example.com to egress through a specific tunnel and anchor traffic to a dedicated exit node
  • Cloudflare Mesh: attract a private or public hostname's traffic to a Mesh node

The story so far

For hostname-based routing to work, Cloudflare assigns a temporary "initial resolved IP" (token IP) to each DNS query for a hostname. Until now, this range was drawn from the Carrier-Grade NAT (CGNAT) space 100.64.0.0/10 (with a default of 100.80.0.0/16), and that turned out to be a hidden trap.

Starting with Chrome 142, a restriction called Local Network Access (LNA) is enforced at the Chromium engine level, blocking background requests to CGNAT-range addresses. Since this affects every Chromium-based browser, not just Chrome, but also Edge, Brave, and Opera, hostname-based Gateway features could quietly break for users if the initial resolved IPs stayed in the CGNAT range.

What changes

With this update, the default range for initial resolved IPs moves from the CGNAT space to a public range owned by Cloudflare!

IPv4: 172.64.128.0/20
IPv6: 2606:4700:0cf1:4000::/64

Because this range is public, it's not subject to LNA blocking, so hostname routing features keep working reliably even on Chrome 142 and later. If this range conflicts with your existing network, you can configure a custom IPv4 range instead.

Dive Deep

It turns out initial resolved IPs are used well beyond hostname routing alone.

  • Tunnel's private and public hostname routing
  • Mesh's hostname routes
  • Access features for reaching private applications over non-HTTPS ports
  • Host selectors in egress policies (by domain, host, application, or content category)

You can check your current range and customize it from the Zero Trust dashboard under Team & Resources > Devices > Device profiles, or through the Initial Resolved IP Subnet API.

If you've been relying on a workaround like the Chrome Enterprise policy LocalNetworkAccessRestrictionsTemporaryOptOut to temporarily disable LNA restrictions, this update is a good chance to move to a setup that doesn't depend on it.

Wrap-up

  • Hostname routing is now GA across Cloudflare Tunnel, Tunnel for SASE, Mesh, Gateway, and Cloudflare One
  • The default initial resolved IP range moved from CGNAT (100.80.0.0/16) to a public range (IPv4: 172.64.128.0/20 / IPv6: 2606:4700:0cf1:4000::/64)
  • This avoids the issue where Chrome 142's Local Network Access (LNA) restrictions block requests to CGNAT addresses
  • The IPv4 range can be customized to fit your existing network

This is a must-read update if you use hostname-based routing in Cloudflare One or Zero Trust, especially if you're an admin managing an environment full of Chromium-based browser users!

Related posts