oui j'ai des traces [1]
je suis d'accord avec l'asymetrie, elle devrait marcher, je ne comprend
pas où cela bloque, je commence a douter de mes propres firewalls, j'ai
pourtant essayé d'ouvrir a max pour debuger, rien n'y fait, d'où mon
debut de doute sur des filtrages upstream, anti-ddos etc ... ou des
comortements specifique sur 443 ?
Merci
jehan
[1] cote VPS client je lance
/# openssl s_client -connect //srv.int-evry.fr//:443
Connecting to 157.155.11.6
CONNECTED(00000003)/
/*ZZZZZZZ +30s */
/*write:errno=104*//
---
no peer certificate available
---
No client certificate CA names sent
Negotiated TLS1.3 group: <NULL>
---
SSL handshake has read 0 bytes and written 331 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.3
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---/
tcpdump coté serveur sur mon domain from le vps OVH
/# tcpdump -i eth0 host 51.178.25.200
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:47:02.504473 IP vps.ovh.fr.55234 > srv.int-evry.fr.https: Flags [S],
seq 847706420, win 64240, options [mss 1460,sackOK,TS val 3939563671 ecr
0,nop,wscale 7], length 0
15:47:02.504523 IP srv.int-evry.fr.https > vps.ovh.fr.55234: Flags [S.],
seq 3777766361, ack 847706421, win 28960, options [mss 1460,sackOK,TS
val 3460344042 ecr 3939563671,nop,wscale 8], length 0
15:47:03.733923 IP srv.int-evry.fr.https > vps.ovh.fr.55234: Flags [S.],
seq 3777766361, ack 847706421, win 28960, options [mss 1460,sackOK,TS
val 3460345272 ecr 3939563671,nop,wscale 8], length 0
15:47:05.934885 IP srv.int-evry.fr.https > vps.ovh.fr.55234: Flags [S.],
seq 3777766361, ack 847706421, win 28960, options [mss 1460,sackOK,TS
val 3460347472 ecr 3939563671,nop,wscale 8], length 0
15:47:09.935917 IP srv.int-evry.fr.https > vps.ovh.fr.55234: Flags [S.],
seq 3777766361, ack 847706421, win 28960, options [mss 1460,sackOK,TS
val 3460351474 ecr 3939563671,nop,wscale 8], length 0
15:47:17.935891 IP srv.int-evry.fr.https > vps.ovh.fr.55234: Flags [S.],
seq 3777766361, ack 847706421, win 28960, options [mss 1460,sackOK,TS
val 3460359474 ecr 3939563671,nop,wscale 8], length 0
15:47:33.835579 IP vps.ovh.fr.55234 > srv.int-evry.fr.https: Flags [R],
seq 847706421, win 64240, length 0
15:47:56.212478 IP vps.ovh.fr.55234 > srv.int-evry.fr.https: Flags [P.],
seq 1:332, ack 1, win 502, options [nop,nop,TS val 3939617379 ecr
3460344042], length 331
15:47:56.212549 IP srv.int-evry.fr.https > vps.ovh.fr.55234: Flags [R],
seq 3777766362, win 0, length 0
^C
9 packets captured
10 packets received by filter
0 packets dropped by kernel/
Quand cela marche depuis le meme client VPS OVH qui interroge un serveur
en ldapS et subissant la meme asymetrie :
client OVH :
/# openssl s_client -connect idex.imtbs-tsp.eu:636
/
/Connecting to 157.159.10.146
CONNECTED(00000003)
depth=2 C=GR, O=Hellenic Academic and Research Institutions CA,
CN=HARICA TLS RSA Root CA 2021
verify return:1
depth=1 C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT
TLS RSA 1
verify return:1
depth=0 CN=*.int-evry.fr
verify return:1
.../
/SSL handshake has read 6832 bytes and written 649 bytes
Verification: OK
---
New, TLSv1.2, Cipher is AES256-GCM-SHA384
Protocol: TLSv1.2
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : AES256-GCM-SHA384/
=> ça marche .
tcpdump au meme moment sur mon serveur ldapS OK aussi
/# tcpdump -i eth0 host 51.178.25.200
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:54:35.743347 IP vps.ovh.fr.51538 > srvldap.int-evry.fr.ldaps: Flags
[S], seq 2388345249, win 64240, options [mss 1460,sackOK,TS val
302939008 ecr 0,nop,wscale 7], length 0
15:54:35.743386 IP srvldap.int-evry.fr.ldaps > vps.ovh.fr.51538: Flags
[S.], seq 2846724707, ack 2388345250, win 28960, options [mss
1460,sackOK,TS val 565242153 ecr 302939008,nop,wscale 8], length 0
15:54:35.749208 IP vps.ovh.fr.51538 > srvldap.int-evry.fr.ldaps: Flags
[.], ack 1, win 502, options [nop,nop,TS val 302939014 ecr 565242153],
length 0
15:54:35.750537 IP vps.ovh.fr.51538 > srvldap.int-evry.fr.ldaps: Flags
[P.], seq 1:332, ack 1, win 502, options [nop,nop,TS val 302939015 ecr
565242153], length 331
15:54:35.750558 IP srvldap.int-evry.fr.ldaps > vps.ovh.fr.51538: Flags
[.], ack 332, win 118, options [nop,nop,TS val 565242161 ecr 302939015],
length 0
15:54:35.750738 IP srvldap.int-evry.fr.ldaps > vps.ovh.fr.51538: Flags
[P.], seq 1:4097, ack 332, win 118, options [nop,nop,TS val 565242161
ecr 302939015], length 4096
15:54:35.750796 IP srvldap.int-evry.fr.ldaps > vps.ovh.fr.51538: Flags
[P.], seq 4097:6575, ack 332, win 118, options [nop,nop,TS val 565242161
ecr 302939015], length 2478
15:54:35.756559 IP vps.ovh.fr.51538 > srvldap.int-evry.fr.ldaps: Flags
[.], ack 1449, win 513, options [nop,nop,TS val 302939021 ecr
565242161], length 0
15:54:35.756586 IP vps.ovh.fr.51538 > srvldap.int-evry.fr.ldaps: Flags
[.], ack 4097, win 501, options [nop,nop,TS val 302939021 ecr
565242161], length 0
15:54:35.756589 IP vps.ovh.fr.51538 > srvldap.int-evry.fr.ldaps: Flags
[.], ack 6575, win 489, options [nop,nop,TS val 302939021 ecr
565242161], length 0
15:54:35.768727 IP vps.ovh.fr.51538 > srvldap.int-evry.fr.ldaps: Flags
[P.], seq 332:650, ack 6575, win 513, options [nop,nop,TS val 302939033
ecr 565242161], length 318
15:54:35.769831 IP srvldap.int-evry.fr.ldaps > vps.ovh.fr.51538: Flags
[P.], seq 6575:6833, ack 650, win 122, options [nop,nop,TS val 565242180
ecr 302939033], length 258
15:54:35.816281 IP vps.ovh.fr.51538 > srvldap.int-evry.fr.ldaps: Flags
[.], ack 6833, win 517, options [nop,nop,TS val 302939081 ecr
565242180], length 0
15:54:38.856541 IP vps.ovh.fr.51538 > srvldap.int-evry.fr.ldaps: Flags
[F.], seq 650, ack 6833, win 517, options [nop,nop,TS val 302942121 ecr
565242180], length 0
15:54:38.856725 IP srvldap.int-evry.fr.ldaps > vps.ovh.fr.51538: Flags
[P.], seq 6833:6864, ack 651, win 122, options [nop,nop,TS val 565245267
ecr 302942121], length 31
15:54:38.856746 IP srvldap.int-evry.fr.ldaps > vps.ovh.fr.51538: Flags
[F.], seq 6864, ack 651, win 122, options [nop,nop,TS val 565245267 ecr
302942121], length 0
15:54:38.862581 IP vps.ovh.fr.51538 > srvldap.int-evry.fr.ldaps: Flags
[R], seq 2388345900, win 0, length 0
15:54:38.862584 IP vps.ovh.fr.51538 > srvldap.int-evry.fr.ldaps: Flags
[R], seq 2388345900, win 0, length 0
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel/
On 3/6/26 15:25, David Ponzone wrote:
Tu as pris une trace côté client ?
Il reçoit les réponses ou pas ?
En retard ? Modifiées ?
SI le routage asymétrique posait problème à ce point, les choses seraient
vraiment compliquées :)
David
Le 6 mars 2026 à 13:59, jehan procaccia int via frnog<[email protected]> a écrit :
Bonjour
j'ai un souci où j'aimerai avoir l'avis de la cammunauté.
nous sommes dual-home BGP (Renater d'un coté , FranceIX de l'autre) , un flux
entrant par Renater atteint bien mon serveur, mais le routage asymetrique
multi-homed le fait retourner par FranceIX, et dans ce cas la negociation
TLS/httpS echoue , le syn/ack de mon serveur en reponse au Syn du client (OVH)
semble etre perdu sur le retour.
j'ai verifié mes firewalls / ACL , pas de filtrage outbound, seulement du filtrage
en IN vers tcp/443 (ou 636/ldapS) => permit dans ce cas là .
ce qui m'etonne c'est que depuis le meme remote host (VPS chez OVH) un acces
ldapS tcp:636 fonctionne !? ceci vers le meme domain / subnet IP qui subit les
meme regle cf [1]
j'ai ouvert un ticket chez OVH pour savoir s'il on mis en place des filtrages
"adaptatifs" sur le 443 qui pourraient ne pas aimer l'asymetrie, mais j'ai des
reponses a coté de la plaque
Avez vous idée du probleme ? du deja vécu ? des operateurs upstream pourraient
filtrer un retour asymetrique sur certains protocoles et pas d'autres, une
question de largeur de fenetre tcp ou de MTU ...? j'ai testé pas mal
d'hypotheses sans succes pour le moment .
Merci pour vos lumieres .
jehan
[1] depuis mon VPS OVH vers mon site academique:
$ openssl s_client -connect cas.mondomain.fr:443 -tls1_2 => OK plein de sites externe
en symetrique , sauf depuis OVH "NOK" quand il est asymetrique
$ openssl s_client -connect ldap.mondomain.fr:636 -tls1_2 => OK depuis
partout meme depuis mon client sur VPS OVH en retour asymetrique
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
