Magic Transit

L3/L4 DDoS protection and network performance for your entire IP address space, delivered at Cloudflare's global edge.

Developer Docs → Learn More

What is Magic Transit?

Magic Transit is Cloudflare's Layer 3/4 DDoS protection and performance product that allows Enterprise customers to route their entire IP address space (prefix) through Cloudflare's global network.

Unlike Cloudflare's traditional proxy services — which terminate HTTP, TCP, and UDP sessions — Magic Transit operates at the IP layer: Cloudflare's servers apply a suite of network functions (DDoS mitigation, firewalling, routing) on a packet-by-packet basis without terminating Layer 4 or Layer 7 sessions.

The result is that all of your eyeball traffic routes through a Cloudflare PoP before reaching your infrastructure, giving you always-on DDoS protection, edge-based firewalling, and performance benefits — for any IP-based service.

Key Facts

  • Enterprise-only product
  • Requires customer-owned /24 or larger IP prefix
  • Connects via GRE tunnel, IPsec tunnel, or Cloudflare Network Interconnect (CNI)
  • Protects against L3/L4 DDoS attacks
  • Mitigation time: up to 3 seconds for automated systems
  • Available as Always-on or On-demand

How Magic Transit Works

1

IP Advertisement

Cloudflare advertises your IP prefixes (your own /24 or larger, or leased space) globally from every Cloudflare PoP using BGP. This causes all Internet traffic destined for your IP space to enter Cloudflare's network first.

2

Traffic Enters Cloudflare Edge

Inbound packets arrive at the nearest Cloudflare PoP via Anycast routing. Cloudflare's automated DDoS mitigation systems (including gatebot and dosd) inspect and filter traffic at line rate, dropping malicious packets before they reach your network.

3

Firewall Rules Applied

Magic Firewall (Cloudflare Network Firewall) applies customer-defined L3/L4 firewall rules at the edge, blocking unwanted traffic before it is forwarded to your infrastructure.

4

Clean Traffic Forwarded

Scrubbed traffic is encapsulated in GRE or IPsec and forwarded to your network through the configured tunnels. Your infrastructure receives only clean, legitimate traffic.

Traffic flow: Internet → Cloudflare Edge (Anycast) → DDoS Mitigation → Magic Firewall Rules → GRE/IPsec Tunnel → Customer Infrastructure

Anycast GRE: What Makes It Unique

GRE is a stateless protocol — each packet is processed independently, with no negotiation required between tunnel endpoints. Cloudflare's implementation uses Anycast GRE: a single tunnel configuration gives you a conduit to every server in every data center on Cloudflare's global edge. Traffic is automatically routed to the closest PoP, providing built-in geographic distribution and failover.

Connection Methods

Magic Transit supports three ways to connect your infrastructure to Cloudflare:

GRE Tunnels

The most common connection method. GRE tunnels run over the public Internet, using your publicly routable IP as the remote endpoint and Cloudflare's Anycast IPs on the other side.

  • Works over any Internet connection
  • Supports multiple tunnels for redundancy and load balancing
  • 24 bytes of overhead (4-byte GRE header + 20-byte outer IP header)
  • Recommended MSS clamping: ≤ 1436 bytes
Configure GRE tunnels →

IPsec Tunnels

IPsec provides encrypted tunnel connectivity between your infrastructure and Cloudflare, suitable when encryption is required at the network layer.

  • Encrypted traffic between endpoints
  • Higher overhead than GRE (1400–1440 bytes MTU)
  • Supports IKEv2 for key exchange
About IPsec tunnels →

Cloudflare Network Interconnect (CNI)

CNI is a private, physical or virtual connection directly into Cloudflare's network — bypassing the public Internet for the tunnel connection entirely.

  • Lower latency and jitter
  • Eliminates GRE tunnel endpoint exposure on the public Internet
  • Available as PNI (Private Network Interconnect) or vPartner connections
  • Ideal for customers concerned about tunnel endpoint attack surface
About Network Interconnect →

Use Cases

🛡️

L3/L4 DDoS Mitigation

Protect your entire IP address space from volumetric and protocol-based DDoS attacks. Cloudflare's automated systems mitigate attacks in under 3 seconds, handling everything from SYN floods to UDP amplification attacks without requiring manual intervention.

🔥

Edge Firewalling

Apply Layer 3/4 firewall rules at Cloudflare's edge for your entire network. Block unwanted protocols, source IPs, or port ranges before traffic ever reaches your infrastructure. Rules are evaluated after automated DDoS mitigations.

⚡

Traffic Routing & Load Balancing

