Three ways to bring your existing servers — EC2, VMs, on-prem boxes — into Zero Trust. Pick the tab that fits your environment.
The common thread: all three patterns use outbound-only connections from your environment to Cloudflare. No security group changes. No public IPs. No inbound firewall rules. The difference is just how much you install where.
Most common
cloudflared on the instance
Install the tunnel daemon on each box. Per-instance control. Works anywhere.
Whole VPC
Mesh node per VPC
One install per VPC, reaches every resource. No agents on the other boxes.
Enterprise
Magic WAN
Connect the whole network via IPsec / GRE. No agents anywhere.
How it works — cloudflared on each instance
Step 1
Create the tunnel
Dashboard: Networks → Tunnels → Create. Copy the install token.
Step 2
Install on EC2
SSH into the instance, run 3 commands. Done in 30 seconds.
Step 3
Connector phones home
Outbound port 443 to Cloudflare. Instance appears as "connected" in the dashboard.
Step 4
Add ingress rule
Map a hostname (app.your-domain.com) to the tunnel. Done.
Install commands
# On any EC2 instance with outbound internet egress:
curl -L --output cloudflared.deb \
https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
sudo cloudflared service install <your-tunnel-token># That's it. The instance is now connected. No security group changes.
Use this when
You're onboarding a handful of specific apps
You want per-instance control + visibility
The instance can run software (Linux, Windows, Mac, Docker)
Mixed cloud / on-prem / hybrid environment
Skip this when
You have 100+ servers — installing on each is too much
You can't put software on the target (appliance, database, RDP target)
You need to expose a whole subnet
How it works — one Mesh node per VPC
Step 1
Spin up one EC2
A small Linux box in the VPC that will act as the subnet router. Can be t3.micro — it's just relaying traffic.
Step 2
Install warp-cli
Two commands: install the package, register as a Mesh connector with your token.
Step 3
Advertise the CIDR
In dashboard: Networks → Mesh → Routes. Enter 10.0.0.0/16. Whole VPC now reachable.
Step 4
Add HA (optional)
Run a second Mesh node in another AZ. Active-passive failover, no human intervention.
Install commands
# On ONE Linux EC2 instance that will route the VPC's subnet:
curl https://pkg.cloudflareclient.com/install.sh | sudo bash
sudo apt install cloudflare-warp
sudo warp-cli connector new <your-mesh-token>
sudo warp-cli connect
# Then in the Cloudflare dashboard:# Networks → Mesh → Advertise routes → 10.0.0.0/16
Use this when
You want to onboard a whole VPC at once
Targets are databases, RDP, SAP, file shares — things you can't put cloudflared on
You don't want to manage agents on every server
You need bidirectional connectivity (server-to-server)
Skip this when
You only need a few specific HTTPS apps exposed
You want per-app rather than per-network policy
The Mesh node host is hard to maintain (use Option 3 instead)
How it works — network-level via Magic WAN
Step 1
Pick a link type
IPsec, GRE, CNI, or WARP Connector. IPsec is the default — most routers speak it natively.
Step 2
Configure both endpoints
In the Cloudflare dashboard: add the tunnel + shared key. On your router: configure the matching IPsec/GRE peer pointing at Cloudflare's anycast IPs.
Step 3
Add CIDR routes
Tell Cloudflare which subnets (e.g., 10.0.0.0/16) live behind the tunnel. Standard SD-WAN routing.
Step 4
Apply Gateway policies
Same Gateway, DLP, and Access policies you've configured already — now applied to the network traffic flowing through the tunnel.
The four ways to connect
1. IPsec tunnel
Most common. Standard encrypted tunnel any modern router speaks. Works with Palo Alto, Fortinet, Cisco ASA, AWS VPN Gateway, Azure VPN Gateway, GCP Cloud VPN.
2. GRE tunnel
Lighter weight, higher throughput. No built-in encryption — pair with another encryption layer if needed. Used when you need raw speed.
3. CNI (Network Interconnect)
Best performance. A literal physical or virtual cable between your network and Cloudflare's backbone — bypasses the public internet entirely. Available at Equinix, Megaport, AWS Direct Connect, Azure ExpressRoute, GCP Partner Interconnect.
4. WARP Connector
Software fallback. Runs on a Linux box inside the network when you can't touch the router itself. Same connectivity outcome, software-based instead of router-based.
What you configure (IPsec example)
# 1. In the Cloudflare dashboard: Magic WAN → Tunnels → Create IPsec Tunnel# Get back two Cloudflare anycast IPs + a pre-shared key (PSK)# 2. On your router (Palo Alto example):
set network ike crypto-profiles ike-crypto-profiles cf-ike encryption aes-256-cbc
set network ike gateway cf-gw protocol version ikev2-preferred
set network ike gateway cf-gw peer-address ip 162.159.65.x
set network tunnel ipsec cf-tunnel auto-key ike-gateway cf-gw
set network virtual-router default routing-table ip static-route to-cf nexthop tunnel cf-tunnel
# 3. In Cloudflare dashboard: Magic WAN → Routes → Add# Route 10.0.0.0/16 (your VPC) via the tunnel you just created# 4. Done — traffic from that CIDR now flows through Cloudflare
Use this when
You're connecting whole data centers or large on-prem networks
You want a true SASE / SD-WAN deployment that replaces MPLS
You can't put any software in the network
Your network team is involved and wants BGP / routing-level control
You want branch-to-branch traffic to ride Cloudflare's backbone
Skip this when
You're a small/mid team just trying to replace a VPN client — start with Option 1 or 2
You want per-app policy more than network-wide policy
You haven't got buy-in from the network team yet
How to choose: Most customers start with Option 1 for the first few apps — fastest to demo, lowest risk. They move to Option 2 when they're ready to onboard whole VPCs of legacy infrastructure without touching every server. Option 3 is the long-game answer for enterprise SD-WAN consolidation. You can use all three at the same time — they're not mutually exclusive.