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

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/