Description
The article explains the IPSEC Anti-replay feature and how to prevent potential packet drops with it.
Scope
Any FortiGate version.
Solution
Anti-replay is a local setting for IPsec phase2. It is not negotiated between IPsec peers, meaning it does not impact the establishment of tunnels.
Enable or disable Anti-Replay as follows in in IPsec phase2 configuration:
# config vpn ipsec phase2-interface
edit <phase2-name>
set replay <enable | disable>
end
However, anti-replay can affect the traffic through the tunnel, which can lead to ESP packets being dropped. It is recommended to have the same anti-replay setting on both the local and peer IPsec.
The anti-replay mechanism uses sequence numbers to mark the ESP packets. The sequence number is in clear-text, meaning it should only be trusted if authentication is enabled. If anti-replay is enabled for the inbound IPsec SA or phase2, the sequence number is checked by the recipient.
The sender increases the sequence number by one for each sent ESP packet. The receiver compares the received sequence number and adjusts the sliding anti-replay window. If any encrypted packet arrives out of order and not in the window range, the FortiGate unit discards it. The receiver can reject old or duplicate packets to protect itself against replay attacks, preventing unauthorized parties from intercepting and replaying a series of IPsec packets.
The receiving FortiGate will log the discarded packets with the following message in the Event Log: 'Invalid ESP packet detected (replayed packet)'.
As the anti-replay is not negotiated, FortiGate will act according to its local anti-replay settings.
During failover in a High Availability FortiGate cluster, sequence numbers are not synchronized between the master and the slave units (depending on the FortiOS versions as well as on NP interfaces and settings). This can cause the peer FortiGate to drop ESP packets.
If anti-replay is disabled on the local IPsec unit but enabled on the peer, the sequence number from the local FortiGate should not enter the replay windows of the IPsec peer, which will discard it. In this situation, the IPsec tunnels are up on both IPsec units. The Tx ESP packet counter is increasing for phase2, but there are most likely no new Rx packets.
In FortiOS V5.2, the ESP sequence numbers are NOT synchronized between HA master and slave nodes. When anti-replay is disabled and a failover occurs, the new master will start sending packets with a sequence number of 1. If anti-replay is enabled, the FortiGate will force a rekey and IPsec negotiation.
In FortiOS V5.4 and above, the ESP sequence numbers are synchronized between master and slave nodes depending on the parameter from the Phase1 configuration 'set ha-sync-esp-seqno enable | disable' (enabled by default).
As of FortiOS V5.2 and above, if IPsec is configured with IKEv2, according to the support and negotiation of RFC 6311, the local and peer FortiGates will exchange the message-ID field to protect against replay.
