TRex Opening connection method

[roic]

Hi Experts,

I'm testing TRex to see how it can help us to improve our testing methodology and I encountered a problem.

I'm 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.

Is there a way for me to make it work? Or since pcaps are being used its a lost cause?

Thanks,

Roi

[hhaim@cisco.com · Accepted solution]

Hi Roi,

you are right. We 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.

thanks

Hanoh

[hhaim@cisco.com]

Hi Roi,

After talking with Ido  I 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

Hanoh

[roic]

Hi Hanoch, thank you for the fast answer.

What I described 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.

And as you mentioned it's indeed utilizes the FW CPU. Will the TCP stack feature will be able to support it?

Also, I remember I saw somewhere that one of the next planned features is supporting client & server machines. If I remember correctly this actually supports the above, am I correct?

In general, I assume the TCP stack will support fragmentation, packet splitting, retransmission, fixing packet TCP checksum and reject/reset, but will it enforce timeout on sent packets?

Thanks,

Roi

[hhaim@cisco.com]

Hi Roi, understood, man-in-the-middle SYN DDos protection is cheaper from CPU utilization perspective than a full TCP proxy, agreed.

You are probably referring to this feature:

https://communities.cisco.com/community/developer/trex/blog/2017/06/20/trex-upcoming-stateful-scalable-tcp-support

To your questions:

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

Something like that

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

or even on Tx side

Could you explain why it is important as TCP will try to send the information in all cases. Maybe you want to simulate application that has timeout on write/read, which application has this feature?

thanks

Hanoh

[roic]

Hi Hanoch, thanks again for the detailed answer.

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.