;[SIM]do_outbound: forwarding packet to network (ifnum=...)...;
;[SIM]do_inbound: got packet 0x... on cpu N of <IP_1,Port_1,IP_2,Port_2,6>;
;[SIM]tcp_seqvalid_verify: cdir=s2c, state=0x60000, th_flags=0x..., seq=0x..., otherdir_seq=0x..., ack=0x..., otherdir_ack=0x...ourdir_seq=0x..., ourdir_ack=0x...;
;[SIM]tcp_seqvalid_verify: Established ACK mismtach (otherdir->ack=..., ack=..., otherdir->seq=...) -> forwarding to firewall;
;[SIM]simtcp_validate_tcp : TCP packet (th_flags=0x...) with invalid sequence information <IP_2,Port_2,IP_1,Port_1,6>-> forwarding to firewall;
;[SIM]do_inbound: Possible TCP state violation for <IP_1,Port_1,IP_2,Port_2,6> -> forwarding to firewall;
;fwconn_lookup_other_ex: conn <dir 0, IP_2:IP_2 -> IP_1:Port_1 IPP 6;...>
found in connections table;
;fwseqvalid_local_set: Setting current parameters ...;
The issue is more likely to occur when Security Gateway is under medium or high load.
"Invalid ACK" means that Security Gateway detected an "ACK" on a packet that was never sent or a duplicate "ACK".
For every TCP flow, the SecureXL mechanism updates the database with Sequence and Acknowledge numbers. Specific flows can cause a race condition between SecureXL and Firewall mechanism. When such condition occurs, the SecureXL mechanism is not updating the database regarding the sequence number of the accelerated packet. The TCP reply packet will be dropped since it is acknowledging a packet that is presumably was not seen by the Firewall.