Route traffic across multiple GRE tunnels using static route priorities. Configure Equal-Cost Multi-Path (ECMP) to load-balance traffic across multiple tunnel endpoints, or set priority-based failover for high availability.

🌐

Multi-Datacenter Connectivity

Simplify load balancing between multiple datacenters and get automatic failover. Magic Transit's health checks continuously monitor tunnel state and automatically reroute traffic when a tunnel degrades or goes down.

🔄

Always-On vs On-Demand

Deploy Magic Transit in Always-on mode for continuous protection, or On-demand mode to enable/disable advertisement of your IP prefixes via the Cloudflare dashboard or API — activating protection only when needed.

📦

Orange-Cloud Compatible

Magic Transit works seamlessly alongside Cloudflare's L7 proxy (orange-cloud) products. Customers using both Magic Transit and Cloudflare CDN/WAF get comprehensive protection at every layer.

Magic Transit vs Magic WAN

Two distinct Cloudflare networking products, each serving different connectivity needs:

Magic Transit Magic WAN
Primary Purpose DDoS protection and connectivity for Internet-facing networks SD-WAN replacement — connecting branch offices and private networks
Traffic Direction Inbound Internet traffic to your IP space East-West traffic between sites and Cloudflare's network
IP Requirements Customer must own/lease a /24 or larger prefix Uses RFC 1918 private address space
BGP Prefix Advertisement Yes — Cloudflare advertises your prefixes globally No public advertisement
Anycast IP Specific Cloudflare Anycast IPs for your tunnels Different Anycast IPs used for WAN connectivity
Use Case Target Enterprises protecting internet-facing IP addresses Enterprises replacing MPLS / SD-WAN infrastructure

DDoS Protection Systems

Magic Transit leverages multiple automated DDoS protection layers, each designed to catch different attack types:

gatebot

Cloudflare's centralized DDoS mitigation system. gatebot samples 1 in 8,192 packets, sending them to a centralized collector for analysis. It handles large-scale, recognizable attack patterns that can be identified from sampled data.

→

dosd

A local, per-colo DDoS mitigation daemon that samples 1 in every 100 packets. dosd can detect and mitigate attacks without centralized coordination, making it faster and effective against attacks that affect a specific location.

→

flowtrackd (Advanced TCP Protection)

A stateful TCP DDoS protection system that tracks TCP connection flows. Designed for sophisticated TCP-based attacks — ACK floods, SYN-ACK floods, and other TCP state exhaustion attacks. Thresholds can be customized per customer.

→

Magic Firewall

Customer-defined L3/L4 firewall rules evaluated at the edge after automated DDoS systems. Allows blocking specific IPs, ports, protocols, or combinations. Configured via the Cloudflare dashboard or API.

Note: Magic Transit protects against L3/L4 attacks. For L7 (HTTP/HTTPS) DDoS protection, pair Magic Transit with Cloudflare's L7 products (CDN/WAF).

Routing and Failover

Static Routes and Priorities

Magic Transit uses static routes to determine which GRE tunnel forwards traffic for a given prefix. Each static route has a priority value. Lower priority values are preferred.

  • Equal-Cost Multi-Path (ECMP): If multiple routes exist for the same prefix at the same priority, traffic is load-balanced across all tunnels equally.
  • Priority-based failover: If routes have different priorities, the lowest-priority (most preferred) route is used. Traffic fails over to higher-priority routes automatically when the primary tunnel degrades.

Tunnel Health Checks

Cloudflare continuously monitors the health of every GRE tunnel using health check probes. There are two types:

Tunnel Health Checks

Run from inside the customer network namespace on each Cloudflare metal, for every configured tunnel. Sends ICMP probes through the tunnel and expects replies, verifying bidirectional GRE connectivity.

Endpoint Health Checks

Run from the default namespace and probe an actual endpoint inside the customer's infrastructure. Tests end-to-end reachability, not just tunnel connectivity. Helps confirm traffic reaches its intended destination.

Tunnel State and Failover Timing

When health checks start failing, Cloudflare applies a route metric penalty to deprioritize the affected tunnel, shifting traffic to other available tunnels:

  • Failover begins in as few as 10 seconds after health check failures start
  • Globally consistent failover completes within 10–90 seconds
  • Tunnels cycle through Degraded state before returning to Healthy (minimum 5-minute hold)
Tunnel health check documentation →

MTU, MSS, and Packet Sizing

Because GRE adds 24 bytes of overhead to every packet, customers must account for the reduced effective MTU in their network configuration.

The Problem

