+1
Mettre des pare-feux à faire du BGP au cul de la DFZ, c'est pas parce
que ça marche qu'il faut le faire.
Déjà un routeur dispose d'optimisations de routages, de protocoles qui
sont propres aux besoins ISP, et qu'un pare-feu n'est qu'une patate sous
stéroïde qui n'a que très rarement de packet processor hardware, du coup
qui doit gérer une full en soft, bon. là où un routeur est une autre
patate mais qui traite les paquets sur asic dédiés (sauf MikroT... ahem)
Enfin un pare-feu c'est pas mal bruyant sur le réseau, rien que les
patchs et mises à jour.
Je parle même pas de la logique de venir autoriser le trafic asymétrique
sur une pare-feu ? Cela vient casser toute la logique de la coupure et
du maintien TCP safe...
Nicolas
On 3/7/26 16:24, David Ponzone via frnog wrote:
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/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
