Onboarding Internal Servers · Talk Track

Live-call companion for the /onboarding page. Five products on one page — cloudflared, Mesh, Magic WAN, Magic Transit, Spectrum. Your job in the call is to pick the right one for their environment, not to walk all five. Notes auto-save as you type. Export at the bottom.

Before the call · open these tabs

Don't open all five tabs of the demo page ahead of time. Land on the one that fits their environment, then use the others only if the conversation goes there.

Pre-call context · what do you know about their environment going in?

1. Open the page · frame what they are looking at ~2 min

Say this first, verbatim if you want: "This page shows five different ways to connect your internal servers to Cloudflare. They are not variants of the same product — they are five separate products, and picking the right one depends on three things about your environment. Rather than walk all five, I would like to ask you a couple of quick questions and then land on the one that fits you. Fair?"
Why this framing works: the page has five tabs, and the temptation is to walk through them left-to-right. Do not do that. Customers glaze over by tab 3. The page is a decision guide, not a product tour. Your job is to run the decision, not present the menu.

The three questions that pick the tab

Ask these three, in this order:
  1. "Are we connecting individual servers, or whole networks?"
  2. "Is the traffic web / HTTPS, or does it include databases, SSH, custom TCP, UDP, other protocols?"
  3. "Do you have your own IP space you need to keep announcing publicly?"
Their answers · which tab does this point at?
Cheatsheet — the five products in one line each:

Tab 1 · cloudflared — per-server tunnel

Install a small binary on one server. That server gets a public URL. No open ports.
Fits when: a handful of servers, HTTP or SSH/RDP, software install is allowed.

Tab 2 · Mesh (WARP Connector) — subnet-level connector

Install one Linux box per subnet. Everything on that subnet becomes reachable, no per-server install.
Fits when: many servers on a subnet, mixed protocols, cannot touch every server.

Tab 3 · Magic WAN — network-level SD-WAN / SASE

Router-to-Cloudflare tunnel. Whole data centers and branch offices ride on Cloudflare's backbone.
Fits when: replacing MPLS, connecting DCs and branches, network-team-owned project.

Tab 4 · Magic Transit — BGP anycast for whole IP blocks

Your /24 (or bigger) is announced from Cloudflare's edge. All traffic gets DDoS-scrubbed before hitting you.
Fits when: you must keep your public IPs (BYOIP), and/or you need L3 DDoS protection on non-HTTP traffic.

Tab 5 · Spectrum — any TCP/UDP port through the edge

Cloudflare-hosted proxy for any port — SSH, SMTP, custom TCP, gRPC, database, whatever.
Fits when: you need one specific non-HTTP protocol protected at the edge, and you do not want to install anything.

2. Tab 1 · cloudflared — per-server tunnel ~5 min

Open with: "This is the smallest thing on the page. It is a single binary called cloudflared that you run on a server. When it starts, it opens an outbound connection to Cloudflare and holds it open. Cloudflare gives that server a public URL. Traffic to the URL comes in through the tunnel and hits your server. You never open an inbound port. You never expose a public IP. There is no attack surface on the AWS side to scan."
The one-sentence value: "Your server makes an outbound phone call to Cloudflare and waits for work. There is nothing to break into because there is no front door."
What is on the tab: architecture diagram (server → outbound tunnel → Cloudflare edge → user), cloudflared install command for Linux/macOS/Windows, "when to use / when to skip" honest boundaries, and the connection between cloudflared and Cloudflare Access (identity on top of the tunnel).
Ask: "What is your current pattern for exposing internal apps to remote users?"
Their pattern today · VPN? Public LB? Reverse proxy? Nothing?
Ask: "How many servers are we talking about? Handful, or hundreds?"
Scale · a handful means cloudflared is a fit, hundreds means Mesh is a better fit
Ask: "Is software install on those servers allowed, or are they locked-down / air-gapped?"
Install constraint · if locked-down, Mesh (Tab 2) or Magic WAN (Tab 3) is the answer
The gotcha to be honest about: "cloudflared works great for HTTP, SSH, RDP, VNC — anything you can proxy through the Cloudflare edge. If you have a hundred servers, installing it on each one is fine. If you have a thousand, we should look at Mesh instead, which puts one connector per subnet rather than one per server."
The Access tie-in (say this if they seem interested): "Once the tunnel is up, you put Cloudflare Access in front of the public URL. Now the app only opens if the user has authenticated through your IdP — Okta, Azure AD, Google, whatever. Same policy engine that runs on your public sites, now protecting the internal one. No VPN client, no separate authentication portal."
Common question — "Is it a hosted service, or do I run something?": Both. You run cloudflared as a daemon on the server (a few MB of binary, systemd unit, done in ~5 min). Cloudflare hosts everything on the edge side. So the answer is "you run a tiny piece; we run the hard part."
Their reaction to Tab 1 · yes / no / follow-ups

