Why would a server not send a SYN/ACK packet in response to a SYN packet
Solution 1:
We had this exact same problem. Just disabling TCP timestamps solved the problem.
sysctl -w net.ipv4.tcp_timestamps=0
To make this change permanent, make an entry in /etc/sysctl.conf
.
Be very careful about disabling the TCP Window Scale option. This option is important for providing maximum performance over the internet. Someone with a 10 megabit/sec connection will have a suboptimal transfer if the round trip time (basically same as ping) is more than 55 ms.
We really noticed this problem when there were multiple devices behind the same NAT. I suspect that the server might have been confused seeing timestamps from Android devices and OSX machines at the same time since they put completely different values in the timestamp fields.
Solution 2:
In my case the following command fixed the problem with missing SYN/ACK replies from Linux server:
sysctl -w net.ipv4.tcp_tw_recycle=0
I think it is more correct than disabling TCP timestamps, as TCP timestamps are useful for high performance (PAWS, window scaling, etc).
The documentation on the tcp_tw_recycle
explicitly states that it is not recommended to enable it, as many NAT routers preserve timestamps and thus PAWS kicks in, as timestamps from the same IP are not consistent.
tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4) Enable fast recycling of TIME_WAIT sockets. Enabling this option is not recommended for devices communicating with the general Internet or using NAT (Network Address Translation). Since some NAT gateways pass through IP timestamp values, one IP can appear to have non-increasing timestamps. See RFC 1323 (PAWS), RFC 6191.