05-10-2009 08:56 AM
Let me try to explain this. Standard Server Load Balancing is going to forward every packet to the real server right away. A new connection from a client is going to start with the SYN packet. This SYN packet is getting load balanced and the ServerIron/ADX is going to send it to the selected real server at the time it arrives at the ServerIron. That implies that the real servers are getting ALL the SYN packets arriving for the virtual servers and they do get these packets in real time.
A SYN flood attack against a virtual server is therefore going to result in a SYN flood attack against the real server.
SYN-Guard/-Proxy is trying to protect the real servers. The ServerIron is not going to forward all the SYNs right away - instead the ServerIron is going to reply to the SYNs himself. The ServerIron is going to send a SYN/ACK as answer to the SYN without sending anything to the real server. The ServerIron is going to wait for an ACK from the client now (to finish the 3-way handshale). A sessions is getting forwarded to the real servers (or to one of the real servers) at the time the 3-way handshake is complete.
A lot of the SYN flood attacks do use SYNs coming from spoofed client IPs. The attacker is normally not going to reply to the SYN/ACK coming back from the ServerIron. The 3-way handshake does not complete in these cases and the SYN/session does not hit the real servers at all which protects the real servers.
I hope this helps. So called SYN-cookies are used to handle this. Have a look at the description of SYN-cookies in case there are still some open questions.