3. Tab 2 · Mesh (WARP Connector) — subnet-level connector ~5 min

Open with: "Mesh is cloudflared's bigger sibling. Instead of one tunnel per server, you install one Linux box per subnet — we call it a WARP Connector — and everything on that subnet becomes reachable through Cloudflare. You do not touch every server. You install once per network segment."
The one-sentence value: "One install per subnet, not per server. Whole subnet reachable through Cloudflare with no changes to the servers themselves."
What is on the tab: architecture diagram (users → Cloudflare → WARP Connector Linux box → whole subnet), the install command for the connector, "when Mesh beats cloudflared" comparison (many servers, mixed protocols, no per-server install possible), and a note about mesh routing between multiple connector nodes.
Ask: "How many subnets are we talking about? One VPC, three VPCs, a dozen?"
Scale · Mesh is elegant for 1-10 subnets, gets heavier past that
Ask: "Are the servers behind that subnet a mix of protocols — HTTP, databases, SSH, custom TCP? Or are they mostly one thing?"
Protocol mix · Mesh shines when it is mixed; if it is all HTTP, cloudflared per-server is simpler
Ask: "Can you install a Linux VM inside each subnet? Is that operationally OK?"
Install constraint · if no Linux VM, we need Magic WAN (Tab 3) instead
The comparison to cloudflared, honestly: "cloudflared is one tunnel per server. Mesh is one connector per subnet. If you have 50 servers on one subnet, one Mesh connector reaches all 50. If you have 50 servers scattered across 50 subnets, Mesh is not the elegant answer — cloudflared per-server or Magic WAN network-level would be better."
The gotcha: "Mesh connectors are Linux only right now. If your subnets are Windows-only environments or air-gapped without a Linux presence, Mesh does not fit — we would move to Magic WAN or cloudflared. Also, connector redundancy matters. Deploy two per subnet, not one, so a single VM outage does not knock the whole subnet offline."
Common question — "How is this different from a VPN gateway?": A VPN gateway terminates inbound VPN connections and requires an open port. Mesh's WARP Connector is outbound-only — it dials Cloudflare, holds the connection open, and never accepts inbound traffic. Same functional outcome (subnet accessible from Cloudflare), different security posture (no inbound attack surface).
Their reaction to Tab 2 · yes / no / follow-ups

4. Tab 3 · Magic WAN — network-level SD-WAN / SASE ~5 min

