Connectivity options
Cloudflare One provides multiple connectivity options for your users, devices, and network infrastructure. Each option serves different use cases, from protecting individual devices to connecting entire data centers.
This page helps you understand which connectivity options to use based on your requirements, and how to combine multiple options in a single deployment.
Cloudflare One connectivity options use the concept of on-ramps and off-ramps:
- On-ramps send traffic into Cloudflare's network. For example, a user's device with the Cloudflare One Client installed on-ramps their traffic to Cloudflare for inspection and policy enforcement.
- Off-ramps send traffic from Cloudflare's network to your infrastructure. For example, Cloudflare Tunnel off-ramps traffic to your private applications without exposing them to the public Internet.
Some connectivity options support both directions (bidirectional), while others only support one direction.
The following table provides a high-level comparison of all connectivity options available to Cloudflare One customers.
Table 1: All Cloudflare One connectivity options
| Connectivity option | Protocol | Direction | Typical deployment model | Use when |
|---|---|---|---|---|
| Cloudflare Tunnel | HTTP/2, QUIC | Off-ramp only | Software daemon (cloudflared) on server | Exposing private applications without a public IP |
| Cloudflare One Client | MASQUE (default), WireGuard | Bidirectional | Client software on end-user devices | Securing remote workforce devices |
| Cloudflare Mesh | MASQUE | Bidirectional | Software client on Linux host | Connecting sites with IoT or VoIP devices |
| DNS locations | DNS (DoH, DoT, IPv4/IPv6) | On-ramp only | DNS resolver configuration | Filtering DNS traffic without device agents |
| Proxy endpoints | HTTP/HTTPS | On-ramp only | Browser PAC file configuration | Filtering web traffic without device agents |
| Clientless Web Isolation | HTTP/HTTPS | On-ramp only | Prefixed URL with Access authentication | Secure web access for unmanaged devices |
| GRE tunnels | GRE | Bidirectional | Network tunnel from router or firewall | Connecting sites with existing network hardware |
| IPsec tunnels | IPsec | Bidirectional | Network tunnel from router or firewall | Encrypted site connectivity over the Internet |
| Cloudflare One Appliance | IPsec | Bidirectional | Hardware or virtual appliance | Zero-touch branch office deployments |
| Cloudflare Network Interconnect | Direct, Partner, Cloud | Bidirectional | Physical or virtual cross-connect | Bypassing the public Internet entirely |
| Multi-Cloud Networking | IPsec (automated) | Bidirectional | Cloud provider VPN integration | Connecting cloud VPCs with automated tunnel setup |
Cloudflare Tunnel provides a secure way to connect your resources to Cloudflare without a publicly routable IP address. The cloudflared daemon creates outbound-only connections to Cloudflare's global network over port 7844 (TCP/UDP) using HTTP/2 or QUIC. This allows you to expose web servers, SSH servers, remote desktops, and other services without opening inbound ports on your firewall.
Use Cloudflare Tunnel when you need to expose private web applications, protect origin servers by hiding their IP addresses, or deploy cloud-native ingress for Kubernetes services.
For detailed configuration, refer to the Cloudflare Tunnel documentation.
The Cloudflare One Client is a device agent that securely connects end-user devices to Cloudflare's global network. The Cloudflare One Client encrypts traffic from the device using MASQUE (with post-quantum cryptography) or WireGuard and routes it through Cloudflare, where Gateway policies filter and inspect the traffic.
Use Cloudflare One Client to secure remote workforce devices, replace traditional VPN solutions, enforce DNS filtering and web security policies, implement device posture checks, and enable Mesh connectivity between enrolled devices.
For detailed configuration, refer to the Cloudflare One Client documentation.
Cloudflare Mesh connects your services and devices with post-quantum encrypted networking. Every enrolled device and mesh node receives a private Mesh IP and can communicate with any other participant over TCP, UDP, or ICMP — including device-to-device without any infrastructure.
Mesh nodes run the Cloudflare One Client (warp-cli) in headless mode on Linux servers. They can advertise CIDR routes to make subnets behind them reachable, enabling connectivity to devices that cannot run the client (IoT, printers, legacy servers). All traffic preserves source IP addresses end-to-end.
Use Cloudflare Mesh for bidirectional connectivity (VoIP, SIP, AD updates, SCCM, DevOps), site-to-site networking, device-to-device connectivity, or any scenario where source IP preservation is important. For outbound-only access to private services, Cloudflare Tunnel (cloudflared) is simpler to deploy and runs on all platforms.
For detailed configuration, refer to the Cloudflare Mesh documentation.
DNS locations allow you to filter DNS traffic from networks without deploying the Cloudflare One Client. By configuring your network's DNS resolver to point to Cloudflare Gateway, Gateway applies DNS policies to all queries from that location.
DNS locations support multiple endpoint types:
- IPv4/IPv6: Standard DNS resolution using Cloudflare's resolver IPs
- DNS over HTTPS (DoH): Encrypted DNS queries over HTTPS
- DNS over TLS (DoT): Encrypted DNS queries over TLS
Use DNS locations when you need to filter DNS traffic for an entire office or network, per device without installing agents on devices, or integrate with existing network infrastructure.
For detailed configuration, refer to the DNS locations documentation.
Proxy endpoints allow you to apply Cloudflare Gateway HTTP policies without installing a client on devices. By configuring a Proxy Auto-Configuration (PAC) file at the browser level, you route web traffic through Gateway for filtering and policy enforcement.
Cloudflare One supports two types of proxy endpoints:
- Authorization endpoints: Use Cloudflare Access for identity-based authentication
- Source IP endpoints: Authorize traffic based on originating IP address (Enterprise only)
Use proxy endpoints when you need to filter web traffic without device agents, integrate with existing proxy infrastructure, or deploy Gateway alongside other security tools.
For detailed configuration, refer to the Proxy endpoints documentation.
Clientless Web Isolation allows users to securely access web applications through a remote browser without installing the Cloudflare One Client. Users navigate to a prefixed URL (https://<team-name>.cloudflareaccess.com/browser/<URL>), authenticate through Cloudflare Access, and Cloudflare renders the web content in an isolated browser, streaming only safe draw commands ↗ to the user's device while enforcing isolation policies.
Use Clientless Web Isolation when you need to provide secure web access for unmanaged devices (contractors, BYOD), enable access to sensitive applications without requiring endpoint software, or on-ramp users who cannot install the Cloudflare One Client.
For detailed configuration, refer to the Clientless Web Isolation documentation.
Generic Routing Encapsulation (GRE) tunnels provide lightweight, stateless network connectivity between your infrastructure and Cloudflare. GRE tunnels are used with Cloudflare WAN (formerly Magic WAN) and Magic Transit to connect sites, data centers, and cloud environments using existing routers and firewalls.
Use GRE tunnels when you need to connect branch offices or data centers with minimal configuration overhead, integrate with Magic Transit for DDoS protection, or deploy redundant tunnels alongside IPsec.
For detailed configuration, refer to the GRE and IPsec tunnels documentation.
IPsec tunnels provide encrypted, stateful network connectivity between your infrastructure and Cloudflare. IPsec tunnels are used with Cloudflare WAN and Magic Transit for secure site-to-site connectivity, using IKEv2 for tunnel negotiation and AES-GCM or AES-CBC for encryption.
Use IPsec tunnels when you need to encrypt traffic over the public Internet, meet compliance requirements for encrypted connections, or replace expensive MPLS links.
For cloud environments (AWS, Azure, GCP), use Multi-Cloud Networking to automate IPsec tunnel creation instead of configuring tunnels manually.
For detailed configuration, refer to the GRE and IPsec tunnels documentation.
Cloudflare One Appliance (formerly Magic WAN Connector) is a plug-and-play SD-WAN appliance that automates connectivity to Cloudflare's network. It establishes IPsec tunnels automatically and provides traffic steering and shaping. You can deploy it as a hardware appliance (Dell VEP1460) or virtual appliance (VMware ESXi, Proxmox).
Use Cloudflare One Appliance for zero-touch branch office deployments, to replace edge routers, achieve high throughput (1 Gbps or higher), or manage multiple sites through a centralized dashboard.
For detailed configuration, refer to the Cloudflare One Appliance documentation.
Cloudflare Network Interconnect (CNI) allows you to connect your network infrastructure directly to Cloudflare through private, dedicated connections that bypass the public Internet. CNI provides predictable latency, consistent throughput, and reduced exposure to attacks.
Use CNI when you need to meet security requirements that prohibit public Internet traffic, reduce cloud egress costs, or deploy in highly regulated industries (financial services, healthcare).
The following table describes the Cloudflare Network Interconnect (CNI) connection types.
Table 2: Cloudflare One CNI connection types
| Type | Description | Ideal for |
|---|---|---|
| Direct Interconnect | Physical fiber cross-connect in a shared data center | Customers colocated with Cloudflare who require maximum control and performance |
| Partner Interconnect | Virtual connection through connectivity partners (Megaport, Equinix Fabric, PacketFabric) | Customers not colocated with Cloudflare or who prefer managed connectivity |
| Cloud Interconnect | Private connection from cloud providers (AWS, GCP, Azure) | Customers with workloads in public clouds requiring private connectivity |
For detailed configuration, refer to the Cloudflare Network Interconnect documentation.
Multi-Cloud Networking (formerly Magic Cloud Networking) is an automation layer that simplifies connecting cloud environments to Cloudflare WAN. Rather than manually configuring IPsec tunnels, Multi-Cloud Networking automatically discovers your cloud resources and creates the necessary VPN tunnels and routes on both sides (cloud provider and Cloudflare WAN).
Multi-Cloud Networking is not a separate tunnel type — it orchestrates your cloud provider's native VPN functionality (AWS VPN Gateway, Azure VPN, GCP Cloud VPN) to establish IPsec connectivity to Cloudflare WAN.
- Connect AWS, Azure, or GCP VPCs to Cloudflare WAN with minimal configuration
- Automate tunnel and route creation instead of manual IPsec setup
- Connect multiple VPCs through a hub architecture (AWS Transit Gateway)
- Simplify multi-cloud networking across different providers
The following table describes the Multi-Cloud Networking on-ramp types.
Table 3: Cloudflare One Multi-Cloud Networking on-ramp types
| Type | Description | Use when |
|---|---|---|
| Single VPC | Connects one VPC directly to Cloudflare WAN via VPN tunnel | You have a single VPC to connect |
| Hub | Connects multiple VPCs through a cloud hub (for example, AWS Transit Gateway) | You need to connect multiple VPCs with inter-VPC communication |
- AWS (single VPC and hubs)
- Azure (single VPC)
- GCP (single VPC)
- Azure VNet sizing: Multi-Cloud Networking creates a GatewaySubnet (
/27) within your VNet for the Azure VPN Gateway. Ensure your VNet has sufficient address space. A/20or larger VNet is recommended to avoid address exhaustion. - Cloud provider costs: Multi-Cloud Networking uses your cloud provider's native VPN services. Standard VPN gateway and data transfer costs from your cloud provider apply in addition to Cloudflare WAN costs.
- Tunnel creation time: Cloud provider VPN gateways can take 15-45 minutes to provision. Plan for this delay when onboarding new VPCs.
For detailed configuration, refer to the Multi-Cloud Networking documentation.
The following table maps common requirements to recommended Cloudflare One connectivity options. These are not exhaustive recommendations.
Table 4. Recommend Cloudflare One connectivity options for common requirements
| Requirement | Recommended option |
|---|---|
| Expose a private web application without a public IP | Cloudflare Tunnel |
| Secure end-user devices | Cloudflare One Client |
| Replace traditional VPN for remote access | Cloudflare Tunnel (primary) + Cloudflare Mesh (for bidirectional needs) |
| Connect a site with IoT devices or VoIP systems | GRE or IPsec tunnels (from existing router/firewall), Cloudflare One Appliance (zero-touch deployment), or Cloudflare Mesh (requires a Linux host) |
| Connect a branch office using existing routers | GRE or IPsec tunnels |
| Encrypt traffic over the public Internet | IPsec tunnels |
| Zero-touch branch office deployment | Cloudflare One Appliance |
| Connect cloud VPCs (AWS, Azure, GCP) with minimal configuration | Multi-Cloud Networking |
| Bypass the public Internet entirely | Cloudflare Network Interconnect |
| High-throughput enterprise connectivity | Cloudflare One Appliance or CNI |
The team driving your Cloudflare One connectivity project influences which option provides the smoothest adoption path. The following table provides examples.
Table 5. Cloudflare One connectivity recommendations for teams
| Primary team | Recommended starting point | Rationale |
|---|---|---|
| Security / InfoSec | Cloudflare Tunnel + Cloudflare One Client | Minimal network infrastructure changes required. Security controls are managed within the Cloudflare One dashboard. |
| Network Operations | Cloudflare WAN (IPsec/GRE) or Cloudflare One Appliance | Familiar routing and tunnel configuration. Integrates with existing network equipment and workflows. |
| DevOps / Platform Engineering | Cloudflare Mesh or Cloudflare Tunnel | Software-defined deployment. Scriptable via API. No hardware dependencies. |
| Facilities / Branch IT | Cloudflare One Appliance | Zero-touch deployment with centralized management. No on-site networking expertise required. |
Cloudflare Mesh and Cloudflare One Appliance both provide site-level connectivity, but serve different deployment scenarios.
| Aspect | Cloudflare Mesh | Cloudflare One Appliance |
|---|---|---|
| Protocol | MASQUE | IPsec |
| Deployment model | Software on Linux host (can run alongside other workloads) | Dedicated hardware appliance or virtual machine |
| Best for | Cloud VPCs, development environments, smaller deployments with an available Linux host | Enterprise branch offices, data centers, sites requiring high throughput (1 Gbps+) |
| Platform support | Linux only (x86_64, ARM64). Currently in beta. | Hardware appliance (Dell VEP1460) or virtual (VMware ESXi, Proxmox) |
| High availability | Active-passive replicas for nodes with routes | Supported through multiple connectors per site |
| Management | Configured as a device in the Cloudflare One Client settings | Centralized through the Cloudflare WAN dashboard with zero-touch provisioning |
Use Cloudflare Mesh when you need lightweight, software-only connectivity for cloud workloads or sites where a Linux host is available. Use Cloudflare One Appliance when you need enterprise-grade throughput, high availability, or integration with existing network infrastructure.
Most enterprise Cloudflare One deployments use multiple connectivity options together. This section covers compatibility considerations and common deployment patterns.
Not all Cloudflare One connectivity options work together in the same account. Review the following compatibility information before designing your deployment.
Table 7. Cloudflare One connectivity compatibility
| Combination | Compatible | Notes |
|---|---|---|
| Cloudflare Mesh + Cloudflare WAN | Conditional | Requires Cloudflare One Unified Routing. Accounts on Legacy routing mode cannot use both. |
| Cloudflare One Client + Cloudflare WAN | Yes | Cloudflare One Client users can access Cloudflare WAN-connected sites. Cloudflare WAN sites can also initiate connections to Cloudflare One Client devices using their virtual IP addresses. |
| Cloudflare Tunnel + Cloudflare WAN | Yes | Avoid overlapping IP routes. Cloudflare Tunnel takes priority if the same CIDR is configured for both. |
| GRE + IPsec | Yes | Use for redundancy or migration scenarios. |
| CNI + GRE or IPsec | Yes | Use Internet-based GRE or IPsec tunnels as backup connectivity alongside CNI. |
| Cloudflare One Client + Cloudflare Tunnel + Cloudflare Mesh | Yes | Common pattern for remote access to private applications. All three work together. |
| CNI + Cloudflare Tunnel | Conditional | cloudflared connects to multiple Cloudflare regions for redundancy. If CNI only advertises one region, the tunnel operates with reduced redundancy. Evaluate whether Cloudflare Tunnel is necessary if CNI already provides private connectivity. |
When using multiple Cloudflare One connectivity options, follow these guidelines to avoid routing conflicts:
- Avoid overlapping CIDR ranges: Do not configure the same IP range for multiple tunnel types. If an overlap exists, Cloudflare Tunnel takes priority over Cloudflare WAN routes.
- No automatic failover: Cloudflare does not automatically fail over traffic between different connectivity options. Plan your routing to handle failures within each tunnel type.
- Virtual Networks: Use Virtual Networks to handle overlapping private IP ranges from different environments (for example, multiple cloud VPCs using
10.0.0.0/8).
When layering Cloudflare One tunnels or using multiple encapsulation methods, account for overhead to prevent fragmentation.
Table 8. Effective MTU values for Cloudflare One tunnel types
| Scenario | Effective MTU | MSS clamping |
|---|---|---|
| GRE tunnel | 1,476 bytes | 1,436 bytes or lower |
| IPsec tunnel | 1,400-1,436 bytes (varies by encryption) | 1,360-1,396 bytes |
| Cloudflare One Client behind Cloudflare WAN (double encapsulation) | ~1,300 bytes | Configure based on testing |
| Cloudflare Mesh to Cloudflare One Client | ~1,280 bytes | Configure based on testing. Traffic is encapsulated twice: by Cloudflare Mesh and again by Cloudflare before delivery to the Cloudflare One Client. |
Configure MSS clamping on your edge devices to ensure TCP traffic does not require fragmentation.
Cloudflare One connectivity options handle source IP addresses differently. The following table shows how each Cloudflare One connectivity option handles source IP addresses.
Table 9. Cloudflare One source IP behavior
| Connectivity option | Source IP behavior |
|---|---|
| Cloudflare Tunnel | Origin sees the cloudflared process IP. Use CF-Connecting-IP header for HTTP traffic. |
| Cloudflare Mesh | Preserves original source IP end-to-end. |
| GRE and IPsec tunnels | Preserves original source IP within the tunnel. |
| Cloudflare One Appliance | Preserves original source IP within the tunnel. |
Source IP preservation is required for:
- VoIP and SIP protocols that embed IP addresses in signaling
- Audit logging that requires client IP visibility
- Applications that make authorization decisions based on source IP
The following table shows traffic direction support for each Cloudflare One connectivity option.
Table 10. Cloudflare One connectivity traffic direction support
| Connectivity option | Client-initiated traffic | Server-initiated traffic |
|---|---|---|
| Cloudflare Tunnel | Yes | No |
| Cloudflare One Client | Yes | Yes |
| Cloudflare Mesh | Yes | Yes |
| GRE and IPsec tunnels | Yes | Yes |
| Cloudflare One Appliance | Yes | Yes |
| CNI | Yes | Yes |
If your application requires server-initiated connections (for example, VoIP callbacks, database replication), use a bidirectional connectivity option such as Cloudflare One Client, Cloudflare Mesh, Cloudflare WAN (IPsec/GRE), or CNI. Cloudflare Tunnel does not support server-initiated traffic.
The following patterns illustrate how organizations combine Cloudflare One connectivity options for different scenarios.
This pattern serves organizations with a distributed workforce and multiple physical locations.
Components:
- Cloudflare One Client for remote employees, providing secure access from any location
- IPsec tunnels (via Cloudflare WAN) for branch offices with existing network infrastructure
- Cloudflare Tunnel for specific internal applications that need clientless browser access
Traffic flow:
- Remote employees connect through the Cloudflare One Client, which on-ramps their traffic to Cloudflare.
- Gateway policies inspect and filter traffic based on user identity and device posture.
- Traffic destined for branch office resources routes through IPsec tunnels to Cloudflare WAN-connected sites.
- Traffic destined for specific applications routes through Cloudflare Tunnel to origin servers.
This pattern serves organizations with primarily cloud-based infrastructure and minimal on-premises equipment.
Components:
- Multi-Cloud Networking for cloud VPCs (AWS, GCP, Azure), automating IPsec tunnel creation to Cloudflare WAN
- Cloudflare Tunnel for Kubernetes services and containerized applications
- Cloudflare One Client for employee devices
Traffic flow:
- Multi-Cloud Networking automatically creates IPsec tunnels between cloud VPCs and Cloudflare WAN.
- Cloudflare Tunnel provides ingress for external-facing applications.
- Employees access cloud resources through the Cloudflare One Client.
Alternative: For organizations not using Cloudflare WAN, Cloudflare Mesh can provide bidirectional connectivity for cloud VPCs. Note that accounts on Legacy routing mode cannot use Cloudflare Mesh and Cloudflare WAN together.
This pattern serves organizations with strict compliance requirements that prohibit traffic from traversing the public Internet.
Components:
- Cloudflare Network Interconnect (CNI) for primary connectivity from data centers
- IPsec tunnels as backup connectivity in case of CNI issues
- Cloudflare One Client for remote employees
Traffic flow:
- Data center traffic routes through CNI, never touching the public Internet.
- IPsec tunnels provide backup connectivity if CNI experiences issues.
- Remote employees connect through the Cloudflare One Client over the public Internet (encrypted).
- Gateway policies enforce compliance rules on all traffic regardless of connectivity method.
- SASE reference architecture - Guide to deploying Cloudflare One
- WAN transformation - Plan your migration from legacy WAN to Cloudflare One
- Cloudflare Tunnel
- Cloudflare One Client
- Cloudflare Mesh
- Cloudflare WAN
- WAN Connectors on-ramps - Full list of supported on-ramps
- Multi-Cloud Networking - Automate cloud VPC connectivity
- Magic Transit
- Cloudflare One Appliance
- Cloudflare Network Interconnect
- Virtual Networks
- DNS locations - Filter DNS traffic without device agents
- Proxy endpoints - Filter web traffic using PAC files
- Clientless Web Isolation - Secure web access without device agents
For implementation guidance on combining Cloudflare One connectivity options, refer to the SASE reference architecture.