Je suis pas un fan des traces tcpdump, une trace tshark serait plus claire. Cependant, il me semble que le client doit renvoyer un ACK au SYN-ACK du serveur. Comme le serveur ne le reçoit pas, il continue d’envoyer des SYN-ACK. Après, tu as pris une trace restrictive dont je comprends pas l’intérêt, donc peut-être que les ack sont là mais pas dans ta trace. Sinon, prends un pcap complet de chaque côté et donne-les à analyser/comparer à Claude.
David > Le 6 mars 2026 à 17:06, jehan procaccia INT <[email protected]> a > écrit : > > Ok, dernier jet avant le weekend avec cette capture des 2 cotés pour avoir > un os a ronger ;-) > > coté "client" VPS OVH qui initie la connexion > > # openssl s_client -connect srv.int-evry.fr:443 > Connecting to 157.150.11.6 > CONNECTED(00000003) > write:errno=104 > > ce meme client voit ceci en filtrant sur l'IP du serveur sollicité > > # tcpdump -i eth0 host 157.150.11.6 and 'tcp[tcpflags] & tcp-syn != 0' -nnvv > dropped privs to tcpdump > tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length > 262144 bytes > > > 16:52:54.044825 IP (tos 0x0, ttl 64, id 53493, offset 0, flags [DF], proto > TCP (6), length 60) > 51.178.25.200.46744 > 157.150.11.6.443: Flags [S], cksum 0xf58d > (incorrect -> 0xf8d3), seq 1392587108, win 65320, options [mss 1420,sackOK,TS > val 3947115214 ecr 0,nop,wscale 7], length 0 > 16:52:54.050731 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0x7651 > (correct), seq 1591607196, ack 1392587109, win 28960, options [mss > 1460,sackOK,TS val 3467895586 ecr 3947115214,nop,wscale 8], length 0 > 16:52:55.452651 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0x70d7 > (correct), seq 1591607196, ack 1392587109, win 28960, options [mss > 1460,sackOK,TS val 3467896988 ecr 3947115214,nop,wscale 8], length 0 > 16:52:57.452632 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0x6907 > (correct), seq 1591607196, ack 1392587109, win 28960, options [mss > 1460,sackOK,TS val 3467898988 ecr 3947115214,nop,wscale 8], length 0 > 16:53:01.452679 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0x5967 > (correct), seq 1591607196, ack 1392587109, win 28960, options [mss > 1460,sackOK,TS val 3467902988 ecr 3947115214,nop,wscale 8], length 0 > 16:53:09.452810 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0x3a27 > (correct), seq 1591607196, ack 1392587109, win 28960, options [mss > 1460,sackOK,TS val 3467910988 ecr 3947115214,nop,wscale 8], length 0 > > 16:53:25.452647 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0xfba6 > (correct), seq 1591607196, ack 1392587109, win 28960, options [mss > 1460,sackOK,TS val 3467926988 ecr 3947115214,nop,wscale 8], length 0 > > ^C > 7 packets captured > 9 packets received by filter > 0 packets dropped by kernel > > J'ai pourtant l'impression qu'il reçoit bien les reponses dès le 2eme packet > > 16:52:54.050731 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0x7651 > (correct), seq 1591607196, ack 1392587109, win 28960, options [mss > 1460,sackOK,TS val 3467895586 ecr 3947115214,nop,wscale 8], length 0 > > Qui correspond a la reponse coté serveur > > 17:52:54.047975 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0xf58d > (incorrect -> 0x7651), seq 1591607196, ack 1392587109, win 28960, options > [mss 1460,sackOK,TS val 3467895586 ecr 3947115214,nop,wscale 8], length 0 > > => meme seq 1591607196, qui ack 1392587109 => demande initiale en seq > 1392587108 , bref tout semble bon jusque là , non ? > > Coté Serveur tj la meme chose au total > > # tcpdump -i eth0 host 51.178.25.200 and 'tcp[tcpflags] & tcp-syn != 0' -nnvv > dropped privs to tcpdump > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 > bytes > > > 17:52:54.047928 IP (tos 0x0, ttl 48, id 53493, offset 0, flags [DF], proto > TCP (6), length 60) > 51.178.25.200.46744 > 157.150.11.6.443: Flags [S], cksum 0xf8d3 > (correct), seq 1392587108, win 65320, options [mss 1420,sackOK,TS val > 3947115214 ecr 0,nop,wscale 7], length 0 > 17:52:54.047975 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0xf58d > (incorrect -> 0x7651), seq 1591607196, ack 1392587109, win 28960, options > [mss 1460,sackOK,TS val 3467895586 ecr 3947115214,nop,wscale 8], length 0 > 17:52:55.449927 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0xf58d > (incorrect -> 0x70d7), seq 1591607196, ack 1392587109, win 28960, options > [mss 1460,sackOK,TS val 3467896988 ecr 3947115214,nop,wscale 8], length 0 > 17:52:57.449883 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0xf58d > (incorrect -> 0x6907), seq 1591607196, ack 1392587109, win 28960, options > [mss 1460,sackOK,TS val 3467898988 ecr 3947115214,nop,wscale 8], length 0 > 17:53:01.449928 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0xf58d > (incorrect -> 0x5967), seq 1591607196, ack 1392587109, win 28960, options > [mss 1460,sackOK,TS val 3467902988 ecr 3947115214,nop,wscale 8], length 0 > 17:53:09.449913 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0xf58d > (incorrect -> 0x3a27), seq 1591607196, ack 1392587109, win 28960, options > [mss 1460,sackOK,TS val 3467910988 ecr 3947115214,nop,wscale 8], length 0 > > 17:53:25.449930 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 60) > 157.150.11.6.443 > 51.178.25.200.46744: Flags [S.], cksum 0xf58d > (incorrect -> 0xfba6), seq 1591607196, ack 1392587109, win 28960, options > [mss 1460,sackOK,TS val 3467926988 ecr 3947115214,nop,wscale 8], length 0 > > ^C > 7 packets captured > 7 packets received by filter > 0 packets dropped by kernel > > Bref je reste perplexe ... > > Merci > > > > On 3/6/26 17:18, David Ponzone wrote: >> Faut prendre une trace tcpdump sur le client aussi, pour comparer paquet par >> paquet, ça te dira s’il y a des paquets retour qui ont été filtrés. >> Après, on peut faire une comparaison des 2 traces avec Wireshark à priori >> (sujet abordé dans un autre fil récemment). >> >> David >> >>> Le 6 mars 2026 à 16:15, jehan procaccia INT <[email protected]> >>> <mailto:[email protected]> a écrit : >>> >>> MErci , mais bof .. cela ne change pas apparement >>> >>> sur le client VPS OVH je fait >>> >>> # ip link set dev eth0 mtu 1460 >>> >>> c'est bien en place >>> >>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc fq_codel state UP >>> group default qlen 1000 >>> >>> je lance mon test >>> >>> # openssl s_client -connect srv.int-evry.fr:443 >>> >>> meme echec >>> >>> coté server destination je vois bien arriver la requetes comme avant avec >>> un Syn from 51.178.25.200 (VPS OVH) et des reponses Syn-Ack depuis mon >>> serveur lcoal (157.150.11.6) qui ne semblent pas revenir sur le VPS OVH :-( >>> >>> # tcpdump -i eth0 host 51.178.25.200 and 'tcp[tcpflags] & tcp-syn != 0' >>> -nnvv >>> >>> 17:08:01.589820 IP (tos 0x0, ttl 48, id 2470, offset 0, flags [DF], proto >>> TCP (6), length 60) >>> 51.178.25.200.40236 > 157.150.11.6.443: Flags [S], cksum 0xd098 >>> (correct), seq 412271373, win 65320, options [mss 1420,sackOK,TS val >>> 3944422756 ecr 0,nop,wscale 7], length 0 >>> 17:08:01.589873 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP >>> (6), length 60) >>> 157.150.11.6.443 > 51.178.25.200.40236: Flags [S.], cksum 0xf58d >>> (incorrect -> 0xba7f), seq 466676691, ack 412271374, win 28960, options >>> [mss 1460,sackOK,TS val 3465203128 ecr 3944422756,nop,wscale 8], length 0 >>> 17:08:02.591909 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP >>> (6), length 60) >>> 157.150.11.6.443 > 51.178.25.200.40236: Flags [S.], cksum 0xf58d >>> (incorrect -> 0xb695), seq 466676691, ack 412271374, win 28960, options >>> [mss 1460,sackOK,TS val 3465204130 ecr 3944422756,nop,wscale 8], length 0 >>> 17:08:04.591924 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP >>> (6), length 60) >>> 157.150.11.6.443 > 51.178.25.200.40236: Flags [S.], cksum 0xf58d >>> (incorrect -> 0xaec5), seq 466676691, ack 412271374, win 28960, options >>> [mss 1460,sackOK,TS val 3465206130 ecr 3944422756,nop,wscale 8], length 0 >>> 17:08:08.591929 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP >>> (6), length 60) >>> 157.150.11.6.443 > 51.178.25.200.40236: Flags [S.], cksum 0xf58d >>> (incorrect -> 0x9f25), seq 466676691, ack 412271374, win 28960, options >>> [mss 1460,sackOK,TS val 3465210130 ecr 3944422756,nop,wscale 8], length 0 >>> 17:08:16.793894 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP >>> (6), length 60) >>> 157.150.11.6.443 > 51.178.25.200.40236: Flags [S.], cksum 0xf58d >>> (incorrect -> 0x7f1b), seq 466676691, ack 412271374, win 28960, options >>> [mss 1460,sackOK,TS val 3465218332 ecr 3944422756,nop,wscale 8], length 0 >>> 17:08:32.794923 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP >>> (6), length 60) >>> 157.150.11.6.443 > 51.178.25.200.40236: Flags [S.], cksum 0xf58d >>> (incorrect -> 0x409a), seq 466676691, ack 412271374, win 28960, options >>> [mss 1460,sackOK,TS val 3465234333 ecr 3944422756,nop,wscale 8], length 0 >>> ^C >>> 7 packets captured >>> 7 packets received by filter >>> 0 packets dropped by kernel >>> >>> >>> >>> >>> >>> >>> On 3/6/26 16:38, David Ponzone wrote: >>>> Ou en forçant le TCP MSS à 1420 par exemple. >>>> >>>> David Ponzone >>>> >>>> >>>> >>>>> Le 6 mars 2026 à 15:34, P. Deloney via frnog <[email protected]> >>>>> <mailto:[email protected]> a écrit : >>>>> >>>>> jehan procaccia INT via frnog <[email protected]> <mailto:[email protected]>: >>>>> >>>>>> oui j'ai des traces [1] >>>>> Ça ressemble clairement à un problème de MTU ou une mauvaise >>>>> configuration d'un pare-feu "stateful". >>>>> >>>>> Je ferais des tests en baissant le MTU de l'interface de l'hôte qui >>>>> initie la connexion TCP. >>>>> >>>>> >>>>> --------------------------- >>>>> Liste de diffusion du FRnOG >>>>> http://www.frnog.org/ >> --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
