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]> 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/
