← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-mesh

Routes

By default, a Mesh node is reachable only by its own Mesh IP. To make other devices on the subnet behind the node reachable — servers, databases, printers, IoT devices that cannot run the Cloudflare One Client — add a route to the node. A Mesh node supports two types of routes:

• CIDR routes — forward traffic for an IP range — private (for example, 10.0.0.0/24) or public — through the node.
• Hostname routes — attract traffic for a hostname to the node instead of an IP. This works for a private hostname (for example, wiki.internal.local), which is useful when the application has an unknown or ephemeral IP, as well as a public hostname (for example, www.example.com), which routes that hostname's traffic through the node and egresses via the node's public IP.

When you add a route, the Mesh node acts as a gateway: traffic destined for the advertised CIDR or hostname is forwarded to the node, which delivers it to the appropriate host on the local network (or egresses it to the public Internet).

Both IPv4 and IPv6 CIDR routes are supported. IPv6 routes require that the Mesh node's device profile is configured to use MASQUE; they will not work if the device profile uses WireGuard instead.

• Without routes — Devices on your Mesh can only reach the node itself by its Mesh IP. Services running directly on the node are reachable this way.
• With routes — Devices on your Mesh can reach any host on the subnet behind the node. Use this when you have infrastructure that cannot run the Cloudflare One Client.

flowchart LR
  subgraph subnet["Subnet 10.0.0.0/24"]
    node["Mesh node <br> 10.0.0.1"]
    db["Database <br> 10.0.0.50"]
    printer["Printer <br> 10.0.0.100"]
  end
  client["Client device <br> 100.96.0.10"] --> CF((Cloudflare)) --> node
  node --> db
  node --> printer

Use CIDR routes to forward traffic from your mesh node to devices on your local network.

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"network": "10.0.0.0/24",
		"tunnel_id": "{mesh_node_id}",
		"comment": "Staging subnet"
	}'

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"network": "10.0.0.0/24",
		"comment": "Updated description"
	}'

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID" \
	--request DELETE \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

For traffic to reach your advertised CIDR, the range must route through Cloudflare on both the Mesh node and client devices.

In your Mesh node's device profile, ensure the advertised CIDR routes through Cloudflare:

• Include mode (recommended for Mesh nodes): Add the CIDR to your include list.
• Exclude mode: Remove the CIDR (or its parent range) from your exclude list.

For example, if you are advertising 10.0.0.0/24 and your Split Tunnels exclude list contains 10.0.0.0/8, you need to remove 10.0.0.0/8 and re-add the portions of the 10.0.0.0/8 range that you do not want to route through Cloudflare.

Repeat the same Split Tunnel configuration on the device profiles used by your client devices, ensuring the advertised CIDR routes through Cloudflare.

The Mesh node forwards inbound traffic from Cloudflare to devices on the subnet. However, for return traffic (responses from subnet devices back to Mesh clients), the subnet devices need a route back to the Mesh node.

flowchart LR
  client["Client device <br> 100.96.0.10"] -- request --> CF((Cloudflare)) -- request --> node["Mesh node <br> 10.0.0.1"]
  node --> db["Database <br> 10.0.0.50"]
  db -. "response: <br> needs route to node" .-> node -. response .-> CF -. response .-> client

How you configure this depends on where the Mesh node is installed:

If the Mesh node is the subnet's default gateway (or is installed on the router), no additional configuration is needed. All traffic from subnet devices naturally routes through the node.

If the Mesh node is a regular host on the subnet, configure the subnet's router to send Mesh traffic through the node. Add a static route:

• Destination: 100.96.0.0/12 (Mesh IP range)
• Next hop: The Mesh node's local subnet IP (for example, 10.0.0.1)

This ensures that responses to Mesh clients are forwarded to the Mesh node for delivery through Cloudflare.

When you have Mesh nodes at multiple sites, devices on one subnet can reach devices on another subnet through Cloudflare.

flowchart TD
  subgraph siteA["Site A — 10.0.0.0/24"]
    serverA["Server <br> 10.0.0.50"] --- nodeA["Mesh node <br> 10.0.0.1"]
  end
  subgraph siteB["Site B — 192.168.1.0/24"]
    serverB["Server <br> 192.168.1.50"] --- nodeB["Mesh node <br> 192.168.1.1"]
  end
  nodeA <--> CF((Cloudflare))
  nodeB <--> CF

For this to work:

1. Each Mesh node must advertise the local subnet as a CIDR route so Cloudflare knows which node to forward traffic to.
2. The remote subnet CIDRs must route through Cloudflare on each node. In your Mesh node's Split Tunnel configuration, add the remote site's CIDR to the include list (or remove it from the exclude list).
3. Each site's router needs static routes pointing remote subnets to the local Mesh node:

Site A router:

• Destination: 192.168.1.0/24 → Next hop: 10.0.0.1 (local Mesh node)
• Destination: 100.96.0.0/12 → Next hop: 10.0.0.1

Site B router:

• Destination: 10.0.0.0/24 → Next hop: 192.168.1.1 (local Mesh node)
• Destination: 100.96.0.0/12 → Next hop: 192.168.1.1

For production site-to-site deployments, consider enabling high availability on each node. HA provides failover for the CIDR routes advertised by a node — if the active replica goes down, Cloudflare promotes a standby so traffic to the subnet continues to flow.

To filter DNS queries from the subnet using Cloudflare Gateway:

1. Configure DNS on your router: Point your router's DNS to the Gateway resolver IPs:

   • 172.64.36.1
   • 172.64.36.2

2. Add IP routes to your router: On your router, add static routes pointing the Gateway resolver IPs to your Mesh node's local IP. This allows DNS traffic to reach Cloudflare through the node.

   • Destination: 172.64.36.1 → Next hop: 10.0.0.1 (local Mesh node)
   • Destination: 172.64.36.2 → Next hop: 10.0.0.1

