Module 4b — Connecting Your Networks: Tunnel, Mesh & Appliance

Goal: Understand and set up the three ways to connect your private resources to Cloudflare — Cloudflare Tunnel (apps & servers), Cloudflare Mesh (site-to-site and device mesh), and the Cloudflare One Appliance (whole branch sites) — and know which to use when.

🧭 Big idea — "on-ramps". Cloudflare Zero Trust protects traffic after it reaches Cloudflare. A connector is the on-ramp that gets your private traffic there safely. You met Cloudflare Tunnel briefly in Module 4; this module covers the full connector family so you can connect a single app, a full mesh, or an entire office.

Which connector do I use?

💡 Rule of thumb: Tunnel for apps and servers, Mesh for any-to-any connectivity between hosts and devices, Appliance for a whole site. They can be combined across a network.

Everything below runs through Cloudflare, so your Gateway policies, device posture, and Access rules apply to every connection regardless of connector.

Part A — Cloudflare Tunnel

cloudflared makes a secure, outbound-only connection from your infrastructure to Cloudflare — so you never open an inbound firewall port or expose a public IP.

A1 — Two management styles

• Remotely-managed (recommended): create and configure the tunnel in the dashboard; the connector pulls its config from Cloudflare. Easiest to operate.
• Locally-managed: you manage a config.yml and credentials on the host (CLI). More control, useful for GitOps/automation.

A2 — Create a tunnel (dashboard)

1. 👉 In the Cloudflare dashboard, go to Networking → Tunnels.
2. 👉 Click Create a tunnel → choose Cloudflared → Next.
3. ⌨️ Name it after what it connects, e.g. enterprise-vpc-01 → Save tunnel.
4. 👉 Choose your server's operating system, copy the install command, and run it in a terminal on your origin server.
5. 📺 Wait for the connector to report Connected / Healthy, then click Continue.

⚠️ Pre-check: the host must be able to reach Cloudflare outbound on port 7844. If it's behind a strict firewall, allow that first.

A3 — Then pick what to connect

Option 1 — Publish an application (reachable at a hostname):

1. 👉 On the tunnel's Routes tab → Add route → Published application.
2. ⌨️ Enter a subdomain + pick a Domain (the zone must be in your account).
3. ⌨️ Service URL = where the app runs locally, e.g. http://localhost:8000.
4. 👉 Save. Then gate it with an Access application (Module 4) so only the right people get in.

Option 2 — Connect a private network (reach it by IP through WARP):

1. 👉 Networking → Routes → Create route → Tunnel CIDR.
2. 👉 Select your tunnel, enter the private range (e.g. 10.0.0.0/24).
3. 👉 (Optional) pick a virtual network if this range overlaps another route in your account.
4. 👉 Create route. Users on the Cloudflare One Client can now reach those IPs (add Gateway network policies to control access).

A4 — High availability

Run multiple cloudflared replicas (different hosts, same tunnel) for redundancy; there are deployment guides for Docker and Kubernetes.

✅ Checkpoint: the tunnel shows Healthy; you can reach the published app's hostname, or ping/reach a private IP through WARP.

🔧 If it didn't work: connector not Healthy → check outbound 7844; app route 502 → wrong Service URL/port; private IP unreachable → missing Tunnel CIDR route or overlapping range (use a virtual network).

Part B — Cloudflare Mesh (formerly WARP Connector)

📖 Naming: WARP Connector is now called Cloudflare Mesh (renamed 2026). Existing WARP Connectors are now mesh nodes — nothing to migrate.

Cloudflare Mesh creates a private, post-quantum-encrypted network across your servers, devices, and sites. Instead of exposing apps one at a time, every participant gets a private Mesh IP and can reach any other participant by IP — including client-to-client — with no bastion hosts or VPN concentrators.

What Mesh gives you

• A private Mesh IP for every enrolled device and mesh node.
• Any-to-any reachability by IP (device↔device, device↔network, network↔network).
• CIDR routes to reach whole subnets behind a mesh node.
• High availability via active-passive replica nodes for routed subnets.
• Every connection still flows through Cloudflare, so Gateway network policies + device posture + Access rules all apply.
• Up to 50 mesh nodes per account.

