replay packet(allow_err)

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.