← Magic Transit / magic-transit

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 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.

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 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.

Standard IPsec anti-replay protection assumes a single sender and a single receiver. The sender stores a sequence number in memory and increments it for every packet. The receiver tracks which sequence numbers it has already processed.

Cloudflare's anycast architecture does not fit this model. Because Magic Transit uses anycast, any packet can be processed by any of thousands of servers across hundreds of data centers. This distributed processing is what gives Magic Transit its performance and resiliency benefits — but it means no single server has a complete view of the sequence number state.

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. The replay protection mechanism works correctly in this mode, but you lose the benefit of distributing traffic across Cloudflare's global servers. It also only applies in one direction (Cloudflare to customer network) — Cloudflare does not route packets from the customer network to a single server and does not apply replay protection in that direction.

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.

If you're experiencing tunnel instability or packet drops related to anti-replay protection, refer to Troubleshoot tunnel health.