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

oui c'est finalement bien ça, désolé pour le bruit, j'etais persuadé 
d'un filtrage outPut ou upstream, mais finalement c'est mon stateFull 
firewall (ZBF) en IN ISP1 qui cassait la sessions car il n'avait pas 
tout vu passer :-( . je n'avais pas le pb avant car mon trafic 
engineering etait tres symetrique, ce n'est que dernierement 
qu'apparement de nouvelles annonces et/ou Local-pref / AS-PATH lenght 
ont priorisés en l'occurrence ici des subnets OVH via ISP2 .

pour les details de l'analyse,  c'est donc mon Cisco ZBF qui ne laissait 
pas passer le ACK (3) du client OVH sachant qu'il n'avait pas vu le 
Syn-ACK (2)  préalable repasser par lui en retour  et ainsi n'a pu 
completer la session 3-way Handshake afin de remplir correctement sa 
table des sessions ouvertes

schema d'architecture:

Client OVH-> ISP1 -> Cisco ZBF -> Server443
Server443 -> ISP2 -> Internet -> Client OVH

du coup quand le Cisco (edge1/ISP1) ZBF voit le ACK depuis le client OVH 
se pointer suivit du  ClientHello (TLS) , il drop les 2 et cela plante 
l'ensemble.

J'ai refais les captures avec Tshark, en effet c'est plus lisible , la 
capture Client montre bien un debut de 3-way HandShake correcte (donc le 
Sync-Ack (2) est bien revenu, mais par ISP2 (FranceIX))

1) SYN ->
2) <- SYN-ACK
3) ACK ->
4) ClientHello TLS ->
5) (retransmissions)

Coté serveur 1 & 2 se passent bien, mais le 3) ACK n'arrive pas

1) SYN ->
2) <- SYN-ACK
(no ACK received)

d'où ses retransmissions sucessives

1 SYN
2 SYN ACK
3 SYN ACK retransmission
4 SYN ACK retransmission
5 SYN ACK retransmission

le fautif, cisco ZBF avec cette config

policy-map type inspect isp1-IN
  class type inspect basic-services-cm
*inspect*

class-map type inspect match-any basic-services-cm
  match protocol https

et il n'etait pas listé un protocol ldapS, d'où l'explication que cela 
marchait bien avec ce dernier malgre l'asymetrie .

une solution consiste a passer la policy-map en Pass plutot que Inspect 
, en effet cela marche, je me prive de stafull et un-sollitated packets 
et des verifications strictes des TCP flags, mais j'assure une asymetrie 
et donc un trafic engineering en adequation avec les best PAth de mon 
multi-home , compromi a faire sinon mieux ?

Merci

On 3/7/26 15:15, Paul Rolland (ポール・ロラン) wrote:
> Hello,
>
> On Sat, 7 Mar 2026 00:32:05 +0100
> jehan procaccia INT via frnog<[email protected]> wrote:
>
>> ok j'ai descendu a une mtu 1260 , tj meme symptome
>> qq'un d'autre ma repondu de verifier en mettant une route statique en
>> retour Symetrique via REnater, deja fait
>> et oui là cela marche ... d'où mon doute sur l'asymetrie
>> je vais essayer de mettre en place une capture en sortie de mon routeur
>> edge2 (frontal FranceIX) et du core interne pour voir si ce ne serait
>> pas lui qui casse qq chose, mais c'est jamais facile a faire .
>>
>> je ferais aussi du tshark + pcap pour completer comme le suggere David
> Meme si ca reste difficilement compatible avec ton test ldaps qui marche,
> on dirait quand meme un probleme de firewall stateful... un qui voit passer
> le SYN sortant, et prepare la session, et le second qui voit revenir un
> SYN+ACK pour lequel il n'a aucune info, et le bloque alors.
>
> Mais il faudrait plus d'infos sur tes archis cote client/serveur pour aller
> plus loin dans l'analyse.
>
> Paul
>
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/