07-09-2017 09:32 AM
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.
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
Solved! Go to Solution.
07-10-2017 12:03 AM
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
07-10-2017 12:03 AM
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
07-10-2017 12:51 AM
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
07-10-2017 08:43 AM
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
07-11-2017 11:18 PM
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:
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
07-15-2017 11:42 PM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: