SYN packets ignored on higher traffic ubuntu 12 nginx server - tcp

Question

I have an ubuntu 12.04 server with nginx at port 80
There is only a single firewall rule, which relates to port mapping port 26 to 25
nginx is set to listen on port 80, initially in a fairly default manner but now with
listen x.x.x.x:80 backlog=5000;
nginx is not that loaded, about 50 requests a second says nginx_status
Active connections: 480
server accepts handled requests
84618 84618 143733
Reading: 0 Writing: 4 Waiting: 474
Some (a very few as a percentage) users complain that one of their computers (for example "it only happens at home") appears to have its SYN packets ignored. They can ping without loss. sometimes they get some responses to tcp requests. They can get responses on quiet ports for example the pop server. Generally however they experience long time outs. I have packet dumps from them that show this.
On my end, I can also see that some IP addresses are being ignored.
Here for example, multiple SYN packets from port 2010 to port 80 are not replied, while the server is fulfilling a prior connection on port 2031
02:21:46.950979 IP 72.38.0.37.2010 > 64.91.255.98.80: Flags [S], seq 3835139709, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
02:21:49.887320 IP 72.38.0.37.2010 > 64.91.255.98.80: Flags [S], seq 3835139709, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
02:21:55.923151 IP 72.38.0.37.2010 > 64.91.255.98.80: Flags [S], seq 3835139709, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
02:22:24.950448 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [S], seq 4138069869, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
02:22:24.950488 IP 64.91.255.98.80 > 72.38.0.37.2031: Flags [S.], seq 248034551, ack 4138069870, win 14480, options [mss 1460,sackOK,TS val 240617577 ecr 0,nop,wscale 7], length 0
02:22:24.982809 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [.], ack 1, win 50112, options [nop,nop,TS val 372774 ecr 240617577], length 0
02:22:24.982852 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [P.], seq 1:526, ack 1, win 50112, options [nop,nop,TS val 372774 ecr 240617577], length 525
02:22:24.982869 IP 64.91.255.98.80 > 72.38.0.37.2031: Flags [.], ack 526, win 122, options [nop,nop,TS val 240617585 ecr 372774], length 0
02:22:25.016783 IP 64.91.255.98.80 > 72.38.0.37.2031: Flags [P.], seq 1:265, ack 526, win 122, options [nop,nop,TS val 240617594 ecr 372774], length 264
02:22:25.190570 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [.], ack 265, win 50079, options [nop,nop,TS val 372777 ecr 240617594], length 0
02:22:45.017288 IP 64.91.255.98.80 > 72.38.0.37.2031: Flags [F.], seq 265, ack 526, win 122, options [nop,nop,TS val 240622594 ecr 372777], length 0
02:22:45.049437 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [.], ack 266, win 50079, options [nop,nop,TS val 372976 ecr 240622594], length 0
02:22:49.998299 IP 72.38.0.37.2031 > 64.91.255.98.80: Flags [R.], seq 526, ack 266, win 0, length 0
02:23:18.883263 IP 72.38.0.37.2059 > 64.91.255.98.80: Flags [S], seq 2419025537, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
02:23:21.890861 IP 72.38.0.37.2059 > 64.91.255.98.80: Flags [S], seq 2419025537, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
Much more simply, near the start of a 20 second period, here is a lone packet from one IP that is not paired with any other packets (to this host):
2:48:05.141703 IP 96.48.197.237.1275 > 64.91.255.98.80: Flags [S], seq 2682822499, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0
I wrote a perl script to watch a tcpdump and find / report the number of dangling SYNs, it finds a few every few seconds (as we go along the accumulated count of never-replied TCP SYN packets rises steadily). The rate of apparently unreplied SYNs is about 1 in 2500. When I ping those IPs, assuming they are pingable, there is no packet loss, no issue communicating with them.
Nothing useful (such as "sending syncookies") is in the kernel log.
nginx has
worker_processes 8
worker_connections 4096
keepalive is on, open_file_cache module is in use, but I'm struggling to see what other variables could silently ignore SYN packets but only and repeatably for specific IPs.
beyond the default ubuntu setup, sysctl.conf has
# increased
net.ipv4.tcp_fin_timeout = 10
net.ipv4.ip_local_port_range = 1024 65535
net.core.somaxconn = 1024
# default
net.ipv4.tcp_tw_reuse = 0
# default
net.netfilter.nf_conntrack_tcp_loose = 1
net.ipv4.netfilter.ip_conntrack_tcp_loose = 1
# reduced
net.netfilter.nf_conntrack_tcp_timeout_established = 86400
net.ipv4.tcp_ecn = 0
I've not experience this problem before, with the same audience, an earlier kernel nginx, different hardware (this is a virtual server). Different data center.
My "canary in a coal mine" reports that from their perspective they see the timeouts and lack of replies on their XP machine, but not if it goes via a linux machine setup as a proxy. So they are investigating that. However whatever their conclusion I'm not sure why I can sniff incoming SYN packets to port 80 with no subsequent reply packet sent out on the same interface.

Answer 1

Based on the information here
https://serverfault.com/questions/235965/why-would-a-server-not-send-a-syn-ack-packet-in-response-to-a-syn-packet
Turning off TCP timestamps on the server stopped SYNs getting dropped from Windows XP clients that send SYN packets with tsval set to zero, and the number of unreplied SYNs on the server went to zero and stayed there.
sysctl -w net.ipv4.tcp_timestamps = 0
My understanding is the behaviour of the XP stack when timestamps are enabled is well known as it has been discussed on the linux lists to do with ipv4, and at some point in time linux with tcp_timestamps enabled simply switched to non timestamp session with XP (or other buggy clients). It seems this behaviour has changed and now at least on busy ports, SYN packet with tsval 0 are dropped if tcp_timestamps is 1

Answer 2

Does your system have three way syn checking enabled? It sounds like it's checking for a three way handshake and some packets are not passing this check and even though they are not malicious, they are being dropped.
Check or post all of your configs and or check your router/firewall as this option is usually set by default.