3. Configure Split Tunnels: Ensure the following IPs route through the Mesh node in your Split Tunnels configuration:

   • The subnet's internal DNS resolver IP
   • 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 for internal DNS records.

Instead of advertising an IP range, you can attract traffic for a specific hostname to a Mesh node. When a user requests the hostname, Cloudflare Gateway assigns an initial resolved IP and routes the traffic through the node.

• Private hostname (for example, wiki.internal.local) — the node delivers the traffic to the application's private IP on the local network. Useful when the application has an unknown or ephemeral IP.
• Public hostname (for example, www.example.com) — the node egresses the traffic to the public Internet using its own public IP. This lets you use a Mesh node as a dedicated egress for that hostname.

Hostname routes replace virtual networks as the way to reach resources: because a hostname is globally unique, overlapping hostnames are not supported and a hostname can only be routed to one node or tunnel at a time.

For a deeper look at the packet flow behind hostname routing, refer to the announcement blog post ↗.

• Run a supported Mesh node version. Hostname routing requires the Mesh node to run Linux Cloudflare One Client version 2026.6.822.0 or newer.

• Configure the Mesh node's device profile to use MASQUE. Hostname routing does not work if the device profile uses WireGuard instead.

• Enable the Gateway proxy with TCP, UDP, and ICMP:

  1. Go to Traffic policies > Traffic settings.
  2. In Proxy and inspection, turn on Allow Secure Web Gateway to proxy traffic.
  3. Select TCP.
  4. Select UDP (required to proxy traffic to internal DNS resolvers).
  5. (Recommended) To proxy traffic for diagnostic tools such as ping and traceroute, select ICMP. You may also need to update your system to allow ICMP traffic through cloudflared.

  1. Add the following permission to your cloudflare_api_token ↗:

     • Zero Trust Write

  2. Turn on the TCP and/or UDP proxy using the cloudflare_zero_trust_device_settings ↗ resource:

     resource "cloudflare_zero_trust_device_settings "global_warp_settings" {
     	account_id            = var.cloudflare_account_id
       gateway_proxy_enabled = true
     	gateway_udp_proxy_enabled = true
     }

  Cloudflare will now proxy traffic from enrolled devices, except for the traffic excluded in your split tunnel settings. For more information on how Gateway forwards traffic, refer to Gateway proxy.

• Route the following IPv4 ranges through Cloudflare in the Split Tunnel configuration of both the Mesh node's device profile and your client device profiles. In Include mode, add each range. In Exclude mode, ensure none of them (or their parent ranges) are excluded.

  Purpose	IPv4
  Mesh device IP range	100.96.0.0/12
  Cloudflare source IP range	100.64.0.0/12

  The hostname routing (token IP) range (172.64.128.0/20) and all Cloudflare One IPv6 ranges are automatically routed through Cloudflare and do not need to be added manually.

• Remove the hostname's top-level domain from Local Domain Fallback on client devices, so the DNS query is sent to Cloudflare Gateway for resolution.

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/zerotrust/routes/hostname" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"hostname": "wiki.internal.local",
		"tunnel_id": "{mesh_node_id}",
		"comment": "Internal wiki"
	}'

For a private hostname, Gateway must be able to resolve the hostname to its private IP. How you configure this depends on whether DNS resolution and application traffic use the same connector or different connectors.

By default, the Mesh node resolves the hostname using the DNS resolver configured on its host machine (for example, in /etc/resolv.conf on Linux) — the same way cloudflared does. If the node can already resolve the hostname to its private IP through that resolver, no further configuration is required.

If the node cannot resolve the hostname on its own, the simplest option is to add an entry to the node's hosts file (for example, /etc/hosts on Linux) mapping the hostname to its private IP. Unlike a Cloudflare Tunnel, a Mesh node does not require you to run a dedicated DNS server:

10.0.0.50 wiki.internal.local

You only need a Gateway resolver policy when the DNS query must be sent to a different connector than the application traffic — for example, the internal DNS server sits behind one Mesh node or Cloudflare Tunnel, while the application is reached through another. In that case:

1. Add a CIDR route for the DNS server's IP so Gateway can reach it through the connector where the DNS server lives (a Mesh node or a Cloudflare Tunnel).
2. Create a resolver policy that sends DNS queries for the hostname (or its domain) to that internal DNS server.

For a public hostname, the Mesh node handles resolution: Gateway sends the DNS query to the node, the node resolves it through its upstream DNS provider, and then routes the packet to the destination and egresses using its own public IP. No internal DNS server or resolver policy is required.

After adding a hostname route, secure it with either an Access self-hosted application or Gateway network policies. For details and examples, refer to Connect a private hostname.

Starting with Chrome 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 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 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.

If the affected request originates from within an iframe (for example, an application embedded in a third-party portal), the iframe must declare the local-network-access permission for the browser prompt to appear in the parent frame:

• Chrome 142-144: Use the allow="local-network-access" attribute on the iframe element.
• Chrome 145+: The permission was split into allow="local-network" and allow="loopback-network".

If iframes are nested, every iframe in the chain must include the appropriate attribute. Since third-party applications control their own iframe attributes, this may not be configurable by the end user.

To avoid this issue, choose one of the following options:

• Override IP address space classification (Chrome 146+): Use the 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 ↗ 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 ↗ Chrome Enterprise policy, which replaces LocalNetworkAccessAllowedForUrls starting in Chrome 146.
• Opt out of Local Network Access restrictions (Chrome 142-152): Use the 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.
• Disable the Chrome feature flag: Go to chrome://flags and set the Local Network Access Checks flag to Disabled. This approach is suitable for individual users but not for enterprise-wide deployment.