diff --git a/src/components.ts b/src/components.ts index 593f5bea3f8..3a8b15a58a1 100644 --- a/src/components.ts +++ b/src/components.ts @@ -82,3 +82,4 @@ export { default as ResourcesBySelector } from "./components/cf/ResourcesBySelec export { default as SubtractIPCalculator } from "./components/react/SubtractIPCalculator"; export { AgentPrimitivesDiagram } from "./components/react/diagram-showcase/AgentPrimitivesDiagram"; export { default as MeshHostnameRoutingDiagram } from "./components/cf/MeshHostnameRoutingDiagram.astro"; +export { default as TunnelHostnameRoutingDiagram } from "./components/cf/TunnelHostnameRoutingDiagram.astro"; diff --git a/src/components/cf/MeshHostnameRoutingDiagram.astro b/src/components/cf/MeshHostnameRoutingDiagram.astro index cfdf099e841..5a3579f46c9 100644 --- a/src/components/cf/MeshHostnameRoutingDiagram.astro +++ b/src/components/cf/MeshHostnameRoutingDiagram.astro @@ -45,7 +45,7 @@ import { Icon as AstroIcon } from "astro-icon/components"; IP.

- 100.80.0.0/16 + 172.64.128.0/20
diff --git a/src/components/cf/TunnelHostnameRoutingDiagram.astro b/src/components/cf/TunnelHostnameRoutingDiagram.astro new file mode 100644 index 00000000000..c20ac39af4b --- /dev/null +++ b/src/components/cf/TunnelHostnameRoutingDiagram.astro @@ -0,0 +1,302 @@ +--- +/* `role="list"` on the `
    ` below is intentional, not redundant: Safari + + VoiceOver drop the implicit list role when `list-style: none` is + applied, so the explicit role is required to preserve list semantics + for screen reader users. */ +/* eslint-disable astro/jsx-a11y/no-redundant-roles */ +import { Icon as AstroIcon } from "astro-icon/components"; +--- + +
    +
      +
    1. +
      +
      + + Client device +
      +

      + Requests wiki.internal.local +

      +
      +
      2. + +
    2. + DNS query + +
      3. + +
    3. +
      +
      + + Cloudflare Gateway +
      +

      + Returns a token IP, then rewrites the destination to the real IP. +

      +
      + 172.64.128.0/20 +
      +
      +
      4. + +
    4. + Hostname route + +
      5. + +
    5. +
      +
      + + Cloudflare Tunnel +
      +

      + Forwards traffic to your private network, or egresses it to the public + Internet +

      +
      +
      6. + + + +
    6. +
      +
      + + Private host +
      +

      + wiki.internal.local · 10.0.0.50 +

      +
      +
      7. +
    +
    + + diff --git a/src/content/changelog/tunnel/2026-08-12-hostname-routing-ga-public-initial-resolved-ips.mdx b/src/content/changelog/tunnel/2026-08-12-hostname-routing-ga-public-initial-resolved-ips.mdx new file mode 100644 index 00000000000..7e7b28fd0e7 --- /dev/null +++ b/src/content/changelog/tunnel/2026-08-12-hostname-routing-ga-public-initial-resolved-ips.mdx @@ -0,0 +1,39 @@ +--- +title: Hostname routing is now generally available, with a new public IP range for initial resolved IPs +description: Hostname routing is now GA. Initial resolved IPs are moving to a public Cloudflare IP range instead of CGNAT, resolving a conflict with Chromium's Local Network Access restrictions. +products: + - tunnel + - cloudflare-tunnel-sase + - mesh + - gateway + - cloudflare-one +date: 2026-08-12 +--- + +import { DashButton, Render, GlossaryTooltip } from "~/components"; + +[Hostname routing](https://blog.cloudflare.com/tunnel-hostname-routing/) is now generally available. 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](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname/) (for example, `wiki.internal.local`) to a private application behind your tunnel, or a [public hostname](/cloudflare-one/traffic-policies/egress-policies/egress-cloudflared/) (for example, `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](/cloudflare-one/networks/connectors/cloudflare-mesh/routes/#hostname-routes) to a Mesh node. + +Alongside GA, the default IPv4 range used for initial resolved IPs (also called token IPs) is changing from a Carrier-Grade NAT (CGNAT) range to a public Cloudflare-owned range: + + + +**Why this is changing:** Starting with [Chrome 142](https://developer.chrome.com/release-notes/142), Local Network Access (LNA) restrictions block background requests to CGNAT addresses (`100.64.0.0/10`), which included the previous initial resolved IP default (`100.80.0.0/16`). LNA is implemented at the Chromium engine level, so it affects all Chromium-based browsers (for example, Microsoft Edge, Brave, and Opera), not only Google Chrome. This could silently break hostname-based Gateway features for users of these browsers, and required Chrome Enterprise policy workarounds. The new default range is public Cloudflare address space, so it is not affected by this restriction. + +**What is affected:** Initial resolved IPs are used by several features that associate a DNS query with the network connection that follows it: + +- [Private](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname/) and [public](/cloudflare-one/traffic-policies/egress-policies/egress-cloudflared/) hostname routing for Cloudflare Tunnel +- [Hostname routes](/cloudflare-one/networks/connectors/cloudflare-mesh/routes/#hostname-routes) for Cloudflare Mesh +- [Access private applications](/cloudflare-one/access-controls/applications/non-http/self-hosted-private-app/) on non-HTTPS ports +- [Egress policy host selectors](/cloudflare-one/traffic-policies/egress-policies/host-selectors/) (Domain, Host, Application, and Content Categories) + +**Rollout:** Cloudflare is migrating all accounts to the new default range over the next few days. Once migration is complete, you can check your account's current range, or configure a custom range, at any time from **Networking** > **IP addresses** > **Address space** > **Custom IPs**, or using the [Initial Resolved IP Subnet API](/api/resources/zero_trust/subresources/networks/subresources/subnets/#(resource)%20zero_trust.networks.subnets.initial_resolved_ip). + + + +For full instructions, refer to [Configure initial resolved IPs](/cloudflare-one/networks/routes/configure-initial-resolved-ips/). The IPv6 range (`2606:4700:0cf1:4000::/64`) is unchanged and is not affected by this restriction. + +If you were relying on a Chrome Enterprise policy workaround (such as `LocalNetworkAccessRestrictionsTemporaryOptOut`) while your account was still on the legacy CGNAT-based range, refer to [Google Chrome restricts access to private hostnames](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname/#google-chrome-restricts-access-to-private-hostnames) for next steps. diff --git a/src/content/dash-routes/core-manually-defined.json b/src/content/dash-routes/core-manually-defined.json index 290d9ea725f..12c7c4ca4ac 100644 --- a/src/content/dash-routes/core-manually-defined.json +++ b/src/content/dash-routes/core-manually-defined.json @@ -9,6 +9,11 @@ "name": "Virtual networks", "parent": ["Networking", "Routes"] }, + { + "deeplink": "/?to=/:account/ip-addresses/address-space/custom-ips", + "name": "Custom IPs", + "parent": ["Networking", "IP addresses", "Address space"] + }, { "deeplink": "/?to=/:account/data-catalog/overview", "name": "R2 Data Catalog", diff --git a/src/content/docs/cloudflare-one/access-controls/applications/non-http/self-hosted-private-app.mdx b/src/content/docs/cloudflare-one/access-controls/applications/non-http/self-hosted-private-app.mdx index 0d84ab2aa4c..1f1b8cff27d 100644 --- a/src/content/docs/cloudflare-one/access-controls/applications/non-http/self-hosted-private-app.mdx +++ b/src/content/docs/cloudflare-one/access-controls/applications/non-http/self-hosted-private-app.mdx @@ -48,7 +48,7 @@ This feature replaces the legacy [private network app type](/cloudflare-one/acce :::note - **HTTPS applications**: Private hostnames explicitly set to port `443` (not including port ranges such as `441-444`) must have a valid Server Name Indicator (SNI). - - **Non-HTTPS applications**: Private hostnames on non-`443` ports do not require a valid SNI value will be assigned an initial resolved IP in the CGNAT space. Ensure that the following IP addresses are not blocked by any firewalls or excluded from Gateway traffic: + - **Non-HTTPS applications**: Private hostnames on non-`443` ports do not require a valid SNI value and will be assigned an initial resolved IP. Ensure that the following IP addresses are not blocked by any firewalls or excluded from Gateway traffic: diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-mesh/client-devices.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-mesh/client-devices.mdx index 24a67787ad1..2f9d56c37a4 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-mesh/client-devices.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-mesh/client-devices.mdx @@ -72,7 +72,7 @@ Depending on your Cloudflare networking configuration, you may need to remove ad In Include mode, add the following to your include list: - `100.96.0.0/12` — Mesh IPs (device IPs) -- `100.80.0.0/16` and `2606:4700:0cf1:4000::/64` — Hostname routing (if used) +- `172.64.128.0/20` and `2606:4700:0cf1:4000::/64` — Hostname routing (if used) - Any CIDR routes you have [configured for your Mesh nodes](/cloudflare-one/networks/connectors/cloudflare-mesh/routes/) ## Firewall considerations diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-mesh/routes.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-mesh/routes.mdx index 237e5f5b5c9..1e7ccc8dd7a 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-mesh/routes.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-mesh/routes.mdx @@ -203,7 +203,7 @@ To filter DNS queries from the subnet using [Cloudflare Gateway](/cloudflare-one 3. **Configure Split Tunnels**: Ensure the following IPs route through the Mesh node in your [Split Tunnels](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/split-tunnels/) configuration: - The subnet's internal DNS resolver IP - - Gateway initial resolved IP range: `100.80.0.0/16` (IPv4) and `2606:4700:0cf1:4000::/64` (IPv6) + - Gateway initial resolved IP range: `172.64.128.0/20` (IPv4) and `2606:4700:0cf1:4000::/64` (IPv6) Gateway logs DNS queries with the private source IP of the originating device. You can use this to create [resolver policies](/cloudflare-one/traffic-policies/resolver-policies/) for internal DNS records. @@ -233,7 +233,7 @@ For a deeper look at the packet flow behind hostname routing, refer to the [anno | --------------------------- | --------------- | -------------------------- | | Mesh device IP range | `100.96.0.0/12` | `2606:4700:cf1:1000::/64` | | Cloudflare source IP range | `100.64.0.0/12` | `2606:4700:cf1:5000::/64` | - | Hostname routing (token IPs) | `100.80.0.0/16` | `2606:4700:0cf1:4000::/64` | + | Hostname routing (token IPs) | `172.64.128.0/20` | `2606:4700:0cf1:4000::/64` | - **Remove the hostname's top-level domain from [Local Domain Fallback](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/local-domains/)** on client devices, so the DNS query is sent to Cloudflare Gateway for resolution. @@ -295,7 +295,7 @@ You only need a Gateway [resolver policy](/cloudflare-one/traffic-policies/resol If the DNS server is reached through a Mesh node, you cannot run it on the **same machine** as that node — the node's DNS interface binds port `53`. Host the DNS server on a separate machine in the same private network. In that case, configure return routes on the subnet so the DNS server's responses can reach the client: - **Mesh device IP range**: `100.96.0.0/12` → next hop is the Mesh node's local IP -- **Initial resolved IP range**: `100.80.0.0/16` → next hop is the Mesh node's local IP +- **Initial resolved IP range**: `172.64.128.0/20` → next hop is the Mesh node's local IP ::: diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname.mdx index 68c1f94db38..f2e926b020f 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname.mdx @@ -8,15 +8,15 @@ tags: - Private networks sidebar: order: 2 - badge: - text: Beta --- -import { Render, Details, GlossaryTooltip } from "~/components"; +import { Render, Details, GlossaryTooltip, TunnelHostnameRoutingDiagram } from "~/components"; Instead of managing static IP lists and routes, you can connect users to private HTTP and non-HTTP applications using their hostnames (for example, `wiki.internal.local`). Private hostname routes are especially useful when the application has an unknown or ephemeral IP, which often occurs when infrastructure is provisioned by a third-party cloud provider. -When a user requests a private hostname, Cloudflare Gateway assigns an initial resolved IP from a CGNAT range to route the traffic through your tunnel to the correct private IP address. For a deep dive into the architecture and packet flow, refer to our [announcement blog post](https://blog.cloudflare.com/tunnel-hostname-routing/). + + +When a user requests a private hostname, Cloudflare Gateway assigns an initial resolved IP to route the traffic through your tunnel to the correct private IP address. By default, this IP is drawn from a Cloudflare-owned public IPv4 range (`172.64.128.0/20`) rather than Carrier-Grade NAT (CGNAT) space, so it does not trigger [Google Chrome's Local Network Access restrictions](#google-chrome-restricts-access-to-private-hostnames). You can also [configure a custom range](/cloudflare-one/networks/routes/configure-initial-resolved-ips/) if it conflicts with your existing network. For a deep dive into the architecture and packet flow, refer to our [announcement blog post](https://blog.cloudflare.com/tunnel-hostname-routing/). ## Supported on-ramps/off-ramps @@ -173,7 +173,7 @@ If you cannot connect, verify the following: Non-authoritative answer: Name: wiki.internal.local - Address: 100.80.200.48 + Address: 172.64.128.48 ``` The query should resolve using [WARP's DNS proxy](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/client-architecture/#dns-traffic) and return a Gateway initial resolved IP. If the query fails to resolve or returns a different IP, check your [Local Domain Fallback](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/local-domains/) configuration and [Gateway resolver policies](/cloudflare-one/traffic-policies/resolver-policies/). @@ -189,8 +189,8 @@ If you cannot connect, verify the following: ``` ```sh output - * Trying 100.80.200.48:80... - * Connected to wiki.internal.local (100.80.200.48) port 80 + * Trying 172.64.128.48:80... + * Connected to wiki.internal.local (172.64.128.48) port 80 ... ``` diff --git a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/ssh-device-client.mdx b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/ssh-device-client.mdx index de39e26c533..dbbb436a5d3 100644 --- a/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/ssh-device-client.mdx +++ b/src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/ssh-device-client.mdx @@ -85,7 +85,7 @@ Hostname routes allow you to SSH directly to `ssh.internal.local` without managi When you create a hostname route in Cloudflare Tunnel: 1. Users SSH to your private hostname (for example, `ssh user@ssh.internal.local`). - 2. Gateway resolves the hostname to an initial resolved IP from a CGNAT range. + 2. Gateway resolves the hostname to an initial resolved IP. 3. Traffic routes through the WARP tunnel to Cloudflare. 4. Gateway network policies evaluate the connection. 5. Cloudflared proxies the connection to your SSH server's private IP. @@ -151,7 +151,8 @@ The output should contain the server's private IP address (the **Internal IP** o To connect to private hostnames, Cloudflare One Clients must be configured to forward the following traffic to Cloudflare: -- Initial resolved IPs (CGNAT range: `100.64.0.0/10`) +- Initial resolved IPs: + - DNS queries for your private hostname #### 3.3.1 Configure Split Tunnels @@ -257,7 +258,7 @@ If you cannot connect, verify the following: Non-authoritative answer: Name: ssh.internal.local - Address: 100.80.200.48 + Address: 172.64.128.48 ``` The query should resolve using [WARP's DNS proxy](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/client-architecture/#dns-traffic) and return a Gateway initial resolved IP. If the query fails to resolve or returns a different IP, check your [Local Domain Fallback](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/local-domains/) configuration and [Gateway resolver policies](/cloudflare-one/traffic-policies/resolver-policies/). @@ -274,8 +275,8 @@ If you cannot connect, verify the following: ```sh output ... - Authenticated to ssh.internal.local ([100.80.200.48]:22) using "publickey". + Authenticated to ssh.internal.local ([172.64.128.48]:22) using "publickey". ... ``` - Look for a line showing connection to an IP in the `100.64.0.0/10` range. If the request fails, confirm that the initial resolved IP [routes through the WARP tunnel](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/split-tunnels/). You can also check your [tunnel logs](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/) to confirm that requests are routing to the server's private IP. + Look for a line showing connection to an IP in your account's [initial resolved IP range](/cloudflare-one/networks/routes/reserved-ips/#gateway-initial-resolved-ips). If the request fails, confirm that the initial resolved IP [routes through the WARP tunnel](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/split-tunnels/). You can also check your [tunnel logs](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/) to confirm that requests are routing to the server's private IP. diff --git a/src/content/docs/cloudflare-one/networks/routes/configure-initial-resolved-ips.mdx b/src/content/docs/cloudflare-one/networks/routes/configure-initial-resolved-ips.mdx new file mode 100644 index 00000000000..ab1337451ae --- /dev/null +++ b/src/content/docs/cloudflare-one/networks/routes/configure-initial-resolved-ips.mdx @@ -0,0 +1,92 @@ +--- +pcx_content_type: how-to +description: Configure the IPv4 range Gateway uses to assign initial resolved IPs for hostname-based traffic. +products: + - cloudflare-one +title: Configure initial resolved IPs +sidebar: + order: 4 +--- + +import { CURL, DashButton, Render, Tabs, TabItem, GlossaryTooltip } from "~/components"; + +Initial resolved IPs (also called token IPs) are ephemeral addresses that Gateway assigns to DNS queries so it can associate hostname-based traffic with the correct policy or tunnel at the network layer, where hostname information is not usually available. Refer to [Gateway initial resolved IPs](/cloudflare-one/networks/routes/reserved-ips/#gateway-initial-resolved-ips) for a list of features that depend on this range. + +By default, initial resolved IPs are assigned from: + + + +The IPv6 range is not configurable. + +:::caution +If you configure a custom IPv4 range within Carrier-Grade NAT (CGNAT) address space, this can lead to [Google Chrome's Local Network Access restrictions](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname/#google-chrome-restricts-access-to-private-hostnames), which the public default range avoids. +::: + +## Prerequisites + +- You have the [Cloudflare One Networks Write](/fundamentals/api/reference/permissions/) permission (for API access), or dashboard access to **Networking** > **IP addresses** > **Address space** > **Custom IPs**. +- Your new range does not conflict with existing routes or other reserved [Cloudflare One subnets](/cloudflare-one/networks/routes/reserved-ips/) in your account. + +## Check your current range + + + +1. Go to **Networking** > **IP addresses** > **Address space** > **Custom IPs**. + + + +2. Find the row where **Assign to** is **Initial Resolved IP** to see your account's current IPv4 range. + + + +Send a `GET` request to the [Get Initial Resolved IP Subnet](/api/resources/zero_trust/subresources/networks/subresources/subnets/subresources/initial_resolved_ip/methods/get/) endpoint for the address family you want to check: + + + + + +## Update your range + + + +1. Go to **Networking** > **IP addresses** > **Address space** > **Custom IPs**. + + + +2. Find the row where **Assign to** is **Initial Resolved IP**, select the three dots menu, and select **Edit**. +3. Enter your new IPv4 range and save your changes. + + + +Send a `PUT` request to the [Update Initial Resolved IP Subnet](/api/resources/zero_trust/subresources/networks/subresources/subnets/subresources/initial_resolved_ip/methods/update/) endpoint with your desired network range: + + + + + +The new CIDR must not conflict with existing private routes or other reserved subnets in your account. If it does, the request fails and the response describes the conflicting route or subnet. + +:::note +Only the IPv4 range is configurable. The IPv6 initial resolved IP range (`2606:4700:0cf1:4000::/64`) is fixed and does not need to be changed to resolve Chromium's Local Network Access restrictions, which do not affect IPv6. +::: + +After you change your range, update your [Split Tunnel configuration](/cloudflare-one/networks/routes/reserved-ips/#split-tunnel-configuration) so that traffic to the new range routes through the Cloudflare One Client, and remove the old range if it is no longer used by any other reserved IP purpose. + +Initial resolved IPs have a TTL of approximately 10 minutes. DNS queries resolved before you change your range continue to use the previous range until that TTL expires. After that, new DNS queries receive an initial resolved IP from the new range. diff --git a/src/content/docs/cloudflare-one/networks/routes/reserved-ips.mdx b/src/content/docs/cloudflare-one/networks/routes/reserved-ips.mdx index 90e48086627..8f096ad659a 100644 --- a/src/content/docs/cloudflare-one/networks/routes/reserved-ips.mdx +++ b/src/content/docs/cloudflare-one/networks/routes/reserved-ips.mdx @@ -13,19 +13,21 @@ tags: import SubtractIPCalculator from "~/components/SubtractIPCalculator.tsx"; -Cloudflare reserves several IPv4 and IPv6 ranges for internal routing and service functionality. These ranges are drawn from the CGNAT address space (`100.64.0.0/10`). To avoid routing conflicts, your Cloudflare Tunnel, Cloudflare Mesh, or WAN routes should not include subsets of these reserved ranges. Broader routes that contain a reserved range, such as `0.0.0.0/0`, are unaffected because longest-prefix match ensures the reserved ranges still take priority. +Cloudflare reserves several IPv4 and IPv6 ranges for internal routing and service functionality. Most of these ranges are drawn from the CGNAT address space (`100.64.0.0/10`). [Gateway initial resolved IPs](#gateway-initial-resolved-ips) are the exception, using a public Cloudflare-owned range by default. To avoid routing conflicts, your Cloudflare Tunnel, Cloudflare Mesh, or WAN routes should not include subsets of these reserved ranges. Broader routes that contain a reserved range, such as `0.0.0.0/0`, are unaffected because longest-prefix match ensures the reserved ranges still take priority. When planning your private network addressing and configuring [Split Tunnel](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/split-tunnels/) entries, use the tables below to identify which IP ranges Cloudflare has reserved and whether they can be reconfigured. ## IPv4 ranges -| Name | Default CIDR | Configurable | -| ------------------------------------------------------------- | ---------------- | ------------ | -| [Cloudflare source IPs](#cloudflare-source-ips) | `100.64.0.0/12` | Yes | -| [Gateway initial resolved IPs](#gateway-initial-resolved-ips) | `100.80.0.0/16` | No | +| Name | Default CIDR | Configurable | +| ------------------------------------------------------------- | ------------------- | ------------ | +| [Cloudflare source IPs](#cloudflare-source-ips) | `100.64.0.0/12` | Yes | +| [Gateway initial resolved IPs](#gateway-initial-resolved-ips) | `172.64.128.0/20` | Yes | | [Device IPs](#device-ips) | `100.96.0.0/12` | Yes | | [Private Load Balancer IPs](#private-load-balancer-ips) | `100.112.0.0/16` | Yes | +Unlike the other IPv4 ranges, Gateway initial resolved IPs are drawn from public Cloudflare address space rather than CGNAT (`100.64.0.0/10`) by default. If your account was created before this default changed, or if you configured a custom range, it may still fall within CGNAT space — refer to [Gateway initial resolved IPs](#gateway-initial-resolved-ips). + ## IPv6 ranges | Name | Default CIDR | Configurable | @@ -46,7 +48,7 @@ The default IPv4 range is `100.64.0.0/12`. You can change this to a different `/ ## Gateway initial resolved IPs -Gateway initial resolved IPs are ephemeral addresses used to map hostnames to destination IPs at the network layer, where hostname information is not usually available. +Gateway initial resolved IPs (also called token IPs) are ephemeral addresses used to map hostnames to destination IPs at the network layer, where hostname information is not usually available. The following features use this range: @@ -55,7 +57,9 @@ The following features use this range: - [Egress policy host selectors](/cloudflare-one/traffic-policies/egress-policies/host-selectors/) — evaluates Gateway egress policies using hostname-based selectors. - [Access private applications](/cloudflare-one/access-controls/applications/non-http/self-hosted-private-app/) — manage access to private applications using their private hostnames. -Initial resolved IPs are assigned from the `100.80.0.0/16` (IPv4) or `2606:4700:0cf1:4000::/64` (IPv6) range. This range is not configurable. +Cloudflare assigns initial resolved IPs from the `172.64.128.0/20` (IPv4) or `2606:4700:0cf1:4000::/64` (IPv6) range by default. Unlike earlier CGNAT-based defaults, the IPv4 range is public Cloudflare address space, so it is not affected by [Google Chrome's Local Network Access restrictions](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname/#google-chrome-restricts-access-to-private-hostnames). + +You can configure a custom IPv4 range if the default conflicts with your existing network or private routes. The IPv6 range is not configurable. For instructions, refer to [Configure initial resolved IPs](/cloudflare-one/networks/routes/configure-initial-resolved-ips/). ## Device IPs @@ -76,20 +80,22 @@ For deployments that use the [Cloudflare One Client](/cloudflare-one/team-and-re ### Exclude mode (default) -In **Exclude IPs and domains** mode, the CGNAT range (`100.64.0.0/10`) is excluded from the Cloudflare One Client routing by default. You must delete the [reserved IP ranges](#ipv4-ranges) from your Split Tunnels exclude list, or the associated features will stop working. +In **Exclude IPs and domains** mode, the Cloudflare One Client excludes the CGNAT range (`100.64.0.0/10`) from its routing by default. You must delete the reserved IP ranges that fall within CGNAT space from your Split Tunnels exclude list, or the associated features will stop working. + +[Gateway initial resolved IPs](#gateway-initial-resolved-ips) are the exception: the default range (`172.64.128.0/20`) is public Cloudflare address space, not CGNAT, so it is **not** excluded by default in Exclude mode — no Split Tunnel changes are required for this range. This only applies if you configured a custom initial resolved IP range within CGNAT space. In that case, treat it the same as the other CGNAT-based ranges. Cloudflare recommends adding back the IPs that are not explicitly used for Cloudflare One services. This reduces the risk of conflicts with existing private network configurations that may use CGNAT address space. -You can use the calculator below to determine which IP ranges to add back based on the Cloudflare One features you use. For example, if your deployment requires [Gateway initial resolved IPs](#gateway-initial-resolved-ips) (`100.80.0.0/16`) and [device IPs](#device-ips) (`100.96.0.0/12`), delete `100.64.0.0/10` from Split Tunnels and add back `100.64.0.0/12`, `100.81.0.0/16`, `100.82.0.0/15`, `100.84.0.0/14`, `100.88.0.0/13`, and `100.112.0.0/12`. +Use the following calculator to determine which IP ranges to add back based on the Cloudflare One features you use. For example, if your deployment requires [Cloudflare source IPs](#cloudflare-source-ips) (`100.64.0.0/12`) and [device IPs](#device-ips) (`100.96.0.0/12`), delete `100.64.0.0/10` from Split Tunnels and add back `100.80.0.0/12` and `100.112.0.0/12`. ### Include mode -In **Include IPs and domains** mode, only traffic for the included routes is sent to Cloudflare. You must explicitly add the reserved IP ranges that your deployment depends on. For example, if you use [hostname routing or egress policy host selectors](#gateway-initial-resolved-ips), add `100.80.0.0/16` to your Split Tunnels include list. +In **Include IPs and domains** mode, the Cloudflare One Client sends only traffic for the included routes to Cloudflare. You must explicitly add the reserved IP ranges that your deployment depends on. For example, if you use [hostname routing or egress policy host selectors](#gateway-initial-resolved-ips), add `172.64.128.0/20` (or your custom IPv4 range) and `2606:4700:0cf1:4000::/64` to your Split Tunnels include list. diff --git a/src/content/docs/cloudflare-one/traffic-policies/egress-policies/egress-cloudflared.mdx b/src/content/docs/cloudflare-one/traffic-policies/egress-policies/egress-cloudflared.mdx index f12b7ca9e11..b9819e28b85 100644 --- a/src/content/docs/cloudflare-one/traffic-policies/egress-policies/egress-cloudflared.mdx +++ b/src/content/docs/cloudflare-one/traffic-policies/egress-policies/egress-cloudflared.mdx @@ -6,8 +6,6 @@ products: title: Egress through Cloudflare Tunnel sidebar: order: 2 - badge: - text: Beta tags: - AWS - Private networks @@ -79,7 +77,9 @@ In your WARP [Split Tunnels](/cloudflare-one/team-and-resources/devices/cloudfla When users connect to a public hostname route, Gateway will assign an initial resolved IP to the DNS query from the following range: -Gateway's network engine operates at Layer 3/Layer 4 of the [OSI model](https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi/), where only IP addresses are available — not hostnames. The initial resolved IP acts as a signal: when a packet's destination IP falls within the `100.80.0.0/16` Carrier-Grade NAT (CGNAT) range, Gateway recognizes that the IP maps to a public hostname route and sends the traffic through the corresponding Cloudflare Tunnel. + + +Gateway's network engine operates at Layer 3/Layer 4 of the [OSI model](https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi/), where only IP addresses are available — not hostnames. The initial resolved IP acts as a signal: when a packet's destination IP falls within this range, Gateway recognizes that the IP maps to a public hostname route and sends the traffic through the corresponding Cloudflare Tunnel. To route initial resolved IPs through the Cloudflare One Client: diff --git a/src/content/docs/cloudflare-one/traffic-policies/egress-policies/host-selectors.mdx b/src/content/docs/cloudflare-one/traffic-policies/egress-policies/host-selectors.mdx index 9dba4363635..682e8eda2f1 100644 --- a/src/content/docs/cloudflare-one/traffic-policies/egress-policies/host-selectors.mdx +++ b/src/content/docs/cloudflare-one/traffic-policies/egress-policies/host-selectors.mdx @@ -10,7 +10,7 @@ tags: - DNS --- -import { Tabs, TabItem, Details, APIRequest, Render } from "~/components"; +import { Tabs, TabItem, Details, APIRequest, Render, GlossaryTooltip } from "~/components";
    @@ -31,7 +31,7 @@ import { Tabs, TabItem, Details, APIRequest, Render } from "~/components"; Egress policies are evaluated at Layer 4 (https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi/) of the OSI model, where only IP addresses are available — not hostnames. The [Application](/cloudflare-one/traffic-policies/egress-policies/#application), [Content Categories](/cloudflare-one/traffic-policies/egress-policies/#content-categories), [Domain](/cloudflare-one/traffic-policies/egress-policies/#domain), and [Host](/cloudflare-one/traffic-policies/egress-policies/#host) selectors need to match traffic by hostname, so Gateway uses a two-step process: -1. When Gateway receives a DNS query for a hostname that matches one of these selectors, it initially resolves the query to a temporary IP in the `100.80.0.0/16` or `2606:4700:0cf1:4000::/64` range. +1. When Gateway receives a DNS query for a hostname that matches one of these selectors, it initially resolves the query to a temporary initial resolved IP. By default, this IP is drawn from a Cloudflare-owned public range (`172.64.128.0/20` for IPv4, or `2606:4700:0cf1:4000::/64` for IPv6). You can [configure a custom IPv4 range](/cloudflare-one/networks/routes/configure-initial-resolved-ips/) if it conflicts with your existing network. 2. When traffic arrives with this temporary destination IP, Gateway can identify which hostname the connection belongs to, apply the correct egress policy, then replace the temporary IP with the real destination IP before forwarding the traffic. ![Example egress policy flow](~/assets/images/cloudflare-one/policies/host-selector-diagram.png) diff --git a/src/content/docs/cloudflare-one/traffic-policies/troubleshoot-gateway.mdx b/src/content/docs/cloudflare-one/traffic-policies/troubleshoot-gateway.mdx index 99dcde1d99d..ab2d38fb047 100644 --- a/src/content/docs/cloudflare-one/traffic-policies/troubleshoot-gateway.mdx +++ b/src/content/docs/cloudflare-one/traffic-policies/troubleshoot-gateway.mdx @@ -26,7 +26,7 @@ Even with an active egress policy, you may find that traffic is egressing from a | Common cause | Solution | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| DNS resolution to CGNAT (carrier-grade NAT) | When an egress policy uses a _Domain_ or _Host_ selector, Gateway must first resolve that domain. For traffic proxied through Cloudflare, this often resolves to a CGNAT IP address from the `100.64.0.0/10` range. Because this IP is internal to Cloudflare's network, it may not be subject to egress policies, which apply to traffic leaving the network. Change the selector in your egress policy from _Domain_ or _Host_ to _Destination IP_. Use the public IP addresses of the service you are trying to reach. | +| DNS resolution to an initial resolved IP | When an egress policy uses a _Domain_ or _Host_ selector, Gateway must first resolve that domain to an [initial resolved IP](/cloudflare-one/networks/routes/reserved-ips/#gateway-initial-resolved-ips). If your account still uses a legacy range within CGNAT (carrier-grade NAT) address space, this IP may be treated as internal to Cloudflare's network and may not be subject to egress policies, which apply to traffic leaving the network. Change the selector in your egress policy from _Domain_ or _Host_ to _Destination IP_ (using the public IP addresses of the service you are trying to reach), or [move your initial resolved IP range off CGNAT](/cloudflare-one/networks/routes/configure-initial-resolved-ips/). | | Policy precedence | A different egress policy with a higher precedence (a lower number) is matching the traffic first. Remember that egress policies follow the same first-match-wins logic. | | Split Tunnel configuration | The destination IP or domain is excluded from the WARP tunnel via your [Split Tunnel](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/split-tunnels/) configuration (which controls whether traffic for specific IPs or domains is sent through or excluded from the WARP tunnel). Traffic that is excluded from the tunnel will not be subject to any Gateway policies, including egress. | | No egress logs | Egress logging is available via Logpush with the Gateway Egress dataset. This is essential for troubleshooting. You can also use a third-party IP check service to verify the egress IP from a test device. | diff --git a/src/content/docs/load-balancing/private-network/warp-to-tunnel.mdx b/src/content/docs/load-balancing/private-network/warp-to-tunnel.mdx index 174e2683f19..3c4195f5527 100644 --- a/src/content/docs/load-balancing/private-network/warp-to-tunnel.mdx +++ b/src/content/docs/load-balancing/private-network/warp-to-tunnel.mdx @@ -139,7 +139,7 @@ In order for Cloudflare One Clients to connect to your load balancer, the load b 4. Select **Manage**. Depending on the mode: - **Exclude mode**: Delete the IP range that contains your load balancer IP. For example, if your load balancer has a Cloudflare-assigned CGNAT IP, delete `100.64.0.0/10`. We recommend [adding back the IPs](/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-cidr/#3-route-private-network-ips-through-the-cloudflare-one-client) that are not being used by your load balancer. :::note - Some IPs in the `100.64.0.0/10` range may be reserved for other Zero Trust services such as Gateway initial resolved IPs or WARP CGNAT IPs. These IPs should remain deleted from the Exclude list. + Some IPs in the `100.64.0.0/10` range may be reserved for other Zero Trust services such as WARP CGNAT IPs, or Gateway initial resolved IPs if your account uses a legacy or custom range within CGNAT space. These IPs should remain deleted from the Exclude list. ::: - **Include mode**: Add your load balancer IP. diff --git a/src/content/glossary/cloudflare-one.yaml b/src/content/glossary/cloudflare-one.yaml index 05390a45c6e..b9a6687d31d 100644 --- a/src/content/glossary/cloudflare-one.yaml +++ b/src/content/glossary/cloudflare-one.yaml @@ -121,7 +121,7 @@ entries: - term: initial resolved IP general_definition: |- - a unique, ephemeral IP address that Gateway assigns to DNS queries when filtering network traffic by hostname. The IP is randomly selected from the `100.80.0.0/16` (IPv4) or `2606:4700:0cf1:4000::/64` (IPv6) range. + a unique, ephemeral IP address that Gateway assigns to DNS queries when filtering network traffic by hostname. The IP is randomly selected from an IPv4 range (`172.64.128.0/20` by default, configurable per account) or an IPv6 range (`2606:4700:0cf1:4000::/64`, not configurable). - term: JSON web token general_definition: |- diff --git a/src/content/partials/cloudflare-one/gateway/egress-selector-cgnat-ips.mdx b/src/content/partials/cloudflare-one/gateway/egress-selector-cgnat-ips.mdx index ea9c95d04ff..fb5b0cd47fc 100644 --- a/src/content/partials/cloudflare-one/gateway/egress-selector-cgnat-ips.mdx +++ b/src/content/partials/cloudflare-one/gateway/egress-selector-cgnat-ips.mdx @@ -3,5 +3,7 @@ --- -- **IPv4**: `100.80.0.0/16` -- **IPv6**: `2606:4700:0cf1:4000::/64` \ No newline at end of file +- **IPv4**: `172.64.128.0/20` +- **IPv6**: `2606:4700:0cf1:4000::/64` + +This is the default range. You can [configure a custom initial resolved IP range](/cloudflare-one/networks/routes/configure-initial-resolved-ips/) for IPv4 if it conflicts with your existing network. \ No newline at end of file diff --git a/src/content/partials/cloudflare-one/gateway/egress-selector-chrome-issue.mdx b/src/content/partials/cloudflare-one/gateway/egress-selector-chrome-issue.mdx index 272dc75256e..c2107c8f852 100644 --- a/src/content/partials/cloudflare-one/gateway/egress-selector-chrome-issue.mdx +++ b/src/content/partials/cloudflare-one/gateway/egress-selector-chrome-issue.mdx @@ -1,8 +1,12 @@ import { GlossaryTooltip } from "~/components"; -Starting with [Chrome 142](https://developer.chrome.com/release-notes/142), the browser restricts requests from websites to local IP addresses, including the Gateway initial resolved IP CGNAT range (`100.80.0.0/16`). Because this range falls within `100.64.0.0/10`, Chrome categorizes these addresses as belonging to a local network. When a website loaded from a public IP makes subrequests to a domain resolved through an initial resolved IP, Chrome treats this as a public-to-local network request and displays a prompt asking the user to allow access to devices on the local network. Chrome will block requests to these domains until the user accepts this prompt. +Starting with [Chrome 142](https://developer.chrome.com/release-notes/142), Local Network Access (LNA) restricts requests from websites to local IP addresses. LNA is implemented at the Chromium engine level, so this affects all Chromium-based browsers (for example, Microsoft Edge, Brave, and Opera), not only Google Chrome. This can affect accounts whose Gateway initial resolved IP range is still drawn from Carrier-Grade NAT (CGNAT) address space (`100.64.0.0/10`) — for example, the legacy default range `100.80.0.0/16`, or a custom range configured within CGNAT space. These browsers categorize such addresses as belonging to a local network. When a website loaded from a public IP makes subrequests to a domain resolved through an initial resolved IP in this space, the browser treats this as a public-to-local network request and displays a prompt asking the user to allow access to devices on the local network. The browser blocks requests to these domains until the user accepts this prompt. -This commonly occurs when an Egress policy matches broadly used domains (such as `cloudfront.net` or `github.com`), causing subrequests from public pages to resolve to the `100.80.0.0/16` range. +This commonly occurs when an Egress policy matches broadly used domains (such as `cloudfront.net` or `github.com`), causing subrequests from public pages to resolve into CGNAT space. + +Accounts using the current default initial resolved IP range (`172.64.128.0/20`) are not affected, because this range is public Cloudflare address space rather than CGNAT. If your account was created before this default changed, or if you configured a custom CGNAT-space range, refer to [Configure initial resolved IPs](/cloudflare-one/networks/routes/configure-initial-resolved-ips/) to move to a non-CGNAT range instead of relying on the following browser workarounds. + +The workarounds below use Google Chrome Enterprise policies. If your organization manages a different Chromium-based browser, consult that browser's enterprise policy documentation for an equivalent control. #### Iframes @@ -17,7 +21,7 @@ If iframes are nested, every iframe in the chain must include the appropriate at To avoid this issue, choose one of the following options: -- **Override IP address space classification (Chrome 146+)**: Use the [`LocalNetworkAccessIpAddressSpaceOverrides`](https://chromeenterprise.google/policies/#LocalNetworkAccessIpAddressSpaceOverrides) Chrome Enterprise policy to reclassify the `100.80.0.0/16` range as public. This is the most targeted fix because it only changes the classification for the initial resolved IP range rather than disabling security checks entirely. +- **Override IP address space classification (Chrome 146+)**: Use the [`LocalNetworkAccessIpAddressSpaceOverrides`](https://chromeenterprise.google/policies/#LocalNetworkAccessIpAddressSpaceOverrides) Chrome Enterprise policy to reclassify your CGNAT-space initial resolved IP range (for example, `100.80.0.0/16`) as public. This is the most targeted fix because it only changes the classification for the initial resolved IP range rather than disabling security checks entirely. - **Allow specific URLs (Chrome 140+)**: Use the [`LocalNetworkAccessAllowedForUrls`](https://chromeenterprise.google/policies/#LocalNetworkAccessAllowedForUrls) Chrome Enterprise policy to exempt specific websites from Local Network Access checks. Note that `https://*` is a valid entry to disable checks for all URLs. - **Allow specific URLs (Chrome 146+)**: Use the [`LocalNetworkAllowedForUrls`](https://chromeenterprise.google/policies/#LocalNetworkAllowedForUrls) Chrome Enterprise policy, which replaces `LocalNetworkAccessAllowedForUrls` starting in Chrome 146. - **Opt out of Local Network Access restrictions (Chrome 142-152)**: Use the [`LocalNetworkAccessRestrictionsTemporaryOptOut`](https://chromeenterprise.google/policies/#LocalNetworkAccessRestrictionsTemporaryOptOut) Chrome Enterprise policy to completely opt out of Local Network Access restrictions. This is a temporary policy and will be removed after Chrome 152. diff --git a/src/content/partials/cloudflare-one/troubleshooting/gateway.mdx b/src/content/partials/cloudflare-one/troubleshooting/gateway.mdx index a5dd284025e..963adfa774a 100644 --- a/src/content/partials/cloudflare-one/troubleshooting/gateway.mdx +++ b/src/content/partials/cloudflare-one/troubleshooting/gateway.mdx @@ -38,7 +38,7 @@ Even with an active egress policy, you may find that traffic is egressing from a | Common cause | Solution | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| DNS resolution to CGNAT (carrier-grade NAT) | When an egress policy uses a _Domain_ or _Host_ selector, Gateway must first resolve that domain. For traffic proxied through Cloudflare, this often resolves to a CGNAT IP address from the `100.64.0.0/10` range. Because this IP is internal to Cloudflare's network, it may not be subject to egress policies, which apply to traffic leaving the network. Change the selector in your egress policy from _Domain_ or _Host_ to _Destination IP_. Use the public IP addresses of the service you are trying to reach. | +| DNS resolution to an initial resolved IP | When an egress policy uses a _Domain_ or _Host_ selector, Gateway must first resolve that domain to an [initial resolved IP](/cloudflare-one/networks/routes/reserved-ips/#gateway-initial-resolved-ips). If your account still uses a legacy range within CGNAT (carrier-grade NAT) address space, this IP may be treated as internal to Cloudflare's network and may not be subject to egress policies, which apply to traffic leaving the network. Change the selector in your egress policy from _Domain_ or _Host_ to _Destination IP_ (using the public IP addresses of the service you are trying to reach), or [move your initial resolved IP range off CGNAT](/cloudflare-one/networks/routes/configure-initial-resolved-ips/). | | Policy precedence | A different egress policy with a higher precedence (a lower number) is matching the traffic first. Remember that egress policies follow the same first-match-wins logic. | | Split Tunnel configuration | The destination IP or domain is excluded from the WARP tunnel via your Split Tunnel configuration. Traffic that is excluded from the tunnel will not be subject to any Gateway policies, including egress. | | No egress logs | Egress logging is available via Logpush with the Gateway Egress dataset. This is essential for troubleshooting. You can also use a third-party IP check service to verify the egress IP from a test device. | diff --git a/src/content/partials/networking-services/cloudflare-wan/zero-trust/tunnel.mdx b/src/content/partials/networking-services/cloudflare-wan/zero-trust/tunnel.mdx index 41ddc29de0c..91e3c411dcc 100644 --- a/src/content/partials/networking-services/cloudflare-wan/zero-trust/tunnel.mdx +++ b/src/content/partials/networking-services/cloudflare-wan/zero-trust/tunnel.mdx @@ -34,7 +34,7 @@ Cloudflare reserves the following IP ranges for Zero Trust services: | --- | --- | | `100.64.0.0/12` | [Cloudflare Source IPs](/cloudflare-wan/configuration/how-to/configure-cloudflare-source-ips/) | | `100.96.0.0/12` | [Device IPs](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/device-ips/) | -| `100.80.0.0/16` | [Initial resolved IPs](/cloudflare-one/traffic-policies/egress-policies/host-selectors/) | +| `172.64.128.0/20` | [Initial resolved IPs](/cloudflare-one/traffic-policies/egress-policies/host-selectors/) | | `100.112.0.0/16` | [Private Load Balancers](/load-balancing/private-network/) | Do not configure routes that overlap with these reserved ranges. @@ -67,7 +67,7 @@ ARR requires Unified Routing mode. For more information, refer to