Description
This article discusses the root cause of the traffic log 'replay packet(allow_err), suspicious'.
Scope
FortiGate.
Solution
If a user gets the log message 'replay packet(allow_err), suspicious' under the forward traffic log, it could be verified with following debug.
id=20095 trace_id=4029 func=tcp_anti_reply line=1112 msg="replay packet(allow_err), suspicious"
id=20095 trace_id=4029 func=ip_session_core_in line=6665 msg="anti-replay check fails, drop”
In certain scenarios, an identical TCP packet may enter the FortiGate firewall through two distinct ports or over the same port twice.
The anti-replay mechanism utilizes sequence numbers to label the packets, serving as a security measure to prevent unauthorized hosts
from injecting or altering packets traveling from a source to a destination. When the source transmits a message, it appends a sequence number to the packet, beginning at 0 and incrementing by 1 for each subsequent packet.
At the destination, a 'sliding window' record is maintained to keep track of the sequence numbers of the validated received packets. Any packets with a sequence number lower than the lowest in the sliding window or that are already present in the sliding window are rejected.
This mechanism ensures that invalid packets are discarded, contributing to the maintenance of communication integrity.
Frame 11: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Fortinet_09:00:22 (00:09:0f:09:00:22), Dst: VMware_a3:da:a0 (00:50:56:a3:da:a0)
Internet Protocol Version 4, Src: 10.100.65.60, Dst: 10.100.202.127
Transmission Control Protocol, Src Port: 58461, Dst Port: 1521, Seq: 276, Ack: 320, Len: 0
Source Port: 58461
Destination Port: 1521
[Stream index: 0]
[Conversation completeness: Complete, WITH_DATA (63)]<----- One of the indication of anti-replay packet SYN, FIN, and RST bit can not appear in the same packet.
..1. .... = RST: Present
...1 .... = FIN: Present
.... 0... = Data: Present
.... .1.. = ACK: Present
.... ..1. = SYN-ACK: Present
.... ...1 = SYN: Present
[Completeness Flags: RFDASS]
[TCP Segment Len: 0]
Sequence Number: 276 (relative sequence number)
Sequence Number (raw): 3888575475
[Next Sequence Number: 276 (relative sequence number)]
Acknowledgment Number: 320 (relative ack number)
Acknowledgment number (raw): 2235475073
1000 .... = Header Length: 32 bytes (8)
Flags: 0x014 (RST, ACK)
Window: 229
[Calculated window size: 29312]
[Window size scaling factor: 128]
Checksum: 0x65d7 [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
[Timestamps]
In the above screenshot, the same packet is received twice with the same sequence number but with a different Identification number, which triggers the anti-replay mechanism and leads to a packet drop on the firewall. The receiving FortiGate will log the discarded packets with the following message in the Event Log: 'replay packet(allow_err), suspicious'.
If it is not possible to manage or change the affected device in topology to avoid this, the workaround on the FortiGate can be to disable TCP replay verification packets.
config system global
set anti-replay | loose | strict | disable |
end
The issue could be observed with IPSec which leads to ESP packets being dropped. Anti-replay is a local setting for the IPsec phase. This could be resolved by disabling Anti-replay in the Phase-2 configuration.
config vpn ipsec phase2-interface
edit <phase2-name>
set replay <enable | disable>
end
