--- title: GRE and IPsec tunnels description: Magic Transit uses Generic Routing Encapsulation (GRE) and IPsec tunnels to transmit packets from Cloudflare's global network to your origin network. image: https://developers.cloudflare.com/core-services-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/magic-transit/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) ### Tags [ IPsec ](https://developers.cloudflare.com/search/?tags=IPsec)[ Post-quantum ](https://developers.cloudflare.com/search/?tags=Post-quantum) # GRE and IPsec tunnels ## Tunnels and encapsulation To route traffic between Cloudflare's global network and your origin network, Magic Transit wraps your original packets inside an outer packet — a process called encapsulation. The outer packet carries your traffic across the Internet to its destination, where it is unwrapped (decapsulated) and delivered. Magic Transit uses two encapsulation protocols: [Generic Routing Encapsulation (GRE)](https://www.cloudflare.com/learning/network-layer/what-is-gre-tunneling/) and [IPsec](https://www.cloudflare.com/learning/network-layer/what-is-ipsec/). GRE is stateless and simpler to configure but does not encrypt traffic. IPsec encrypts traffic and authenticates the source, providing stronger security. Both create tunnels — logical point-to-point connections between Cloudflare and your network. Cloudflare sets up tunnel endpoints on global network servers inside your network namespace, and you set up tunnel endpoints on routers at your data center. To accommodate additional header data introduced by encapsulation, you must adjust the maximum segment size (MSS) to comply with the standard Internet routable maximum transmission unit (MTU), which is 1500 bytes. For instructions, refer to [Set maximum segment size](https://developers.cloudflare.com/magic-transit/get-started/#set-maximum-segment-size). This diagram illustrates the flow of traffic with Magic Transit. sequenceDiagram accTitle: Tunnels and encapsulation accDescr: This diagram shows the flow of traffic with Magic Transit. participant A as Client machine participant B as Cloudflare Magic Transit participant C as Origin router A->>B: Payload
Protocol
IP header Note left of A: Ingress
traffic B->>C: Payload
Protocol
IP header
GRE
IP header C->>A: IP header
Protocol
Payload Note right of C: Egress
traffic Note By default, your Internet Service Provider (ISP) interface routes egress packets, not Cloudflare. ## Anycast Traditional tunnels connect two fixed endpoints — one device on each side. Magic Transit uses a different model: [anycast](https://www.cloudflare.com/learning/cdn/glossary/anycast-network/) IP addresses for Cloudflare's tunnel endpoints. In the anycast model, any server in any Cloudflare data center can receive traffic and must be capable of encapsulating and decapsulating packets for any tunnel. This means your tunnel is not tied to a single Cloudflare server — traffic is handled by whichever data center is closest to the source. This works with GRE tunnels because the GRE protocol is stateless. Cloudflare processes each packet independently without requiring any negotiation or coordination between tunnel endpoints. Tunnel endpoints bind to IP addresses but not to specific devices. Any device that can strip off the outer headers and then route the inner packet can handle any GRE packet sent over the tunnel. For IPsec tunnels, the customer's router negotiates the creation of an IPsec tunnel with Cloudflare using the Internet Key Exchange (IKE) protocol. Because IPsec is stateful (it requires shared keys and session parameters), one Cloudflare server handles the initial negotiation, then propagates the tunnel details (traffic selectors, keys, etc.) across all Cloudflare data centers. The result is that any Cloudflare server can handle traffic for that IPsec tunnel, even though only one server negotiated the setup. Cloudflare's anycast architecture provides a conduit to your tunnel for every server in every data center on Cloudflare's global network. The following image shows this architecture. flowchart LR accTitle: Anycast tunnel accDescr: Multiple servers in data center preparing packets to send through anycast tunnel. a(User) subgraph 1 direction LR b(Cloudflare global
network server) c(Cloudflare global
network server) d(Cloudflare global
network server) e(Cloudflare global
network server) f(Cloudflare global
network server) g(Cloudflare global
network server) h(Cloudflare global
network server) end subgraph 2 i("Acme router
198.51.100.1") j("FTP server
(203.0.113.100)") end subgraph 3 x("Acme router
198.51.100.1") z("FTP server
(203.0.113.100)") end a --> 1== Cloudflare anycast GRE
single endpoint ==>i --> j 1== Cloudflare anycast IPsec
single endpoint ==>x --> z ## IPsec tunnels Post-quantum IPsec Post-quantum key agreement for IPsec tunnels with third-party devices is generally available, with confirmed interoperability for [validated third-party platforms](#tested-third-party-vendor-interoperability). Post-quantum IPsec is also generally available when using the [Cloudflare One Appliance](https://developers.cloudflare.com/cloudflare-wan/configuration/appliance/). [IPsec ↗](https://www.cloudflare.com/learning/network-layer/what-is-ipsec/) is a group of protocols that work together to set up encrypted connections between devices. It helps keep data you send over public networks secure. Organizations often use IPsec to set up Virtual Private Networks (VPNs), and it works by encrypting IP packets and authenticating the source where the packets come from. For information on how to set up an IPsec tunnel, refer to [Configure tunnel endpoints](https://developers.cloudflare.com/magic-transit/how-to/configure-tunnel-endpoints/). To learn more about the configuration parameters Magic Transit uses to create an IPsec tunnel, keep reading. ### How IKEv2 establishes an IPsec tunnel Magic Transit uses the following stages to establish an IPsec tunnel: * **Initial Exchange** (`IKE_SA_INIT`): IKE peers negotiate parameters for the IKE Security Association (SA) and establish a shared secret for key derivation, and when relevant, signal support for post-quantum key exchange with [RFC 9370 ↗](https://datatracker.ietf.org/doc/rfc9370/). After this exchange, the peers have a secure communication channel but they have not yet authenticated each other. * **Intermediate Exchange** (`IKE_INTERMEDIATE`): If both peers support RFC 9370, they perform an additional key exchange using ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism), a post-quantum key exchange specified in [draft-ietf-ipsecme-ikev2-mlkem ↗](https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/). This creates a hybrid shared secret by combining a secret derived from classical Diffie-Hellman (established during the `IKE_SA_INIT`) with post-quantum ML-KEM to protect against [harvest-now, decrypt-later ↗](https://en.wikipedia.org/wiki/Harvest%5Fnow,%5Fdecrypt%5Flater) attacks. * **Auth Exchange** (`IKE_AUTH`): Using the keys established from both the `IKE_SA_INIT` and the `IKE_INTERMEDIATE` exchange, IKE peers mutually authenticate each other. After authentication, they establish the IKE security association (SA). Next, the peers negotiate and establish an IPsec tunnel, known as a Child SA. * **Rekeying**: Periodically, or through manual intervention, IKE SAs can be rekeyed to generate new SAs with fresh keys for the session. This rekey operation is performed for both the IKE SA (to refresh the control plane) and the Child SAs (to refresh the data plane). When a hybrid exchange is in use (RFC 9370), the rekey process for the IKE SA will once again perform the parallel classical (DH) and post-quantum (ML-KEM) exchanges to ensure continued quantum resistance. Note The IKE SA and the Child SA are separate entities, each with their own parameters. The Child SA is the dataplane IPsec tunnel where user traffic flows (that is, the ESP layer of IPsec). The IKE SA sets up and manages the Child SA. In summary, IKEv2 creates an IKE SA that uses certain cryptographic transforms. It then uses that IKE SA to create a Child SA which itself uses certain cryptographic transforms. The following configuration section details which of these transforms Magic Transit currently supports for IKE SAs and Child SAs. Note IKE is one of the protocols that makes up IPsec. Cloudflare only operates as an IKE responder. ### Supported configuration parameters Choose from the following configuration parameters that Magic Transit supports, based on what your appliance supports. IKE SA (also known as Phase 1) Documentation sometimes refers to IKE SA as Phase 1 as per IKEv1 language. * **Encryption** * AES-GCM-16 with 128-bit or 256-bit key length * AES-CBC with 256-bit key length * **Integrity** (sometimes referred to as Authentication) * SHA2-256 * **Key Exchange Method** (formerly Diffie-Hellman group): Cloudflare supports the following key exchange methods for the IKE SA. Note that [RFC 9370 ↗](https://datatracker.ietf.org/doc/rfc9370/) renames "DH Group" to "Key Exchange Method" to accommodate non-DH algorithms. * **Post-quantum hybrid (recommended)**: ML-KEM-768 as an additional Key Exchange to DH Group 20 (per RFC 9370 and [draft-ietf-ipsecme-ikev2-mlkem ↗](https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/)) * Post-quantum hybrid: ML-KEM-1024 as an additional Key Exchange to DH Group 20 (per RFC 9370 and [draft-ietf-ipsecme-ikev2-mlkem ↗](https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/)) * Classical DH group 20 (384-bit random ECP group) * Classical DH group 14 (2048-bit MODP group) * Classical DH group 5 (1536-bit MODP group) Warning Cloudflare recommends the **ML-KEM-768 + DH Group 20** hybrid exchange for post-quantum key agreement. If your appliance does not yet support RFC 9370 and draft-ietf-ipsecme-ikev2-mlkem, use DH group 20. * **Pseudorandom function (PRF)** Do not confuse this with Perfect Forward Secrecy (PFS). You often cannot configure PRF. * SHA2-256 * SHA2-384 * SHA2-512 Child SA (also known as Phase 2 or IPsec SA) The Child SA. Documentation sometimes refers to this as Phase 2 as per IKEv1 language. * **Encryption**: * AES-GCM-16 with 128-bit or 256-bit key length * AES-CBC with 128-bit or 256-bit key length * **Integrity** (sometimes referred to as Authentication.) * SHA2-256 * SHA-1 Note When using AES-GCM-16, you do not need an integrity algorithm because AES GCM includes integrity checking (since it is an Authenticated Encryption with Associated Data (AEAD) algorithm). Even when using an AEAD algorithm, however, some routers still require you to select an integrity algorithm. * **Perfect Forward Secrecy (PFS) group** Documentation sometimes refers to this as Phase 2 Diffie-Hellman Group. Do not confuse this with PRF. Cloudflare supports the following Diffie-Hellman (DH) groups. * DH group 20 (384-bit random ECP group) * DH group 14 (2048-bit MODP group) * DH group 5 (1536-bit MODP group) Post-quantum security If the Child SA uses DH groups for Perfect Forward Secrecy, it is still protected against quantum threats if the parent IKE SA was established using a hybrid ML-KEM exchange. Warning Cloudflare recommends that you use only one DH group when configuring your device, specifically **DH group 20**. Note Cloudflare recommends configuring the Child SA rekey interval (SA lifetime) between 30 minutes and 8 hours. Required configuration parameters * The IKE version must be IKEv2. * The IKE authentication method must be Pre-Shared Key (PSK). * If your router is behind Network Address Translation (NAT) and requires NAT traversal (NAT-T), then your router must initiate IKE communication on port `4500`. Most devices support configuring NAT-T to begin on port `4500` (exceptions include at least some versions of the Cisco ASA). Cloudflare does not support NAT-T for IKE sessions which begin on port `500` and then switch to port `4500`. * (Uncommon) You must disable Extended Sequence Numbers (ESN). * If your tunnels need replay protection, enable Dead Peer Detection (DPD) in your router and select the option that restarts your IKE session when a DPD timeout occurs. This "restart" option ensures that the connection can recover in the event that a Cloudflare server goes offline. If your router does not offer this setting, check the router documentation for its dead peer detection behavior. * **Multiple Key Exchange ([RFC 9370 ↗](https://datatracker.ietf.org/doc/rfc9370/))**: To use post-quantum security, your router must support the `IKE_INTERMEDIATE` and `IKE_FOLLOWUP_KE` exchange as defined in RFC 9370 and [draft-ietf-ipsecme-ikev2-mlkem ↗](https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/). Because post-quantum public keys and ciphertexts (like ML-KEM-768) are larger than classical keys, you must enable IKEv2 fragmentation on your router to prevent packets from exceeding the 1,500-byte MTU. When configuring the first Additional Key Exchange, use the IANA-assigned Transform ID `36` for ML-KEM-768, or Transform ID `37` for ML-KEM-1024. Optional configuration parameters * Disable [anti-replay protection](https://developers.cloudflare.com/magic-transit/reference/anti-replay-protection/). * **`NULL` encryption for IPsec (not recommended):** Do not use this option unless necessary because it reduces security by leaving IPsec traffic unencrypted. You must explicitly opt in to use this option. Using this option also eliminates post-quantum protections. ### Tested third-party vendor interoperability The following third-party vendors have been tested and validated to interoperate with Cloudflare IPsec for post-quantum key agreement: | Vendor | Product / Version | ML-KEM variant | DH group | Notes | | -------- | ----------------------------------------------------------- | -------------- | -------- | ------------------------------------------------------------- | | Cisco | Cisco 8000 Series Secure Routers with IOS XR Release 26.1.1 | ML-KEM-1024 | Group 20 | Requires RFC 9370 and draft-ietf-ipsecme-ikev2-mlkem support. | | Fortinet | FortiOS 7.6.6+ | ML-KEM-768 | Group 20 | Requires RFC 9370 and draft-ietf-ipsecme-ikev2-mlkem support. | | Fortinet | FortiOS 7.6.6+ | ML-KEM-1024 | Group 20 | Requires RFC 9370 and draft-ietf-ipsecme-ikev2-mlkem support. | Cloudflare continues to test and validate additional third-party devices. If you have successfully configured post-quantum IPsec with a vendor not listed here, contact your account team. ### Supported IKE ID formats Magic Transit supports the following IKE ID types for IPsec: Request for Comments (RFC) name `ID_RFC822_ADDR` * **Format**: `ipsec@..ipsec.cloudflare.com` * **Example**: `ipsec@f5407d8db1a542b196c59f6d04ba8bd1.123456789.ipsec.cloudflare.com` RFC name `ID_FQDN` * **Format**: `..ipsec.cloudflare.com` * **Example**: `f5407d8db1a542b196c59f6d04ba8bd1.123456789.ipsec.cloudflare.com` RFC name `ID_KEY_ID` * **Format**: `_` * **Example**: `123456789_f5407d8db1a542b196c59f6d04ba8bd1` Additionally, Cloudflare supports the IKE ID type of `ID_IPV4_ADDR` if the following two conditions are met: 1. You set the IPsec tunnel's `customer_endpoint` value. 2. The combination of `cloudflare_endpoint` and `customer_endpoint` is unique among the customer's IPsec tunnels. Warning Make sure each IPsec tunnel has a unique combination of a [Cloudflare endpoint and customer endpoint](https://developers.cloudflare.com/magic-transit/how-to/configure-tunnel-endpoints/). If this combination is not unique among your IPsec tunnels, you should use one of the custom IKE formats (`ID_RFC822_ADDR`, `ID_FQDN`, or `ID_KEY_ID`) to specify the tunnel ID and account ID. This helps Cloudflare link the IKE packet to the right IPsec tunnel for tasks like authentication. ### Route-based vs. policy-based VPNs Although Cloudflare supports both route-based and policy-based VPNs, we recommend route-based VPNs. If route-based VPNs are not an option and you must use policy-based VPNs, be aware of the following limitations: * Cloudflare only supports a single set of traffic selectors per Child SA. * A policy must cover reply-style health checks — that is, they must match traffic selectors — otherwise, Cloudflare drops them, just like any other traffic from an IPsec tunnel that does not match a policy. * A single IPsec tunnel can only contain around 100 Child SAs. Therefore, there is effectively a limit on the number of different policies per tunnel. ### Troubleshooting For help resolving tunnel issues: * [Troubleshoot tunnel health](https://developers.cloudflare.com/cloudflare-wan/configuration/common-settings/check-tunnel-health-dashboard/) \- Diagnose and fix health check failures * [Troubleshoot with IPsec logs](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/account/ipsec%5Flogs/) \- Use Logpush to analyze IPsec handshake issues ## Network Analytics Cloudflare's Network Analytics provides near real-time visibility into network and transport layer traffic patterns and Distributed Denial of Service (DDoS) attacks to help troubleshoot IP traffic issues. You can also use Network Analytics to view information about the traffic that leaves Cloudflare's global network by reviewing ingress and egress tunnel traffic over a specific amount of time. For more information, refer to [Analytics](https://developers.cloudflare.com/magic-transit/analytics/). ## Troubleshooting For help resolving tunnel issues: * [Troubleshoot tunnel health](https://developers.cloudflare.com/magic-transit/troubleshooting/tunnel-health/) \- Diagnose and fix health check failures * [Troubleshoot with IPsec logs](https://developers.cloudflare.com/magic-transit/troubleshooting/ipsec-troubleshoot/) \- Use Logpush to analyze IPsec handshake issues ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/magic-transit/","name":"Magic Transit"}},{"@type":"ListItem","position":3,"item":{"@id":"/magic-transit/reference/","name":"Reference"}},{"@type":"ListItem","position":4,"item":{"@id":"/magic-transit/reference/gre-ipsec-tunnels/","name":"GRE and IPsec tunnels"}}]} ```