Chain of events:

1. One of the Security Group Members receives the connection and inspects it.
2. The Security Group Member synchronizes the connection information to all other Security Group Members.
3. Because the delayed sync is enabled in the Security Group (this is the default), the connection's timeout is not updated on other Security Group Members.
4. At some later point, one of these other Security Group Members synchronizes its connection information with the old timeout to all other Security Group Members.
5. The connection timeout is decreased as if this connection was idle for a short period.
6. As a result, the connection packets are treated as part of a closed connection and are dropped as "out of state".

To make sure this is the issue in your Security Group, you can run this debug (see the R81.10 Security Gateway Administration Guide > Chapter Kernel Debug):

Important Note - Debug causes higher load on the CPU.

g_fw ctl zdebug + conn nat xlate xltrc

During the described issue, the debug shows this flow:

1. The connection opens, and one of the Security Group Member receives it for inspection.
2. The Security Group Member that received this connection synchronizes its information to other Security Group Members with a TCP start timeout.
3. The Security Group Member that received this connection updates the connection timeout value.
4. One of the other Security Group Members synchronizes its connection information to other Security Group Members with the original TCP start timeout.

For more information about the delayed sync, see the R81.10 Maestro Administration Guide > Chapter System Optimization > Section Configuring Services to Synchronize After a Delay.