Personal study reference, not customer-facing. Covers all five Cloudflare network connectivity products — Cloudflare Tunnel, Cloudflare Mesh, Cloudflare WAN, Magic Transit, and Spectrum — the decision framework for picking between them, the architectural argument against SD-WAN/SASE competitors, and a real field-notes rollout (XC vs GRE design patterns from an actual Magic Transit deal). Includes a critical naming correction: two completely different products both used to be colloquially called "WARP Connector." Every fact below is sourced from live Cloudflare docs (full list at the bottom).
Five products answer five different connectivity questions. Options 1–3 protect your apps or network via agents/tunnels; Magic Transit protects your whole IP network at Layer 3; Spectrum is the fast, no-BGP bridge to either app-layer or L3 protection.
Critical naming disambiguation — read this before anything else. There are two completely different products that used to both be casually called "WARP Connector," and conflating them is a real, easy mistake:
| Old name | Current name | What it actually is |
|---|---|---|
| WARP Connector | Cloudflare Mesh (Apr 2026) | Software VPC/subnet mesh node — bidirectional, runs warp-cli |
| Magic WAN Connector | Cloudflare One Appliance (Feb 2026) | Zero-touch branch hardware/virtual appliance, specifically a Cloudflare WAN on-ramp |
These are genuinely different products. When you see "WARP Connector" referenced as one of several Cloudflare WAN link types, that's talking about the Cloudflare One Appliance context, not Cloudflare Mesh.
There's also a live interactive version of this decision wizard and the 6 on-ramp patterns (3 user-side, 3 server-side, "Animate all" plays through all six): cf-demo-app.dustinburke23nc.workers.dev/connectivity.
Step 1 — "Who connects to this service?" A known group (employees/contractors/ops) → private branch. The public internet (customers/partners/anyone) → public branch.
Step 2 (private) — "How much do you need to bring online?"
Step 2 (public) — "Do you own the IPs you want to protect?" No (hosting provider's IPs, no ASN, one app) → Spectrum. Yes (own a /24+, own ASN, can sign an LOA) → Step 3.
Step 3 — "Whole network or just one app?" Whole network/IP range, want the full DDoS stack → Magic Transit. Just one app/port, need it protected this week → Spectrum.
"Start with Cloudflare Tunnel for the first few apps — fastest to demo, lowest risk. Move to Cloudflare Mesh when onboarding whole VPCs of legacy infrastructure without touching every server. Cloudflare WAN is the SD-WAN/MPLS-replacement answer for enterprise. Magic Transit is a different animal — network-layer DDoS protection when you own IPs and need to protect everything on them, especially non-HTTP workloads like VoIP, backend services, or authoritative DNS. Spectrum is the fast lane — one TCP/UDP app protected in minutes, no BGP, no LOA; a great same-week bridge until Magic Transit is ready. These aren't mutually exclusive — many customers pair Spectrum today with Magic Transit later, or run Magic Transit for L3 protection AND Zero Trust for app access at the same time."
Publishes services outward without opening any inbound ports.
Install the cloudflared daemon. The most common pattern is one connector on a jump host that already has network reach, routing a whole private range through it (cloudflared tunnel route ip 10.0.0.0/16) — not one connector per server. Dials outbound on port 443 only (no inbound firewall changes, no NAT, no public IP needed). Users reach published resources through Cloudflare Access (SSO + MFA + device posture).
Install is 3 commands, roughly 30 seconds, zero security-group changes. HA is achieved by running several cloudflared processes against the same tunnel. The connector itself is free — billing is on Access seats, not the tunnel.
| Use | Skip |
|---|---|
| No inbound firewall changes needed; zero-trust identity at the app layer; works across Linux/Windows/macOS/Docker/K8s/ARM64/x86; mixed cloud and on-prem; fastest POC (~5 min) | Need bidirectional server-to-server flows (Tunnel is inbound-only toward resources) — use Mesh or Cloudflare WAN instead |
| Free connector, HA without extra config | Need non-HTTP L3 protection at scale for a public IP range — that's Magic Transit/Cloudflare WAN territory |
| — | Compliance requires zero third-party agents anywhere at all — even a jump-host connector counts as an agent; Cloudflare WAN's router-level IPsec/GRE puts nothing on a host |
Note, not a blocker: a single jump-host connector can serve a whole subnet/CIDR via private network routing — you don't need Mesh or Cloudflare WAN just to reach a range. Reach for those only when you specifically need bidirectional or agentless connectivity.
Renamed from WARP Connector in April 2026. Individual connected hosts are now called Mesh nodes. One small box per site reaches every resource in that network — bidirectionally.
One Linux box per site (VPC/DC/on-prem LAN) runs warp-cli headless and advertises that site's subnet. Any server reaches any other by private IP, bidirectionally, over TCP/UDP/ICMP, routed through Cloudflare where policy/identity apply. Nothing is installed on the other servers in that subnet.
| Cloudflare Mesh | Cloudflare Tunnel | |
|---|---|---|
| Traffic direction | Bidirectional — any participant can initiate | Inbound to origin — clients connect to published services |
| Connector | warp-cli | cloudflared |
| Protocols | TCP, UDP, ICMP | HTTP/S, TCP, SSH, RDP, SMB (over WebSocket) |
| Best for | Stable long-lived TCP: NFS, DB replication, RDP, SAP | Publishing apps or hostnames to users |
ha: true at creation time.Mesh node limit was raised from 10 to 50 per account as part of the April 2026 rename/update.
| Use | Skip |
|---|---|
| Onboard a whole VPC/subnet/LAN with one install | Only need a few HTTPS apps — a per-instance Tunnel connector is simpler |
| Targets you can't agent individually (RDS/Aurora, RDP, SAP, file shares, legacy Windows, network appliances) | Want per-app/hostname policy — Mesh routes by CIDR, layer Access on top instead |
| Bidirectional connectivity, long-lived TCP connections | Can't run an HA pair — a single node is a single point of failure |
Renamed from Magic WAN in February 2026 (same product, docs/dashboard nav updated, no action required, billing unchanged). Connects whole data centers, branch offices, and on-prem networks via network-level tunnels — no agents anywhere.
| Method | Notes |
|---|---|
| Cloudflare IPsec (formerly Magic WAN IPsec) | Most common; standard encrypted tunnel; works with Palo Alto, Fortinet, Cisco ASA, AWS/Azure/GCP VPN gateways |
| Cloudflare GRE (formerly Magic WAN GRE) | Lighter weight, higher throughput, no built-in encryption |
| Cloudflare Network Interconnect (CNI) | Best performance; physical/virtual cross-connect bypassing the public internet; available at Equinix, Megaport, AWS Direct Connect, Azure ExpressRoute, GCP Partner Interconnect |
| Cloudflare One Appliance (formerly Magic WAN Connector) | Zero-touch branch hardware/virtual appliance — software fallback for when you can't touch the router. Not the same product as Cloudflare Mesh (Module 3), despite both having been colloquially called "WARP Connector." |
BGP over IPsec/GRE reached General Availability on October 5, 2026 — available to all Unified Routing accounts, no enablement required, applies to both Cloudflare WAN and Magic Transit. BGP over CNI remains closed beta and is not available to new customers. The default routing model is still static routes with configurable priority and weight — BGP routes get a default priority of 100, and a static route at the same priority always wins the tie against a BGP route.
Recommended default: two tunnels per site to two different Cloudflare anycast IPs.
| Transition | Trigger | Priority penalty |
|---|---|---|
| Healthy → Degraded | ≥0.1% probe failures in 5 min (minimum 2 failures) | +500,000 |
| Healthy/Degraded → Down | 3 consecutive failures within 1 second | +1,000,000 |
| Down → Degraded | 3 consecutive successful probes | Reduced to +500,000 |
| Degraded → Healthy | <0.1% failure rate over the last 30 probes | Penalty removed |
Full recovery can take up to 30 minutes — intentional hysteresis to prevent rapid state flapping. Tunnels stay in a degraded/down state a minimum of 5 minutes regardless.
| Tier | Design | Covers |
|---|---|---|
| 1 — Standard | 2 IPsec tunnels, 2 anycast IPs, active/active ECMP | Single-tunnel + single-PoP failure. Default, covers most sites. |
| 2 — Redundant ISPs | 2 ISPs × 2 tunnels each = 4 tunnels | Also ISP failure. Recommended for HQ/primary DCs. |
| 3 — CNI + tunnel | CNI primary, IPsec warm backup | Also ISP failure, dedicated bandwidth. |
| 4 — Dual CNI | 2 physical CNIs from 2 diverse buildings | Building, carrier, ISP, and PoP failure. |
| Phase | What happens | Timeline |
|---|---|---|
| 1 — Secure user access | Deploy Cloudflare One Client on laptops, turn on Access for 2-3 apps. No network change. | Weeks 1-4 |
| 2 — Connect your networks | Pilot site: 2 IPsec tunnels to 2 nearest anycast IPs. Run parallel with existing MPLS, test 2-4 weeks. | Weeks 4-12 |
| 3 — Secure internet egress | Gateway policies, observe-mode then enforce-mode site by site, add Cloudflare Network Firewall. | Weeks 8-16 (overlaps phase 2) |
| 4 — Reduce infrastructure | Cut MPLS at contract renewal, retire branch firewalls/VPN concentrators. End state: every site is just an internet connection. | Months 6-18 |
Typical real-world timeline: pilot site live in 30 days, first three sites in 90 days, full MPLS decommission in 12-18 months. Phase 4 is bounded by contract exit dates, not technical readiness — most customers are technically ready 90 days in.
Three migration risks: (1) Asymmetric routing — outbound via the new tunnel, return via old MPLS causes a stateful firewall to drop the reply; fix with BGP local-preference steering both directions to the same tunnel during pilot. (2) Policy drift — the branch firewall has hundreds of organic rules of unclear purpose; fix with 4 weeks of Phase 3 observe-mode, comparing logs to find dead rules. (3) MPLS contract inertia — 3-5 year contracts already paid through a future date; plan the migration around contract exits, 12-18 months of parallel running is normal, not a problem.
The one argument that works against any SD-WAN or SASE vendor — and the honest caveats that keep it defensible in the room.
The sentence to say out loud: "Every other SD-WAN vendor is a networking company that built an overlay on top of the public internet. Cloudflare is the network itself — we own and operate the underlay that their overlays are riding on." This is not marketing — it's an architectural fact you can defend in any room.
Every SD-WAN product (VeloCloud, Viptela, Silver Peak, Fortinet, Versa, Cato) puts a box at each site, encrypts between boxes, and steers that traffic across internet connections the customer already has. The "SD" in SD-WAN is software-defined routing decisions on top of transport somebody else owns.
Standardize on these numbers (source: cloudflare.com/network, the actively-maintained page) — 348 cities, 100+ countries, 13,000+ network interconnections, sub-50ms to 95% of the world's internet-connected population (most within 20ms), and "1 in 5 sites on the Internet use Cloudflare" (20% of web properties — not a traffic-volume claim). Don't say "20% of internet traffic" — that's not Cloudflare's actual claim and a technical customer can push back on it. Note: Cloudflare's own secondary marketing/reference-architecture pages are internally inconsistent and still show stale "330+ cities" figures — don't be surprised if you see that elsewhere; this curriculum's numbers are the current source of truth.
Do not tell a customer that all their Cloudflare WAN traffic rides the private backbone edge-to-edge by default. For a lot of use cases it doesn't — once traffic hits the ingress edge and gets inspected, egress to the destination often goes out over regional peering or transit near that edge, not a guaranteed long-haul backbone trip. Guaranteed private-backbone middle mile requires deliberately turning on Argo Smart Routing or a CNI direct interconnect. The honest framing: nearest on-ramp and inline policy for everyone; guaranteed private-backbone middle mile is a design choice you turn on, not an automatic property of Cloudflare WAN.
"Show me your traffic map. What percentage of the internet is within 50 milliseconds of one of your PoPs?" Cloudflare's answer: ~95% of the internet-connected population. Most SD-WAN vendors can't answer this at all — they don't own PoPs, they run in AWS regions or customer data centers.
Competitor PoP-count claims are unverifiable from Cloudflare's own docs — Cloudflare doesn't publish competitor PoP counts. If you cite a specific number for Zscaler, Netskope, Cato, etc., source it from the vendor's own published material or an analyst report, not from memory, and expect it to be stale by the time you use it.
If a customer has a 50-site network entirely on private MPLS and is happy with it, ripping it out is multi-year regardless of vendor. If the traffic pattern is 95% intra-datacenter with tiny egress, they may not need a global backbone. The argument matters most for geographically distributed users, sites, or cloud workloads — most modern enterprises, but not all.
Not renamed — still Magic Transit as of late 2026. Different from the first three products: those protect your apps or network via agents/tunnels. Magic Transit protects your whole IP network — your IP addresses, your ASN, everything on your /24. Operates at Layer 3, covering TCP, UDP, ICMP, and custom protocols.
Cloudflare announces the customer's /24 from every colo via BGP anycast → an XDP/eBPF kernel filter and DDoS mitigation run at line rate → rate limiting/firewall rules apply → only clean traffic is forwarded to the customer's rack via tunnel or CNI → customer servers reply direct to the user via DSR (Direct Server Return), bypassing Cloudflare entirely on the way back.
Setup: (1) sign an LOA — same-day paperwork, customer keeps ASN/prefix ownership; (2) describe the rack (location, routers, transit provider); (3) pick a connectivity method; (4) verify and go live — Cloudflare tests the path and starts announcing the prefix worldwide.
"Your prefix 203.0.113.0/24 is announced from every Cloudflare data center. Attackers hit their nearest colo, not a central scrubbing hub — the attack surface becomes the whole planet."
Important clarifying detail — this is not full-table peering. Cloudflare sends the customer zero prefixes by default (optionally a 0.0.0.0/0 default route). The customer sends Cloudflare only their protected /24s. The BGP session's job is liveness and prefix-consent, not route distribution: session up = tunnel healthy; prefix announced = "keep sending clean traffic for this /24"; prefix withdrawn = graceful drain. Announce the same /24 from multiple sites for ECMP, or AS-path-prepend a backup site for standby. Return traffic goes out the customer's normal uplink via DSR — Cloudflare only sees ingress.
"A common misconception is that a 1 Gbps circuit costs you a full gig every month. It doesn't. Cloudflare bills on the sustained clean traffic we deliver to you — measured at the 95th percentile. Your circuit size is just capacity; attack traffic never counts toward your bill."
Worked example: 1 Gbps circuit (just the ceiling), ~200 Mbps typical clean traffic (95th percentile — this is what's billed), 600 Mbps attack absorbed and scrubbed at the edge (never reaches the rack, never appears on the invoice). A multi-terabit flood costs the same as no attack at all. Note: Magic Transit's billing is "95th percentile of clean bandwidth" (post-mitigation egress only) — a related but distinct model from Cloudflare WAN's general 95th-percentile billing; don't conflate the two products' billing language.
| Method | Notes |
|---|---|
| CNI — best fit if on-net | Physical/virtual cross-connect, ~0 hops latency, 10G/100G/400G available, skips public-internet transit egress fees on return. Takes 2-4 weeks + LOA; unencrypted (use IPsec if compliance requires encrypted transit). |
| GRE tunnel — classic | Unencrypted, same-day, no LOA/cross-connect. Skip if compliance requires encryption, or the transit provider filters GRE. |
| IPsec tunnel — encrypted | IKEv2 + BGP, same-day deploy. Skip if already on-net for CNI (strictly better), or want max throughput without the crypto tax. |
| Cloudflare One Appliance — software | For when you can't touch the router (managed/ISP-locked/shared appliance). ~10-minute install on any Linux VM, no BGP config, no LOA, outbound 443 only. Usually paired with tunnels above rather than replacing them for full L3 protection — shines for Zero Trust private networking, not full DDoS-in-front L3. |
Common rollout pattern: "Start on GRE or IPsec today to get DDoS protection in place ASAP. If you're in a Cloudflare-on-net facility, order the CNI cross-connect in parallel — it takes 2-4 weeks. Once CNI is live, keep the tunnel as a backup path. Cloudflare's per-colo health probes prefer CNI when healthy, fail over to the tunnel automatically. You never lose protection."
| Use | Skip |
|---|---|
| Own IPs/ASN, need L3 DDoS for the whole network | Don't own IPs — use Spectrum instead |
| Non-HTTP or mixed workload (backend, VoIP/SIP, authoritative DNS, MQTT, RTP, proprietary L4) | Only need a few HTTPS apps — a standard Cloudflare zone is cheaper and gives WAF+Bot Management |
| Want DSR — origin sees real client IPs, no SNAT/PROXY headers | Need same-week protection and aren't near an on-net facility — bridge with Spectrum |
| Same DDoS stack that protects cloudflare.com itself | ASN isn't BGP-capable / no BGP staff |
Gotchas: asymmetric routing kills Magic Transit deployments — return traffic must ride the Cloudflare onramp back out. Minimum announcement is a confirmed /24 (IPv4) — smaller allocations won't work (though customers without a /24 can lease a Cloudflare-owned IP instead, no LOA required). Licensing is by clean-traffic Gbps commit — spiky traffic needs careful sizing with the account team.
From an actual Magic Transit deal (Chicago + London rollout). The honest answer to a real customer concern about Cloudflare-side hardware failure.
The honest answer to the concern. Yes — a direct XC terminates on a specific Cloudflare router in a specific building. If that router fails, that path is down until restored. GRE uses anycast, which reconverges to the next Cloudflare data center automatically. That's the core tradeoff, and it's the reason production CNI deployments are almost always built with redundant paths rather than a single XC.
Traffic encapsulates in GRE, rides ISP uplinks over the public internet, lands at whichever Cloudflare DC is topologically closest. If that DC fails, the anycast route withdraws and traffic reconverges to the next closest DC within seconds — you do nothing.
Physical fiber cross-connect into a specific Cloudflare router, then onto the backbone. Better latency and jitter, doesn't touch the public internet — but if that specific router or XC fails, the path is down until repair.
| Aspect | GRE tunnel | Direct XC (CNI) |
|---|---|---|
| Where it terminates on Cloudflare | Anycast IP, resolved to the closest of many DCs | A specific router in a specific building |
| Path | Public internet via your ISPs | Physical fiber into Cloudflare's backbone |
| Impact of one Cloudflare router failing | None — anycast routes around it | BGP session drops, path unavailable until restored |
| Impact of a fiber cut | N/A | Path down until the facility repairs it |
| Cost | No direct connectivity cost, rides your existing ISP | XC monthly cost to the facility, port cost from Cloudflare |
The point: XC gives better performance. GRE gives inherent anycast resilience. Neither is strictly better — the right production design combines them, or uses redundant XCs, so a single Cloudflare-side hardware event doesn't take you offline.
Option A — Two XCs to two Cloudflare routers in the same building (Solid). Protects against single router/port/fiber failure. Doesn't protect against a whole-building event. Cost: two XC fees, two Cloudflare ports.
Option B — One XC in the primary facility plus one XC in a diverse facility (Most resilient). Protects against everything Option A does, plus whole-building failure. Requires a footprint in the second facility — a real cost beyond just the XC. Pick this when SLA or compliance requires facility-level redundancy.
Option C — One XC plus a GRE tunnel as warm backup (Best cost-to-resilience ratio). BGP policy prefers the XC path when up; if the XC or Cloudflare-side router fails, BGP withdraws the route and traffic falls back to the GRE tunnel, landing at the nearest DC via anycast. Recovery is BGP reconvergence — typically single-digit seconds. One XC fee, one port, no additional facility cost — GRE rides existing ISP uplinks.
The design to avoid: one XC with no backup path at all. A single XC is a single point of failure at the Cloudflare-side hardware layer — if the port, router, or fiber fails, traffic stops on that path until repair. Not hypothetical; this is exactly the failure mode a cautious customer should be asking about.
Recommendation pattern used on this real deal: Option C for the initial rollout site (one XC as primary, one GRE tunnel as warm backup) — cheapest resilient design, gets the latency/jitter benefit of direct connectivity plus anycast resilience as a safety net. Same pattern repeated at the second site for operational consistency. Upgrade to Option B only if SLA/compliance specifically requires facility-level redundancy.
Cross-connects at a carrier-neutral facility (e.g. Equinix) are ordered by the customer of record directly through that facility's portal — the facility bills the customer for the monthly cost. Cloudflare does not resell XCs, so Cloudflare's own facility pricing doesn't flow through to the customer. What Cloudflare covers: the Cloudflare-side port, the Cloudflare-side patch to reach its cage, and BGP peering configuration/operational support. What the customer pays the facility directly: the XC monthly cost, and any fabric costs if using a virtual cross-connect instead of physical fiber. If the customer already has a footprint in the facility, or can reach it economically through a fabric product from a nearby facility, the XC economics stay reasonable — provisioning brand-new cage space just for this is a real cost worth putting on the table explicitly.
Cloudflare in front of a single TCP/UDP application. Where Magic Transit protects a whole IP range at L3, Spectrum reverse-proxies one application on one port at L4 — no BGP, no LOA, no on-net requirement.
Clients connect to app.example.com:5432; the DNS record points at Cloudflare; Cloudflare proxies to the origin over the internet. Same anycast network, same DDoS scrubbing as Magic Transit, scoped to a single application. Setup: (1) add a Spectrum application in the dashboard — pick TCP/UDP, port, origin IP:port, Cloudflare provisions an anycast listener across its network; (2) point DNS at Cloudflare; (3) lock the origin down to only accept Cloudflare IP ranges.
| Magic Transit (L3) | Spectrum (L4) | |
|---|---|---|
| Scope | Entire network — every IP, every port | One app on one port at a time |
| Whose IPs? | Yours — Cloudflare announces your /24 via BGP | Cloudflare's — you use a Cloudflare hostname/IP |
| Deploy time | Weeks — LOA, BGP peering, on-ramp config | Minutes — dashboard + DNS record |
| Return path | DSR — server replies bypass Cloudflare, real client IPs | Via Cloudflare — reverse proxy, client IP in PROXY header |
| Best for | Owning IPs, whole-range protection, non-HTTP fleets | Individual apps, don't own IPs, need it today, or piloting before Magic Transit |
"Magic Transit is the right long-term answer for whole-network L3 protection — but it takes BGP peering, LOAs, and weeks of setup. If you just need to shield one TCP or UDP application, Spectrum gets you protected in minutes."
UDP is Enterprise-only, and it's a paid add-on even on Enterprise — not automatically bundled. Each Spectrum application is bound to a specific port or port range; only configured ports/apps are proxied, unconfigured ports on the same IP are dropped (no automatic coverage of an arbitrary port range). Caveat: Pro/Business do get a handful of narrow, pre-built app types for free even though generic/arbitrary TCP/UDP/HTTP/HTTPS is Enterprise-gated — e.g. Minecraft (UDP/TCP) is available on Pro+, SSH on Pro+, RDP on Business+. Don't over-claim "zero UDP below Enterprise" — be specific about generic vs. pre-built app types.
| Use | Skip |
|---|---|
| Protect a specific TCP/UDP app, not the whole network | Need to protect the whole network — use Magic Transit |
| Don't own IPs and don't want to (cloud-hosted, colo tenants, MSPs reselling) | Need DSR for real client IPs and can't parse the PROXY protocol |
| Need protection this week — DNS-record deploy, no BGP/LOA | Many apps to protect — per-app pricing is less efficient than Magic Transit at scale (~10+ apps) |
| On-ramp to Magic Transit — migrate once owning IPs/BGP is ready | HTTP/HTTPS workload — a standard Cloudflare zone is cheaper and includes WAF+Bot Management+Rate Limiting |
Gotcha: the real client IP arrives via PROXY protocol v1/v2 (or Cf-Connecting-IP for HTTP) — the application must be configured to accept and parse it, or it will see Cloudflare's IP as the source.
| Old name | Current name | When |
|---|---|---|
| Magic WAN | Cloudflare WAN | Feb 17, 2026 |
| Magic WAN IPsec | Cloudflare IPsec | Feb 17, 2026 |
| Magic WAN GRE | Cloudflare GRE | Feb 17, 2026 |
| Magic WAN Connector | Cloudflare One Appliance | Feb 17, 2026 |
| Magic Firewall | Cloudflare Network Firewall | Feb 17, 2026 |
| Magic Network Monitoring | Network Flow | Feb 17, 2026 |
| Magic Cloud Networking | Cloudflare One Multi-cloud Networking | Feb 17, 2026 |
| WARP Connector | Cloudflare Mesh (nodes = "Mesh nodes") | Apr 14, 2026 |
| Magic Transit | Not renamed — still Magic Transit | — |
| Scenario | Product |
|---|---|
| A handful of specific servers, OK installing a small daemon | Cloudflare Tunnel |
| Whole VPC/subnet of legacy infra, can't agent each box | Cloudflare Mesh |
| Whole enterprise, replacing MPLS/SD-WAN | Cloudflare WAN |
| Own IPs/ASN, need whole-network DDoS at L3, non-HTTP workload | Magic Transit |
| Don't own IPs, or need same-week protection for one app | Spectrum |
| Branch office needs a zero-touch hardware on-ramp to Cloudflare WAN | Cloudflare One Appliance |
| Customer can't touch the router at all for Magic Transit | Cloudflare One Appliance (paired with a tunnel, not a full L3 replacement) |
| Product | Availability |
|---|---|
| Cloudflare Tunnel (cloudflared) | Free connector; billing is on Access seats |
| Cloudflare Mesh | Zero Trust plan-gated; 50 Mesh nodes per account |
| Cloudflare WAN | Enterprise-only, negotiated contract, 95th-percentile bandwidth billing |
| Magic Transit | Enterprise-only, clean-traffic Gbps commit, minimum /24 |
| Spectrum (generic TCP/UDP/HTTP/HTTPS) | Enterprise-only paid add-on |
| Spectrum (pre-built app types: Minecraft, SSH) | Available on Pro+ |
| Spectrum (pre-built: RDP) | Available on Business+ |
| Business-plan 100% uptime SLA | Core CDN/DNS/WAF plan only — not Cloudflare WAN or Magic Transit, which are contract-negotiated separately |
"Is Magic Transit getting renamed like everything else?"
No — Magic Transit was explicitly excluded from the February 2026 rename wave and still carries its original name.
"What's the difference between Cloudflare Mesh and the Cloudflare One Appliance? Aren't they both 'WARP Connector'?"
They used to both be casually associated with that name, but they're different products with different renames: WARP Connector → Cloudflare Mesh (software VPC mesh node, April 2026); Magic WAN Connector → Cloudflare One Appliance (branch hardware/virtual appliance for Cloudflare WAN, February 2026). Don't conflate them.
"Can we get BGP on Cloudflare WAN now?"
Yes — BGP over IPsec/GRE reached General Availability on October 5, 2026, for all Unified Routing accounts, no enablement needed. BGP over CNI is still closed beta and not open to new customers.
"What's our actual SLA on Magic Transit or Cloudflare WAN?"
It's Enterprise-only and contract-negotiated — not a public, quotable number. Don't confuse it with the public Business-plan SLA (100% uptime, 1x service credits), which applies to the core CDN/DNS/WAF plan only.
"A customer wants a hard guarantee their Cloudflare WAN traffic stays on the private backbone end-to-end. Can we promise that?"
Not by default. Traffic gets inline policy and a nearby on-ramp everywhere, but egress from the ingress edge often rides regional peering, not a guaranteed backbone trip. A guaranteed backbone middle mile requires turning on Argo Smart Routing or a CNI direct interconnect — it's a deliberate design choice, not automatic.
"Customer doesn't own their IPs but wants DDoS protection for a database port. What do we sell them?"
Spectrum — don't need owned IPs or BGP, just a DNS record and a Spectrum application pointed at the right port. Magic Transit requires owning a /24 and an ASN.
"How fast does Cloudflare WAN fail over if a tunnel drops?"
Sub-second to a few seconds for the second tunnel to pick up load. If the issue is a whole PoP, the tunnel re-establishes at the next-nearest one automatically since it's bound to an anycast IP, not a specific PoP.
Click a question to reveal the answer. No peeking before you commit to one.
Magic Transit — it was excluded from the February 2026 rename wave and still carries its original name.
Cloudflare Mesh (formerly WARP Connector proper — the software VPC mesh node, renamed April 2026) and Cloudflare One Appliance (formerly Magic WAN Connector — the branch hardware/virtual appliance, renamed February 2026). They are different products.
Yes for IPsec/GRE — BGP over IPsec/GRE reached General Availability on October 5, 2026, available to all Unified Routing accounts with no enablement needed. BGP over CNI is still closed beta, not open to new customers.
Inbound traffic (Mesh clients to the subnet) fails over automatically on Cloudflare's network. Outbound traffic (devices on the subnet leaving through the node) does not auto-fail over — the customer's environment must detect the newly-promoted replica and update routing tables.
No — HA must be set at node creation time and cannot be changed afterward. It also requires MASQUE transport; WireGuard transport does not support HA at all.
False — traffic gets a nearby on-ramp and inline policy everywhere, but egress from the ingress edge often rides regional peering, not a guaranteed backbone trip. A guaranteed private-backbone middle mile requires deliberately enabling Argo Smart Routing or a CNI interconnect.
Accurate: "1 in 5 websites on the Internet use Cloudflare" (20% of web properties) and 348 cities, 100+ countries. Common mistake: saying "Cloudflare sees 20% of all internet traffic" — that's not Cloudflare's actual claim and conflates web-property share with traffic volume. Also watch for stale "330+ cities" figures still floating around Cloudflare's own secondary marketing pages.
Don't quote a specific number from memory — Magic Transit and Cloudflare WAN SLAs are Enterprise-only and contract-negotiated, not a public quotable figure. Don't confuse this with the public Business-plan SLA (100% uptime, 1x service credits), which applies only to the core CDN/DNS/WAF plan.
On sustained clean traffic at the 95th percentile — not the circuit's line-rate capacity, and not any absorbed attack traffic. A 1 Gbps circuit with ~200 Mbps typical traffic and a 600 Mbps attack is billed on roughly 200 Mbps; the attack costs nothing extra.
Minimum is a /24 — smaller allocations aren't globally routable enough to onboard directly. Customers without a /24 of their own can instead lease a Cloudflare-owned IP, no LOA required.
Option C — one XC plus a GRE tunnel as warm backup. BGP prefers the XC path when healthy; if it fails, traffic falls back to GRE via anycast in single-digit seconds. One XC fee instead of two, no second-facility cost, yet still protects against router/fiber/whole-building failure at the primary site.
Generally no — cross-connects are ordered and billed by the customer of record directly through the facility's own portal. Cloudflare doesn't resell XCs, so Cloudflare's facility pricing doesn't flow through to the customer.
Spectrum — Magic Transit requires owning a /24 and an ASN with BGP capability. Spectrum needs no owned IPs, no BGP, no LOA — just a DNS record and a Spectrum application pointed at the port.
Generic/arbitrary UDP is Enterprise-only, and it's a paid add-on even there. However, a few narrow pre-built app types are available lower down — e.g. Minecraft (UDP/TCP) on Pro+. Don't claim "zero UDP below Enterprise" without that caveat.
ARR learns flow state on ingress and routes the reply back on the same connection automatically — no static return route needed, and it enables overlapping RFC1918 address space across sites (useful for M&A/multi-tenant scenarios). It's now GA for Internet-bound return traffic (WAN-to-WAN return routing isn't supported yet) — no longer purely beta.
ML-KEM-1024 for Cisco 8000 Series routers on IOS XR 26.1.1. FortiOS 7.6.6+ supports both ML-KEM-768 and ML-KEM-1024 — don't assume the two vendors use the same variant.
"Every other SD-WAN vendor is a networking company that built an overlay on top of the public internet. Cloudflare is the network itself — we own and operate the underlay that their overlays are riding on." Paired with the honest caveat that this isn't always decisive — a happy 50-site MPLS customer or a mostly-intra-datacenter traffic pattern won't feel the difference as strongly.