Network & Infrastructure / Segmentation, TLS & Secure Connectivity
IPsec anti-replay drops after packet-path reordering
A multipath WAN change increases VPN drops even though both circuits are healthy. Packets arriving outside the receiver's accepted sequence window may trigger anti-replay rejection.
Environment and inputs: Stateful network boundaries, TLS endpoints and IPsec gateways; use the deployed security policy and implementation manual. Diagnostic/design example; not tested on production equipment.
Collect the evidence
Record anti-replay counters, sequence behavior, path latency differences and per-packet versus per-flow forwarding. Distinguish delayed legitimate packets from actual duplication or corrupted traffic.
Explain the result
Anti-replay protection rejects unacceptable sequence reuse or excessive lateness according to the implementation. Unequal paths can reorder traffic enough to expose a window constraint without a cryptographic negotiation failure.
Plan the fix
Restore suitable flow ordering or evaluate a supported window setting against the security requirement. Do not disable anti-replay globally simply because it is the counter that reveals the problem.
Check the result and rollback
Measure drops and latency under peak traffic and path failure. Revert if a window change weakens required protection or merely conceals persistent instability in the WAN forwarding design.