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]> a écrit :
jehan procaccia INT via frnog<[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/
