🌐 Trang này chưa được dịch sang tiếng Việt — đang hiển thị nội dung tiếng Anh.
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.
| 👤 Who does this | Network / infrastructure team |
| ⏱️ Time | ~45 minutes |
| 🎯 You'll finish with | A private network or site connected to Cloudflare with the right connector |
| ✋ Before you begin | Module 3 done (devices enrolled). For Tunnel: a server/VM that can reach your private network. |
🧭 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?
| Connector | Connects | Runs on | Best for |
|---|---|---|---|
Cloudflare Tunnel (cloudflared) |
A single app, server, subnet, or private network | A lightweight daemon on a host/VM | Publishing internal apps, SSH/RDP, connecting a VPC or subnet — outbound-only, no inbound ports |
| Cloudflare Mesh (was WARP Connector) | Devices and networks to each other — full mesh, incl. client-to-client | Software on a Linux host (mesh node) | Site-to-site, device-to-device, replacing VPN mesh / bastion hosts |
| Cloudflare One Appliance (was Magic WAN Connector) | An entire branch site | A hardware or virtual appliance plugged into the office network | Connecting a whole office/data center — all devices, no per-device client |
💡 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.ymland credentials on the host (CLI). More control, useful for GitOps/automation.
A2 — Create a tunnel (dashboard)
- 👉 In the Cloudflare dashboard, go to Networking → Tunnels.
- 👉 Click Create a tunnel → choose Cloudflared → Next.
- ⌨️ Name it after what it connects, e.g.
enterprise-vpc-01→ Save tunnel. - 👉 Choose your server's operating system, copy the install command, and run it in a terminal on your origin server.
- 📺 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):
- 👉 On the tunnel's Routes tab → Add route → Published application.
- ⌨️ Enter a subdomain + pick a Domain (the zone must be in your account).
- ⌨️ Service URL = where the app runs locally, e.g.
http://localhost:8000. - 👉 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):
- 👉 Networking → Routes → Create route → Tunnel CIDR.
- 👉 Select your tunnel, enter the private range (e.g.
10.0.0.0/24). - 👉 (Optional) pick a virtual network if this range overlaps another route in your account.
- 👉 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
- 👉 In the dashboard, go to Networking → Mesh and start the setup wizard (interactive network map, node management, diagnostics).
- 👉 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.
- ⌨️ (Optional) add CIDR routes on the node so the subnets behind it (e.g.
192.168.20.0/24) are reachable across the mesh. - 👉 For a routed subnet that must stay online, add an active-passive replica node for high availability.
B2 — Verify
- 👉 After install,
pingthe 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
- 👉 Order/deploy the hardware appliance, or deploy the virtual appliance in your hypervisor/cloud.
- 👉 Cable WAN (Internet) and LAN (your network) ports; power on.
- 👉 It bootstraps (DHCP by default; static IP via serial console if needed) and registers to your account.
- 👉 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
| Need | Connector | Where |
|---|---|---|
| Publish one internal web app | Tunnel → Published application | Networking → Tunnels |
| Reach a private subnet by IP | Tunnel → Tunnel CIDR route | Networking → Routes |
| Site-to-site + device-to-device | Cloudflare Mesh | Networking → Mesh |
| Connect an entire branch office | Cloudflare One Appliance | Cloudflare WAN (Module 8) |
👉 Next: Module 5 — Gateway (Web Filtering)
Block threats and filter DNS/web traffic for everything now connected.