Anti-replay protection

If you use Magic Transit and anycast IPsec tunnels, we recommend disabling anti-replay protection. Cloudflare disables this setting by default. However, you can enable it through the API or the Cloudflare dashboard for devices that do not support disabling it, including Cisco Meraki, Velocloud, and AWS VPN Gateway.

Refer to Add tunnels to learn how to set up replay protection. This page explains replay attacks, why Cloudflare recommends disabling IPsec anti-replay, and related considerations.

Replay attacks

Replay attacks occur when a malicious actor intercepts and records a packet ↗, and later sends the recorded packet to the target network again with an intent that benefits the attacker.

Example

Consider a poorly designed Internet of Things (IoT) garage door opener. The device has a simple protocol for operation: A User Datagram Protocol (UDP) packet contains the garage door password and either open or shut in its data segment. The garage door's key encrypts the data segment, and the owner's phone sends it to either open or close the garage door.

An attacker likely cannot open or close the garage door by guessing the encryption key and password. While the attacker cannot see the recorded packet's encrypted content, if the garage is in their line-of-sight, they could potentially correlate and guess which packets are responsible for opening the garage door. When the attacker wants to open the door, they send the recorded open packet, and because the recorded packet would contain the password and already be encrypted with the right key, this door would open.

To prevent this replay attack, a user could add a packet number to each command sent to the garage door. The first could be packet 1, the second packet 2 and so on, and the garage door would only accept packets containing the next number in the sequence each time. For example, after the garage door receives packet 1, it would only accept packet 2, and if an attacker tries to replay packet 1, the garage door ignores the request.

IPsec anti-replay protection

IPsec anti-replay protection works similarly to the prevention example in the scenario above. The sender assigns each IPsec packet a sequence number. The receiver tracks which sequence numbers it has already seen and only accepts packets in a small window around the highest value the receiver has seen, and the window is typically 64-1024 packets. IPsec uses a window instead of strict sequencing because sometimes packets are reordered or lost on the Internet - having a range of acceptable packet sequence numbers helps absorb these issues.

Magic Transit and anti-replay protection

Cloudflare's global anycast network consists of thousands of servers in hundreds of data centers around the world. Similar to Cloudflare's anycast GRE tunnel implementation, Cloudflare's IPsec implementation is also anycast, which enables users to enjoy all the benefits of Cloudflare's anycast network architecture. These benefits include unparalleled performance and low latency, greatly simplified configuration and management, and native network resiliency with automatic failover. By default, any packet for Magic Transit can go through any one of these servers where Cloudflare encrypts and encapsulates it with IPsec and sends it to your router.

Engineers did not design IPsec anti-replay protection for such a distributed scenario - they designed the protection scheme for a single sender and single receiver. For a single sender, keeping track of the sequence number is trivial, and the sender stores the sequence number in memory and increments it for every packet sent. If you enable replay protection for Magic Transit IPsec tunnels, Cloudflare routes packets for a single tunnel to one server that keeps track of the sequence number. This means the replay protection mechanism will work correctly, but you lose the benefits of automatically distributing traffic across Cloudflare's global servers. It also only works in one direction (Cloudflare to customer network) - Cloudflare will not route packets from the customer network to Cloudflare to a single server, and will not apply replay protection.

Additional considerations

IPsec anti-replay protection is extremely important for transport mode - host-to-host or even app-to-app IPsec. In transport mode, an attacker has a relatively easy time identifying the encrypted protocol and identifying which packets to replay if the protocol is even subject to replay attacks. Magic Transit, however, uses tunnel mode, which is inherently much harder to successfully manage a replay attack.

There are several reasons that make replay attacks difficult with tunnel mode:

• IPsec encrypts the entire inner packet, which means the attacker would know almost nothing about the user packet they capture and perform correlation for replay attack. The only information an attacker would know is the outer site network that encrypted the packet, the outer site network that receives it, and the approximate size of the packet. However, this information is not enough to identify specific inner user packet flows to correlate and replay.
• Replay attacks only work when attackers use the same encryption keys. After rekeying, the router drops old replayed packets.
• Most protocols are not susceptible to replay at the packet level. The Internet can duplicate packets, which means TCP and many protocols built on UDP already include sequence numbers or similar to handle duplicate packets coming off the wire. For those, the replay traffic just looks like a duplicate packet and is handled by the end host correctly.
• Anti-replay protection is available in a higher Open Systems Interconnection (OSI) layer. Many modern day applications use secure communication protocols such as Secure Sockets Layer/Transport Layer Security (SSL/TLS), Secure Shell (SSH), or SSH File Transfer Protocol (SFTP) to transport application data. These secure communication protocols (at a higher OSI layer than network layer) natively support anti-replay protection.
• The reduced attack surface lowers the probability for packet interception. IPsec tunnels are site-to-site VPN tunnels between a user's site router and Cloudflare's global network, through dedicated Internet Service Provider (ISP) network connections, which are typically very secure. Additionally, the anycast nature of Cloudflare's IPsec implementation terminates the IPsec tunnel to one of the more than 300 Cloudflare data centers closest to the customer's edge router, which minimizes the physical distance and footprint the encrypted packets have to traverse.