Feature Request: Replay attack prevention incremental counter

hi all, I was wondering if a modification could be on the table to better prevent unnecessary packet drops.

I'll describe the issue first, which i'm sure probably a good 95% of openvpn users have experienced at one time or another. The dreaded replay attack prevention messages and subsequent dropped packets.

The issue stems from a combination of packet queues in buffers filling up and the time based nature of openvpn's replay attack prevention.

Lets say you are a residential user who has a modest connection of 200 mbps and the openvpn server is a fast pipe 1gb. You fire up that steam game download and o0nce you approach your max limits on speed, either as high upstream or downstream you'll find that gateway latencies go through the roof. This is a normal phenomena of nic buffer queues and we can mitigate that through the use of CAKE / FQ_CODEL and other solutions but those don't completely fix the issue, just help reduce the amount of packets that are erroneously dropped.

Once that event occurs [high latency] we then start to see the openvpn gateways start to drop packets, thinking its a replay attack because the openvpn server hasn't received the packets in the time required (yes this is modifiable by some flags, but in practice i've found this to not resolve the issue for me and others). The end result being that the packets then end up being erroneously dropped.

Another well known solution has the same replay attack prevention but it accomplishes it differently, through incremental counting instead of being time based. The end result is that when you are in the same exact scenario i've described - the packets just keep flowing even though the gateway latencies are high, rather than being dropped.

Would this not just be a better scenario all round (incremental counting)? also please correct me if i have any misgivings on how the technologies work.

Start by reviewing OpenVPN's existing replay-attack prevention implementation and the configuration flags mentioned in the issue. Compare its time-based behavior with an incremental-counter approach under high latency; the issue does not identify files, tests, or a definitive completion criterion.