Standard Ethernet MTU is 1,500 bytes. GRE adds 24 bytes (4-byte GRE header + 20-byte outer IP header), pushing a 1,500-byte packet to 1,524 bytes — which exceeds Ethernet MTU and would normally require fragmentation.

If the Don't Fragment (DF) bit is set on a packet that exceeds the tunnel MTU, the packet will be dropped.

The Solution: MSS Clamping

MSS (Maximum Segment Size) clamping artificially lowers the TCP payload size negotiated during the handshake, ensuring packets never exceed the tunnel's effective MTU.

Magic Transit customers must configure MSS clamping on their egress WAN interface (not the GRE tunnel interface) to a maximum of 1,436 bytes.

  • GRE interface MTU: 1,476 bytes
  • Max MSS: 1,476 − 40 (IP + TCP headers) = 1,436 bytes
MTU and MSS documentation →

Getting Started

Prerequisites

Before onboarding to Magic Transit, you will need:

IP Prefix Ownership

You must own or lease a /24 or larger IP prefix. Magic Transit is not available for smaller prefixes because /24 is the most specific subnet that can be announced via BGP on the public Internet.

Verify ownership: bgp.he.net | bgpview.io

Letter of Agency (LOA)

A signed LOA authorizing Cloudflare to announce your IP prefixes is required. Cloudflare will send this to transit providers on your behalf.

ASN (Recommended)

Having your own ASN is recommended. If you don't have one, you can use the BYOIP ASN (AS209242) provided by Cloudflare.

RPKI / ROA Records

If you sign your route advertisements using RPKI, ensure your Route Origin Authorization (ROA) record matches your origin ASN before onboarding. Update or add ROA records if needed.

Learn about RPKI →

GRE Tunnel Endpoints

You will need at least one publicly routable IP address on your side for the GRE tunnel endpoint. For redundancy, Cloudflare recommends at least two tunnel endpoints.

MSS Clamping

Configure MSS clamping to ≤ 1,436 bytes on your egress WAN interface before go-live. This is mandatory and will be verified during onboarding.

Onboarding Steps

  1. Engage your Cloudflare team — Magic Transit onboarding is managed by Cloudflare Solutions Engineers. Contact your account team to begin.
  2. Submit your prefix and ASN information — Provide your IP prefix(es), ASN, and a signed LOA.
  3. Prefix validation — Cloudflare validates your prefix via IRR and RPKI records.
  4. Configure tunnels — Set up GRE tunnels in the Cloudflare dashboard (Magic Transit → Configuration → Tunnels) and configure the matching tunnel on your CPE/router.
  5. Configure static routes — Add static routes for your prefix pointing to your GRE tunnels.
  6. Verify health checks — Confirm tunnel and endpoint health checks are passing.
  7. Verify MSS clamping — Cloudflare will verify your MSS is correctly configured before go-live.
  8. Go live — Cloudflare begins advertising your prefixes globally. Monitor traffic via Network Analytics in your dashboard.
Full Onboarding Guide →

Analytics and Visibility

Magic Transit customers have access to Network Analytics in the Cloudflare dashboard, providing visibility into:

Traffic Volume

Inbound and outbound packet and byte rates, broken down by tunnel, prefix, protocol, and more.

Attack Events

DDoS attack detections with Attack ID, affected destination IPs, attack type, and mitigation status.

Traffic Distribution

Geographic breakdown by country and ASN showing where your inbound traffic originates.

Protocol Breakdown

Traffic split by protocol (TCP, UDP, ICMP) and TCP flags, useful for identifying anomalous traffic patterns.

Firewall Rule Hits

Packets matched and dropped by Magic Firewall rules, for auditing rule effectiveness.

Tunnel Health

Real-time and historical health check status for every configured tunnel, visible in the dashboard.

GraphQL Analytics API

All Network Analytics data is available via Cloudflare's GraphQL Analytics API. Relevant datasets:

  • ipFlows1mGroups — 1-minute granularity flow data
  • ipFlows1hGroups — 1-hour granularity flow data
  • ipFlows1dGroups — 1-day granularity flow data
  • ipFlows1mAttacksGroups — Attack-specific flow data at 1-minute granularity
GraphQL Analytics API documentation →

Dynamic Advertisement (On-Demand)

Magic Transit customers using the On-demand deployment can toggle the advertisement of their IP prefixes at any time — activating or deactivating protection without making routing changes on their own infrastructure.

How to Toggle Advertisement

Dashboard

Enable or disable prefix advertisement directly from the Cloudflare dashboard under Magic Transit settings.

Dashboard guide →

API

Use the IP Address Management API to programmatically control prefix advertisement status.

