Yes I have this problem and want it to be fixed.

Overmore, speed behind SYNPROXY is about 3 times slower even when all the parameters are matched manually.

Hi,

Thanks for the SYN-Proxy! :)

I think this is a really important feature to have and probably not too hard to implement. Is there any timeline on this one? :)

Hi, 
I value this also as important. However, possible performance degradation of overall synproxy function should in minds. If performance degragation is possible this issue should be enabled by a sysctl.

Very necessary, any timeline on this one ?

This is really important, we are interested too.

So interesting in this too!

We consider this bz obsolete since the upstream listener rewrite, which seems to unfortunately not hitting RHEL7 for the moment.

Just out of curiosity: Are you referring to the TCP listener refactoring in Linux 4.4?

https://kernelnewbies.org/Linux_4.4#head-7c34e3af145ac61502d1e032726946e9b380d03d

(In reply to Steffen Weber from comment #11)
> Just out of curiosity: Are you referring to the TCP listener refactoring in
> Linux 4.4?
> 
> https://kernelnewbies.org/Linux_4.4#head-
> 7c34e3af145ac61502d1e032726946e9b380d03d

Yes, exactly.

This BZ would only be relevant if you are using synproxy on a firewall protecting servers behind it, what cannot be upgraded to use the listener scalability improvements, like Windows servers or old RH servers.

It would be pretty nice if this could be improved/fixed, because exactly of this statment:

"This BZ would only be relevant if you are using synproxy on a firewall protecting servers behind it, what cannot be upgraded to use the listener scalability improvements, like Windows servers or old RH servers."

Which is our case for example, and from many other people as well. :)

The problem is that the backend servers (in case of old RH servers, probably also windows servers) will reconfigure their TCP options at will (e.g. syncookies or based on the tcp buffer sizes). So you end up in very strange to debug situations because the options of the synproxy don't fit to the options the backend server would assume.

Notice, that setting those options in case you know what options are supported by the backend is already supported.

TCP Syn Cookies are great to know whether an IP source is valid or not, but TCP Contains "retransmission" of SYN Packets, so after you've tested it and it works good, why not letting the next syn retransmission to be direct sent or processed ? It would be a logical decision, considering it is a valid source IP that past the 3WH :) (So all options are preserved just fine).

Just to be sure you've got it:

1) Are you under attack ? 
No. -> Pass the SYN Packet to the system.
Yes. -> Test the SRC IP w/ Syn Cookies challenge.
2) Did the IP pass the challenge test ?
No. -> Discard further processing/drop packets.
Yes. -> Allocate the IP into a hashtable, let the next SYN Packet pass direct (no proxying or intervention). So the options are preserved.

Just an example, since the IP has past the 3-way handshake, then you can safely store it somewhere and whitelist it in a way the IP can communicate with the local server or a remote server through forwarding... :)

In general your idea might flight. A few more questions:

(In reply to Fred from comment #19)
> Just to be sure you've got it:
> 
> 1) Are you under attack ?

Who determines if we are under attack? If the request queues on the backend system(s) are full? How do you check for that without holding state on the synproxy? Do you hold state per 2-tuple for the backend? How to determine the request queue is full?

> No. -> Pass the SYN Packet to the system.
> Yes. -> Test the SRC IP w/ Syn Cookies challenge.
> 2) Did the IP pass the challenge test ?
> No. -> Discard further processing/drop packets.
> Yes. -> Allocate the IP into a hashtable, let the next SYN Packet pass
> direct (no proxying or intervention). So the options are preserved.

In case of IPv6 I just can now list huge address spaces as trusted and then start a syn attack from those trusted IPs? In the end you end up in syncookie situation on the backend systems, which you could have done in the first place, no?

> Just an example, since the IP has past the 3-way handshake, then you can
> safely store it somewhere and whitelist it in a way the IP can communicate
> with the local server or a remote server through forwarding... :)

Thanks for your idea! If we can come up with a design on how to do that this could very well be interesting to implement. But so far I still have some doubts.

>Who determines if we are under attack? If the request queues on the backend >system(s) are full? How do you check for that without holding state on the >synproxy? Do you hold state per 2-tuple for the backend? How to determine the >request queue is full?

Defined Request Rate or Forced Mode. (Since synproxy will handle this, the backend server will have no trouble at this mode).

>In case of IPv6 I just can now list huge address spaces as trusted and then >start a syn attack from those trusted IPs? In the end you end up in syncookie >situation on the backend systems, which you could have done in the first >place, no?

No, this must be stored per IP and if necessary to avoid small spoofed attacks using validated IPs, you can always use rate limiting in a firewall, that's not really an issue, except for packet intensive attacks, which aren't the issue here of course.

> Thanks for your idea! If we can come up with a design on how to do that this > could very well be interesting to implement. But so far I still have some > > doubts.

I've already done this myself in my own network stack using Intel DPDK, so yes this concept works fine, and preserves all the tcp options. :) (Thanks for RFC and for the TCP protocol design support this method).