replay packet(allow_err)

[Sveda]

Hi there, I want to know what does the Message " replay packet(allow_err), drop" exactly mean? I have a problem with updating my branch offices Antiviruses which are connected to head office through fortigate 400A. In the section of log access of fortianalyzer,deny logs for antivirus update, all have replay packet(allow_err), drop message. all the policy and network configurations are correct. thank you for the help.

[AtiT]

Hi, I have a same error message in our logs. The TT is open at Fortinet for that.

[AtiT · Accepted solution]

FYI: (answer from the Fortinet support) FortiGate units use TCP sequence checking to make sure that a packet is part of a TCP session. By default, if a packet is received with sequence numbers that fall out of the expected range, the FortiGate unit drops the packet. This is normally a desired behavior, since it means that the packet is invalid. The default is strict, you can change it to loose to see if this solves your issue: # conf sys global # set anti-replay loose # end You can set anti-replay protection to the following settings: • disable — No anti-replay protection. • loose — Perform packet sequence checking and ICMP anti-replay checking with the following criteria: - the SYN, FIN, and RST bit can not appear in the same packet. - the FortiGate unit does not allow more than one ICMP error packet through before it receives a normal TCP or UDP packet. - if the FortiGate unit receives an RST packet, and check-reset-range is set to strict, the FortiGate unit checks to determine if its sequence number in the RST is within the un-ACKed data and drops the packet if the sequence number is incorrect. • strict — Performs all of the loose checking but for each new session also checks to determine of the TCP sequence number in a SYN packet has been calculated correctly and started from the correct value for each new session. Strict anti-replay checking can also help prevent SYN flooding. If any packet fails a check it is dropped. Regarding reasons why the " no session matched" might appear in the logs: a. If strict-dirty-session check is enabled, Fortigate unit will delete the session if a routing or policy change causes the session to no longer match the policy. But it is not the case, because you have this setting disabled. b. Log with message ' no session matched' is generated when a client tries to connect to a server with an old/expired connection which the Firewall doesn' t have any session opened for anymore. Example: - A user connects to the server and keeps the connection idle - Fortigate will have a session for this connection - After idle timeout, the Firewall will remove this session from its session table - However, the user tries to use the same old session and the Firewall will block this access saying " no session matched" c. It could also be due to one side sending the " fin/ack" packets to close the session. After the session is closed, a duplicate packet that is still on the network is received however, the session was already removed from the session table on the FGT.

[Rookie_tr]

we have same problem from turkey. we are usıng fortigate 600d . when we check the packet  , source and  destination  interface is unknown and there is no packet going through.  we searched from internet and found out that the problem is relayed to anti replay and asymetric route . But we didnt find to solve it. If you guys know about anything that problem. Could we help us ?