API reference →

Terraform

Manage prefix advertisement as infrastructure-as-code using the Cloudflare Terraform provider.

Terraform resource →

Frequently Asked Questions

How quickly does Magic Transit mitigate a DDoS attack?

Cloudflare's automated DDoS systems mitigate attacks in up to 3 seconds. Static Magic Firewall rules take effect in 0 seconds (they are always active). Note that static rules are distinct from automated DDoS mitigations.

What types of attacks does Magic Transit protect against?

Magic Transit protects against Layer 3 and Layer 4 DDoS attacks, including volumetric floods (UDP, ICMP), SYN floods, ACK floods, DNS amplification, and other protocol-based attacks. It does not protect against Layer 7 (HTTP/HTTPS) attacks — for L7 protection, pair Magic Transit with Cloudflare's WAF and CDN products.

Do I need my own IP address space?

Yes. Customers must own or lease a /24 or larger IP prefix. This is a fundamental BGP requirement — /24 is the most specific subnet that can be announced on the public Internet. Cloudflare can also lease smaller portions of an already-advertised prefix range in some cases.

Do I need my own ASN?

An ASN is recommended but not strictly required. If you don't have your own ASN, you can use Cloudflare's BYOIP ASN (AS209242). You can check your ASN and its associated prefixes at bgp.he.net.

What is RPKI and do I need it?

RPKI (Resource Public Key Infrastructure) allows IP address holders to cryptographically authorize which Autonomous Systems can originate their prefixes via Route Origin Authorizations (ROAs). If you already sign your routes with RPKI, Cloudflare will check that your ROA matches your origin ASN during onboarding. If your ROA doesn't match, you'll need to update it. If you don't use RPKI, no action is needed. Learn more about RPKI.

How does GRE tunnel failover work?

Cloudflare runs health checks on every configured tunnel. When a tunnel starts failing health checks, Cloudflare adds a large metric penalty to the routes using that tunnel, causing traffic to fail over to the next available tunnel. Failover can begin as quickly as 10 seconds after failures start and completes globally within 10–90 seconds.

Why does MSS clamping matter?

GRE tunnels add 24 bytes of overhead per packet. Without MSS clamping, large packets (especially TCP segments) may exceed the tunnel MTU and be dropped if the Don't Fragment bit is set. Setting MSS to ≤ 1,436 bytes on your egress WAN interface ensures the negotiated TCP payload size never creates packets too large for the GRE tunnel. This must be applied on the physical egress interface, not the GRE tunnel interface itself.

How does Magic Transit handle traffic that is also orange-clouded (proxied)?

Magic Transit and Cloudflare's L7 proxy (orange-cloud/CDN) work together seamlessly. Traffic for proxied hostnames routes through Magic Transit at L3/L4 and also through the L7 proxy stack, giving you both network-layer DDoS protection and application-layer protection simultaneously.

Can I run DDoS simulations to test Magic Transit?

Yes — DDoS simulations are permitted against your own IP ranges at any time. You should notify Cloudflare support in advance with details including date/time window, duration, target, and expected volume (bps/pps). See the simulated DDoS attack policy for the full process.

What routing databases and route authorization concepts do I need to understand?

Several routing authorization systems are relevant to Magic Transit onboarding:

  • IRR (Internet Routing Registry) — A globally distributed database where network operators publish routing policies and announcements. Cloudflare validates your prefix against IRR records during onboarding. Check your prefixes at IRR Explorer.
  • RPKI (Resource Public Key Infrastructure) — Cryptographic validation of route origins using ROA certificates issued by RIRs.
  • ROA (Route Origin Authorization) — A cryptographically signed record specifying which AS is authorized to originate a given prefix.
  • RIR (Regional Internet Registry) — The five RIRs (AFRINIC, APNIC, ARIN, LACNIC, RIPE) manage IP address allocation and provide the infrastructure for creating ROA records.
What are the OWASP vulnerability protections?

Magic Transit does not provide OWASP/application vulnerability mitigations — those operate at Layer 7 and require Cloudflare's WAF product. Magic Transit focuses on L3/L4 network protection.

Is queuing or class of service (QoS) supported?

QoS and traffic shaping are not currently supported in Magic Transit.

Can Cloudflare automatically activate protection when an attack is detected?

In Always-on mode, protection is always active. In On-demand mode, advertisement can be toggled manually via dashboard or API. Flow-based automatic activation is not currently available for on-demand mode.

Resources & Documentation

Official Developer Documentation

Cloudflare Blog Posts

BGP & Routing Tools

API & Terraform

DDoS Protection Reference