Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

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 CIDR routes.

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

When to use routes

  • 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

Manage routes

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

Add a route

  1. In the Cloudflare dashboard, go to Networking > Mesh.

    Go to Mesh

  2. Select your Mesh node.

  3. Go to the Routes tab.

  4. Select Add route.

  5. Enter the private CIDR you want to route through this node (for example, 10.0.0.0/24).

  6. (Optionally) add a description for the route.

  7. Select Add route.

Edit a route

  1. Go to Networking > Mesh > select your node > Routes tab.
  2. Select the edit icon next to the route you want to modify.
  3. Update the CIDR or description.
  4. Select Save.

Delete a route

  1. Go to Networking > Mesh > select your node > Routes tab.
  2. Select the delete icon next to the route.
  3. Confirm deletion.

Configure Split Tunnels

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

On the Mesh node

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.

On client devices

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

Return traffic routing

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:

Option 1: Mesh node is the default gateway

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.

Option 2: Mesh node is not the default gateway

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.

Site-to-site routing

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.

DNS filtering

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: 100.80.0.0/16 (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.