TRex Opening connection method

The testing a FW and one of the ways the FW works is like this. 

1. Client sends Syn to server
2. FW captures the Syn and returns to the client SynAck (without sending the Syn packet to the server)
3. Client sends Ack to the server
4. FW capture the Ack and then starts a 3way handshake with the server. 

• In other words the client thinks it speaks with the server but it actually complete 3way handshake with the FW and only then the FW starts & completes the 3way handshake with the Server. 
• TRex seems confused from it and as a result the server starts to send packets before the FW expect the packets to arrive. 

Tried to solve most cases (like NAT/FW syn randomization etc) but in this case the current Stateful (with --learn) won't work because the learn expect specific sequence of packets. However the new advance Stateful will work in this case as client and server are separate and uses TCP for L7 data.

Realized that what you are describing is TCP proxy as there is no way to "connect" the original client session  with the new server session. All the connection should continue to be proxy throw the FW. This will consume CPU utilization from the FW 

• Resembeled TCP proxy, but the more accurate description will be man in the middle, as the FW actually is the server for the client machine and the client for the server machine.
• it's indeed utilizes the FW CPU. Will the TCP stack feature will be able to support it.
•  one of the next planned features is supporting client & server machines.
• In general, I assume the TCP stack will support fragmentation, packet splitting, re transmission, fixing packet TCP checksum and reject/reset, but will it enforce timeout on sent packets.

TRex scalable TCP feature will support Man-in-the-middle,packet splitting, retransimition, fixing TCP checksum, reset/reject.

1. IP fragmentation will be implemented in the second phase
2. Timeout wasn't implemented yet, but could be added to the L7 emulation instruction model

rx_expect_data(min_len=1024, timeout=12sec) à in case of timeout send reset/close

or even on Tx side 

Regarding the timeout, it's more FW related than application related, since the FW can hold (=delay) packets from time to time to have the next few packets in order to validate the connection.