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