ssh connection

Thanks for the excellent explanation. Does the VS type have an affect? I am under the impression for a standard VS type, the 3WHS needs to complete with the client before a SYN is sent to the pool member, so the above explanation aligns perfectly.

But for a Performance L4 VS, it passed the SYN to the server before completing the 3WHS. https://support.f5.com/csp/article/K8082

Does this mean that we negate the benefits of SYN cookie when using a perf L4 a VS type?

When SYN cookie is activated, regardless the type of the virtual server, BIG-IP needs to work in a full proxy mode for the initial TCP 3WHS with client in order to confirm that it is not an attacker. This means that BIG-IP will first handle SYN Cookie TCP handshake with client, and once BIG-IP confirms client is legitimate it will start a second TCP 3WHS with the server.

SYN Cookie works in the same way for Standard or FastL4 virtual server, so it can work with FastL4 virtual servers as well. If this is the case BIG-IP modifies traditional FastL4 behaviour by disallowing direct initial TCP 3WHS negotiation between client and server, instead it will work as a typical Standard virtual server, but only for the initial TCP 3WHS.

Note that FasL4 profile goal is accelerating the connection traffic between client and server (not for accelerating TCP 3WHS) by offloading eligible flows to the ePVA chip for acceleration. So once client is confirmed as legitiate then rest of the traffic for the connection will behaves as expected for a FastL4 virtual server.

Thanks for clarifying the above. This article series goes a long way to explaining how the big-ip handles SYN cookies. I remember looking for a detailed explanation 18 months ago and didn’t seem anything this detailed. Great post!!!