Open with: "Magic WAN is the network-team version of everything you just heard. Instead of installing software anywhere, you stand up an IPsec or GRE tunnel from your router directly to Cloudflare. Whole subnets — whole data centers, whole branch offices — ride through the tunnel and out onto Cloudflare's backbone. Router-only deployment, no software inside the network."
The one-sentence value: "This is our SASE / SD-WAN product. Router-to-Cloudflare tunnel. Your wide-area network runs on our backbone instead of the public internet."
What is on the tab: architecture diagram (customer network → IPsec/GRE tunnel → Cloudflare backbone at 330+ edges → destination), four connection methods (IPsec, GRE, CNI, WARP Connector), a Palo Alto IPsec config example, "The fundamental difference" section (the argument that works against any SD-WAN vendor), vendor comparison cards (Zscaler, Palo Alto, Netskope, Cato, Cisco, Fortinet, VeloCloud, Aruba), Cloudflare's four-phase migration model, and resilience/SLA content.
Ask: "What are you running today for site-to-site — MPLS? SD-WAN? Point-to-point VPN?"
Their WAN today · incumbent shapes the whole conversation
Ask: "How many sites? Are they mostly connecting to each other, to the cloud, to SaaS, or to the internet?"
Traffic pattern · determines whether they need SASE, SD-WAN, or both
Ask: "Is your network team involved in this conversation? Magic WAN is a network-team project — not something the security team can drive alone."
Buy-in check · Magic WAN requires network + security together
The differentiator sentence to say verbatim: "Every other SD-WAN vendor is a networking company that built an overlay on top of the public internet. Cloudflare is the network — we own and operate the underlay that their overlays are riding on. That is why we can bundle SASE, SD-WAN, CDN, DDoS, WAF, and Zero Trust on the same PoP. Every other vendor either stitches those together with APIs or leaves you to buy them separately."
The test question to hand them: "Ask any SD-WAN or SASE vendor you evaluate — 'What percentage of the internet is within 50 ms of one of your PoPs?' Our answer is about 95%. Zscaler cannot answer, Cato has about 85 PoPs, VeloCloud does not own PoPs at all. That is the architectural difference. It is not marketing — it is math."
The migration comfort answer: "This is not a big-bang cutover. We publish a four-phase model — secure user access first (no network change), then connect networks (pilot site running parallel to MPLS), then secure egress (Gateway policies on tunnel traffic), then decommission MPLS on contract exit. Most customers spend 12-18 months in phase 4 alone because MPLS contracts run their course. That is expected, not a problem."
Common question — "Is this really SD-WAN, or is it just tunneling?": It is both. IPsec/GRE tunnels are the transport, and the routing decisions, path selection, policy inspection, and observability happen at Cloudflare's edge — which is exactly what SD-WAN is. The difference from Cisco/VMware SD-WAN is that our "edge" is 330+ cities of our own network, not a handful of vendor PoPs plus the public internet.
Common question — "What is the SLA?": Enterprise-only product, and the SLA is contractual — it lives in the customer's subscription agreement, not on a public page. The Business SLA is 100% uptime with service credits; Enterprise is typically stronger. Do not quote a number in the room — say "let's get your account team to walk through your specific SLA language."
Their reaction to Tab 3 · yes / no / follow-ups

5. Tab 4 · Magic Transit — BGP anycast for whole IP blocks ~5 min

Open with: "Magic Transit is where we announce your public IP space from Cloudflare's edge, on your behalf, using BGP. Your /24 or larger goes on our network. All traffic destined for those IPs gets scrubbed for DDoS at the edge — over 100 Tbps of scrubbing capacity — and the clean traffic is delivered to you over a tunnel or a physical cross-connect. Your users, your customers, your systems keep using the same IPs they always did. Nothing changes for them."
The one-sentence value: "You keep your public IP space. Cloudflare announces it globally and scrubs every packet before it reaches you. Works for HTTP and any other protocol on any port."
What is on the tab: architecture diagram (your /24 announced from Cloudflare edges → BGP → DDoS scrubbing → clean traffic via GRE tunnel or CNI back to you), BYOIP process, LOA and RPKI requirements, "when to use / when to skip" boundaries.
Ask: "Do you own your own IP space? A /24 or bigger, RIR-registered?"
BYOIP prerequisite · Magic Transit needs your own IP block, minimum /24 in most RIRs
Ask: "Why do you need to keep those IPs — hardcoded by partners, regulatory, historical DNS, embedded in devices?"
Reason for BYOIP · this determines whether Magic Transit is the answer or overkill
Ask: "What is your DDoS story today? Do you have anything at the network layer, or just at the application layer?"
DDoS posture · Magic Transit's real value is L3/L4 DDoS at scale
The differentiator: "Most DDoS scrubbing services are 'divert on attack' — traffic normally flows direct to you, and only reroutes through the scrubber when an attack is detected. That means the first few minutes of an attack still hit you. Magic Transit is 'always on' — every packet flows through Cloudflare's edge, all the time. There is no rerouting window. Attacks hit our capacity, not yours."
The BYOIP timeline reality: "Announcing your prefix from us takes real time — LOA to your RIR, RPKI ROA setup, IRR updates. Usually two to six weeks depending on which RIR (ARIN is fastest, RIPE is medium, APNIC and LACNIC are slower). If you need protection today for an active attack, Magic Transit is not the same-day answer — for same-day we would use Spectrum or the HTTP proxy instead."
Common question — "What if we only need to protect one app, not a whole /24?": Then Magic Transit is overkill. Use Spectrum (Tab 5) for a single non-HTTP app, or the Cloudflare HTTP proxy for an HTTP app. Magic Transit is for when you have an entire IP block that has to stay yours and stay announced.
Common question — "How is Magic Transit priced?": Enterprise contract, billed on clean traffic (p95 of what egresses to you after scrubbing). PNI or GRE connectivity is separate — the PNI cross-connect at Equinix or wherever is a physical circuit you order and pay for directly with the carrier, not through Cloudflare. Get the exact number from the account team; do not quote from memory.
Their reaction to Tab 4 · yes / no / follow-ups

6. Tab 5 · Spectrum — any TCP/UDP port through the edge ~5 min

Open with: "Spectrum is our edge proxy for non-HTTP protocols. You point a hostname at Cloudflare, tell us what port to listen on, tell us where to send the traffic on the other side, and we proxy it. Same DDoS scrubbing and edge network as our HTTP proxy, but for any TCP or UDP protocol — SSH, SMTP, gRPC, custom TCP, databases, whatever you have."
The one-sentence value: "Everything you love about putting Cloudflare in front of a website, but for the non-HTTP protocol you cannot put on port 443."
What is on the tab: architecture diagram (client → Cloudflare edge on custom port → tunnel or origin IP → your server), an example config for a Postgres database front-end, use-case tiles (database front-ends, SSH/RDP, SMTP, gaming/comms protocols), "when to use / when to skip" boundaries.
Ask: "Is there a specific non-HTTP protocol you are trying to protect or expose? What is the port?"
Protocol/port · Spectrum is per-port, per-application, so we need to know exactly what
Ask: "Is it one app, or many? Spectrum is priced per application."
Scope · one app is a clean fit; many apps starts looking like Magic Transit territory
The comparison to Magic Transit: "Spectrum protects an application. Magic Transit protects an IP block. If you have one Postgres server you want behind Cloudflare, that is Spectrum. If you have a whole /24 of your own IPs, that is Magic Transit. Some customers use both — Magic Transit for the network layer and Spectrum inside it for specific applications."
The gotcha: "Spectrum is priced per application. If you have 30 apps behind it, that is 30 line items — at some point Magic Transit becomes more economical, and we should have that conversation. If you have one or two apps, Spectrum is the right shape."
Common question — "Can Spectrum do TLS termination for a non-HTTP protocol?": Yes. If your protocol runs over TLS (Postgres SSL, encrypted SMTP, custom TLS on custom port), Spectrum can terminate the TLS at the edge and re-encrypt to your origin — or pass through end-to-end if you prefer. Certificates are managed the same way as HTTP proxying.
Common question — "Does Spectrum work with cloudflared?": Yes. Instead of pointing Spectrum at a public IP, you can point it at a Cloudflare Tunnel origin. That gives you Spectrum's edge-side protocol handling plus cloudflared's no-open-ports story. Both products in the same picture.
Their reaction to Tab 5 · yes / no / follow-ups

7. Close · confirm the pick and next step ~2 min

Landing line: "Based on what you just told me, the tab that fits your environment is [X]. The others are on the same page for reference, but that is the one we should build the POC around."
The mapping to remember:
Ask to close: "For the POC, are you comfortable if I set up a scoped trial on [product], with a walkthrough of the dashboard next week? I can pull [network team person] in if it is Magic WAN or Magic Transit."
Next step · what did they commit to?
Who else needs to be in the follow-up call?
Anything they said that surprised you, or that we should escalate internally?
Notes save automatically as you type