← Cloudflare Wan / cloudflare-wan / reference

GRE and IPsec tunnels

To route traffic between Cloudflare's global network and your origin network, Cloudflare WAN 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.

Cloudflare WAN uses two encapsulation protocols: Generic Routing Encapsulation (GRE) and 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.

This diagram illustrates the flow of traffic with Cloudflare WAN.

sequenceDiagram
accTitle: Tunnels and encapsulation
accDescr: This diagram shows the flow of traffic with Cloudflare WAN.
participant A as Client machine
participant B as Cloudflare Cloudflare WAN
participant C as Origin router
A->>B: Payload <br> Protocol <br> IP header
Note left of A: Ingress <br> traffic
B->>C: Payload <br> Protocol <br> IP header <br> GRE <br> IP header
C->>A: IP header <br> Protocol <br> Payload
Note right of C: Egress <br> traffic

Traditional tunnels connect two fixed endpoints — one device on each side. Cloudflare WAN uses a different model: anycast 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 <br> network server)
c(Cloudflare global <br> network server)
d(Cloudflare global <br> network server)
e(Cloudflare global <br> network server)
f(Cloudflare global <br> network server)
g(Cloudflare global <br> network server)
h(Cloudflare global <br> network server)
end

subgraph 2
i("Acme router <br> 198.51.100.1")
j("FTP server <br> (203.0.113.100)")
end

subgraph 3
x("Acme router <br> 198.51.100.1")
z("FTP server <br> (203.0.113.100)")
end

a --> 1== Cloudflare anycast GRE <br> single endpoint ==>i --> j

1== Cloudflare anycast IPsec <br> single endpoint ==>x --> z

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. To learn more about the configuration parameters Cloudflare WAN uses to create an IPsec tunnel, keep reading.

Cloudflare WAN 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 ↗. When downgrade protection is enabled, Cloudflare also sends an IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification during this exchange to signal support for full transcript authentication. 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 ↗. 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 ↗ 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.

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 Cloudflare WAN currently supports for IKE SAs and Child SAs.

Choose from the following configuration parameters that Cloudflare WAN supports, based on what your appliance supports.

The following third-party vendors have been tested and validated to interoperate with Cloudflare IPsec for post-quantum key agreement:

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.

Cloudflare WAN supports the following IKE ID types for IPsec:

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.

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.

IKEv2's original authentication design has each endpoint sign only its own outbound messages, not the full handshake transcript. A quantum-capable on-path attacker ↗ can exploit this to create a "split view" of the handshake, tricking the endpoints into downgrading a post-quantum connection back to classical cryptography even when both sides support post-quantum key exchange.

To address this, Cloudflare supports the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH ↗ IKEv2 extension. When enabled, both IKEv2 peers sign the entire handshake transcript during the authentication exchange, rather than only their own messages. This prevents an attacker from downgrading the connection without being detected.

How it works:

• When the feature flag is enabled, Cloudflare (acting as IKE responder) unconditionally includes an IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification in its IKE_SA_INIT response.
• If the initiator also supports the extension, both sides use full transcript authentication, which improves protection again downgrade attacks.
• If the initiator does not support the extension, the handshake proceeds with standard IKEv2 authentication. Both parties must support the extension for downgrade protection to be effective.

Requirements:

• Your IKEv2 initiator must support the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification as defined in draft-ietf-ipsecme-ikev2-downgrade-prevention ↗.

For help resolving tunnel issues:

• Troubleshoot tunnel health - Diagnose and fix health check failures
• Troubleshoot with IPsec logs - Use Logpush to analyze IPsec handshake issues

For help resolving tunnel issues:

• Troubleshoot tunnel health - Diagnose and fix health check failures
• Troubleshoot with IPsec logs - Use Logpush to analyze IPsec handshake issues