B1 — Set up a mesh node

1. 👉 In the dashboard, go to Networking → Mesh and start the setup wizard (interactive network map, node management, diagnostics).
2. 👉 Add a mesh node and follow the wizard to install the connector software on a Linux host in the network you want to join to the mesh.
3. ⌨️ (Optional) add CIDR routes on the node so the subnets behind it (e.g. 192.168.20.0/24) are reachable across the mesh.
4. 👉 For a routed subnet that must stay online, add an active-passive replica node for high availability.

B2 — Verify

• 👉 After install, ping the mesh node's own LAN IP — it responds directly, giving you a fast reachability check before testing downstream services.
• 👉 On an enrolled device (Cloudflare One Client connected), reach another participant by its Mesh IP.

✅ Checkpoint: the node appears on the Mesh network map; you can ping the node and reach a device/subnet across the mesh.

💡 Mesh vs Tunnel: Tunnel is one-directional (bring an app/subnet to Cloudflare and users reach it). Mesh is bidirectional and any-to-any — ideal for connecting sites to each other and enabling device-to-device traffic.

Part C — Cloudflare One Appliance (formerly Magic WAN Connector)

When you want to connect an entire office or data center — every device on the LAN, with no per-device software — use the Cloudflare One Appliance (hardware or virtual). It's the branch on-ramp for Cloudflare WAN.

What it does

• Plugs into your branch network and connects the whole site to Cloudflare over automatically-built tunnels.
• Bootstrap via DHCP (plug-and-play) or a static IP using the serial console.
• Multiple WAN ports with breakout traffic control — e.g. pin latency-sensitive apps (Zoom, Teams) to your fastest uplink, with automatic failover if that port goes down.
• Built-in DHCP server for the branch (with redundant DNS servers).
• Automatically creates up to two tunnels per WAN port when you have more than one anycast IP — for reliability, no extra config.

C1 — At a glance

1. 👉 Order/deploy the hardware appliance, or deploy the virtual appliance in your hypervisor/cloud.
2. 👉 Cable WAN (Internet) and LAN (your network) ports; power on.
3. 👉 It bootstraps (DHCP by default; static IP via serial console if needed) and registers to your account.
4. 👉 Configure LAN subnets, DHCP, and WAN/breakout policy in the dashboard.

📘 The Appliance is part of Cloudflare WAN — full site connectivity, routing, redundancy (dual appliances), and Magic Firewall are covered in Module 8 — Cloudflare WAN. This section is the connector-family overview; do Module 8 for the complete branch rollout.

✅ Checkpoint: the appliance shows healthy in the dashboard and branch devices reach the Internet/private resources through Cloudflare.

Part D — Putting it together

A typical enterprise uses more than one connector:

  Internal web app / SSH  ──── Cloudflare Tunnel ────┐
  Linux servers + laptops ──── Cloudflare Mesh ──────┼──►  CLOUDFLARE  ──►  Zero Trust
  Whole branch office     ──── Cloudflare One Appliance┘   (Identity · Access · Gateway · DLP)

• Publish an app / reach a subnet → Cloudflare Tunnel (Part A)
• Connect hosts and devices any-to-any → Cloudflare Mesh (Part B)
• Bring a whole site online → Cloudflare One Appliance / Cloudflare WAN (Part C → Module 8)

Whichever you choose, traffic lands in Cloudflare and your Access, Gateway, DLP, and posture policies apply uniformly.

✅ Module 4b complete!

You now understand:

• ✅ Cloudflare Tunnel — outbound-only connector for apps, servers, and subnets
• ✅ Cloudflare Mesh — any-to-any private networking (formerly WARP Connector)
• ✅ Cloudflare One Appliance — whole-site on-ramp for Cloudflare WAN
• ✅ Which connector fits which scenario

Quick reference

👉 Next: Module 5 — Gateway (Web Filtering)

Block threats and filter DNS/web traffic for everything now connected.