On Thu, Oct 22, 2015 at 07:26:20PM +0200, Lukas Tribus wrote: > > Hi, > > > > I checked kernel log and I can't find anything. How do I procede? > > Ask kernel folks. Or don't disable tcp_timestamps, a lot of important > TCP features rely on it and those "security reasons" are ridiculous > anyway. > > Uptime is not supposed to be a secret, if someone can attack you based > on its knowledge of your uptime, your "security concept" is broken > anyway.
TCP timestamps are used as a complement for sequence numbers. Some firewalls (eg: Cisco ACE) love to add extra randomization to TCP sequence numbers to protect unsafe operating systems. The problem is that by doing so they randomly prevent new connections from establishing because a client which uses a higher sequence number can appear on the server with a lower one, making the server take it for a retransmit. In this case, timestamps help the server detect that since the timestamp is higher than the last one, it cannot be a retransmit so it's a new session. This is called PAWS (protection against wrapped sequence numbers). That's just one example among many good examples for TCP timestamps, of course. The real problem you're facing here, regardless of timestamps, is that since you're working in TCP mode and your client closes first (shame on it for this), haproxy replicates and puts itself in a bad situation where its ports are left in TIME_WAIT state. There's a workaround against this, you can enable "option nolinger" on the backend. It will make haproxy close to the server using an RST and will not keep the TIME_WAIT sockets. Never do this in a frontend! Regards, Willy
