Mettre les firewall plus « south » , et donc pas directement derrière les transits ?
David > Le 7 mars 2026 à 16:15, jehan procaccia INT via frnog <[email protected]> a > écrit : > > 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/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
