Why Encryption Alone Does Not Stop a Replayed Packet

Protected packets do not expire cryptographically, so one that was valid five minutes ago is still valid now, because encryption and integrity protection say nothing about when the bytes were produced. An attacker who can capture and resend traffic does not need to break the cipher. This is why every serious tunnel protocol carries sequence state alongside its keys.

The mechanism is small, and its failure modes are easy to confuse with packet loss.

Valid Ciphertext Is Not Fresh Ciphertext

Authentication answers one question: did these bytes come from a holder of the key, unmodified. It does not answer whether this is the first time the receiver has seen them. A replayed packet satisfies the first test perfectly, which is exactly why integrity checking alone cannot stop a replay and why the protocol needs a second rule about acceptance. A receiver that only authenticates has no defence against an attacker holding a recording.

That rule is cheap to implement and cheap to state: accept a given protected packet once, under a given key. Everything else in this area follows from how the implementation tracks that once.

Reading a replay drop as a decryption failure sends you looking at the wrong subsystem entirely.

A Sequence Number and a Window

IPsec ESP carries a sequence number and the receiver keeps a sliding window of recently accepted values, with the ESP specification describing the default window size and the option to extend it. WireGuard takes a different route with a counter per key and an explicit check against it. Neither design assumes packets arrive in order, because real networks reorder them. Both tolerate reordering, and neither tolerates repetition.

The window is what makes that tolerance possible. A packet slightly behind the highest value seen can still be accepted if it has not been accepted before; one far behind, or one whose slot is already marked, is dropped. Increase the window and you tolerate more reordering at the cost of more state per association.

Diagnostic counters show you which case you are in. Replay drops increment a specific counter rather than a generic error, and reading that counter is the first useful observation.

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

State Belongs to the Key, Not the Host

Counter state is tied to a security association or a key epoch, so a rekey creates a fresh context and its own sequence space. Clearing a counter without replacing the key, or reusing an association after a manual reset, breaks the assumption the receiver's window depends on. That is why protocol-driven rekeying exists rather than an operator-visible reset button.

When a tunnel misbehaves after a manual intervention, ask whether the intervention touched sequence state. A configuration that looks identical can behave differently because the state it inherited is not the state it expects.

Diagnose the Cause Before Disabling Anything

Loss, reordering, duplicated traffic and an implementation defect all surface as retransmissions, and only one of them is a replay problem. Disabling the check to silence noise removes the property you were relying on and makes the original cause harder to find, because now the retransmissions have no explanation at all.

Capture scoped evidence: association identifiers, sequence numbers and counters, with payloads excluded. That is enough to tell a duplicate from a reordered arrival, and it does not turn your diagnostic file into a copy of the user's traffic.

What the Check Does Not Promise

Replay protection is a property of packet processing inside one protocol. It does not mean the operator keeps no logs, that a website cannot recognise an account, or that a session is anonymous. Those are separate questions about separate systems, and a strong anti-replay design answers none of them.

Maintained software with supported settings is the practical control available to a user. The protocol handles the packet; everything else remains an operational decision.