Example captures (client = 1.1.1.1 server = 2.2.2.2). The first capture is of a "broken" client, the second one is a "working" client. 18:47:42.016240 1.1.1.1 → 2.2.2.2 TCP 74 49138→443 [SYN] Seq=0 Win=26883 Len=0 MSS=1460 SACK_PERM=1 TSval=88462395 TSecr=0 WS=64 18:47:42.016254 2.2.2.2 → 1.1.1.1 TCP 74 443→49138 [SYN, ACK] Seq=0 Ack=1 Win=0 Len=0 MSS=1460 SACK_PERM=1 TSval=3050415126 TSecr=88462395 WS=128 18:47:42.236466 1.1.1.1 → 2.2.2.2 TCP 66 [TCP Keep-Alive] 49138→443 [ACK] Seq=0 Ack=1 Win=26944 Len=0 TSval=88462451 TSecr=3050415126 18:47:42.660495 1.1.1.1 → 2.2.2.2 TCP 66 [TCP Keep-Alive] 49138→443 [ACK] Seq=0 Ack=1 Win=26944 Len=0 TSval=88462557 TSecr=3050415126 18:47:43.509891 1.1.1.1 → 2.2.2.2 TCP 66 [TCP Keep-Alive] 49138→443 [ACK] Seq=0 Ack=1 Win=26944 Len=0 TSval=88462769 TSecr=3050415126 18:47:45.208593 1.1.1.1 → 2.2.2.2 TCP 66 [TCP Keep-Alive] 49138→443 [ACK] Seq=0 Ack=1 Win=26944 Len=0 TSval=88463194 TSecr=3050415126 Keeps sending Keep-Alives, haproxy sends http error 408 after a while. 13:18:49.627673 1.1.1.1 → 2.2.2.2 TCP 78 64776→443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=599171873 TSecr=0 SACK_PERM=1 13:18:49.628323 2.2.2.2 → 1.1.1.1 TCP 74 443→64776 [SYN, ACK] Seq=0 Ack=1 Win=0 Len=0 MSS=1460 SACK_PERM=1 TSval=3261482069 TSecr=599171873 WS=128 13:18:54.636632 1.1.1.1 → 2.2.2.2 SSL 67 [TCP ZeroWindowProbe] 13:18:54.637389 2.2.2.2 → 1.1.1.1 TCP 66 [TCP Window Update] 443→64776 [ACK] Seq=1 Ack=1 Win=14464 Len=0 TSval=3261482069 TSecr=599176873 13:18:54.637544 1.1.1.1 → 2.2.2.2 SSL 583 Client Hello 13:18:54.639903 2.2.2.2 → 1.1.1.1 TLSv1.2 1514 Server Hello TLS session is set up, everything works as expected. -- Met vriendelijke groet / Best regards, Joshua Vijsma > On 19 Mar 2018, at 16:39, Remy de Boer <remydb@xxxxxxxxxxx> wrote: > > Hi Llorente, > > Yeah, I do think it is a client issue somehow... > We took packet captures of both the sending side and the receiving > side and each time the problem appears we see a SYN reaching the > server, SYN-ACK being sent back, the SYN from the client never > reaching the server and after that just a bunch of keepalive SYNs from > the client. > When we tested from our own clients, simulating the packet loss by > dropping traffic on our laptops, we see that our clients managed to > get through by eventually sending a TCP Zero Window Probe. The clients > that end up timing out apparently never send these packets. > > On Sat, Mar 17, 2018 at 11:57 AM, Llorente Santos Jesus > <jesus.llorente.santos@xxxxxxxx> wrote: >> Hi Remy, >> >> I am also using a SYNPROXY in some of my scenarios. I would like to try and replicate your setup to better understand the situation. Could this be an issue with the client's TCP stack? In any case, can you indicate what OS are you running on the client side. Also, if you could make a pcap file available that'd be most helpful! >> >> Best, >> Jesus >> >> -----Original Message----- >> From: netfilter-owner@xxxxxxxxxxxxxxx [mailto:netfilter-owner@xxxxxxxxxxxxxxx] On Behalf Of Remy de Boer >> Sent: 16 March 2018 12:49 >> To: netfilter@xxxxxxxxxxxxxxx >> Subject: SYNPROXY, packet loss, and window sizes >> >> Hi all, >> >> We've been running into some trouble using SYNPROXY in a scenario where there's some packet loss outside of our network. >> >> Regularly, when a client connects to a server using SYNPROXY, a TCP handshake is performed where the server sends window size of 0. The client responds with an ACK, the server sends a window update and we can start using the connection. We're running into trouble where the following situation occurs: >> >> Client --SYN--> Server >> Server --SYN-ACK--> Client >> Client --ACK--> Server **LOST** >> >> After the ACK from the client to the server is lost, no window update is ever sent to the client, so no data is transmitted across the connection. The client starts sending keepalive packets and eventually times out. >> >> Is there any way to prevent this from happening? >> >> -Remy >> -- >> To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n����z���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
