Re: [TECH] academique, routage BGP asymetrique casse TLS 443

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/