Lu, Concernant la gamme ASA faut admettre que ça reste de bon produit, ayant déjà mis en œuvre plusieurs solution en FailOver (5510 et 5520) je n’ai pour le moment pas rencontré de problème majeur avec ce produit. Celui-ci est relativement stable, cependant attention au version du système d’exploitation, les toutes dernières versions offrent comme d’hab de nouvelles fonctionnalités mais ne garantissent pas une stabilité exemplaire (ceci n’est pas vrai dans tous les cas et heureusement).
Pense également que en terme de débit annoncé par le constructeur le 5520, c’est environ 450 Mbps de throughtpout sur l’ensemble des interfaces , cette valeur est basé sur un mode de calcul en IMIX. Concernant le FailOver, l’ASA 5520 gère deux mode, le premier actif – actif en statefull et le second actif passif également en statefull. Concernant la gestion des ACL, bien que l’ASDM soit une interface graphique assez ergonomique et très complète (ça ne vaut pas un checkpoint de ce coté), je ne suis pas un adepte de l’interface (bug potentiel etc … comme pour beaucoup d’interface GUI) . Il m’arrive de l’utiliser pour le debug via l’interface graphique. Une gestion des ACL via un bon vieux fichier texte reste l’idéal à condition qu’une nomenclature simple et cohérente soit déterminé à la base, surtout si l’utilisation d’objet est effectuée. Concernant la création d’access-list via l’ASDM avec l’intégration des objets, ceci doit se faire de manière organisé au risque de tombé sur un méchant bordel avec des objets génériques qui ont des noms qui ressemblent à rien. Exemple : object-group network DM_INLINE_NETWORK_2 (objet créé dynamiquement par l’ASDM, pas très propre) network-object host 192.X.X.X network-object host 192.X.X.X network-object lan 255.255.255.0 network-object 192. .X.X.X 255.255.255.0 ce qui donne dans l’access-list access-list INTERCO_backbone_nat0_outbound extended permit ip object-group DM_INLINE_NETWORK_2 object-group DM_INLINE_NETWORK_5 donc la lecture pas top !!! surtout quand tu commence à atteindre la centaine d’ACL voir plus, ça peut devenir une sacrée galère. L’idéal est de créer ces propres objets et ces propres groupes d’objets (logique !!!) et par la même occasion lors de leurs applications dans les ACL nommer les ACL et du coup la lecture est bien plus aisé. Si tu as des questions hésite pas Qu’est ce qui justifie le choix d’un 5520 plutôt qu’un 5510 ou 5540 par exemple ?? @+ PS : pour le scripting tu peux utiliser le generateur de conf « confterm » super pratique « http://www.fcug.fr/confterm-la-version-6-8 » -----Message d'origine----- De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de Romain LE DISEZ Envoyé : mercredi 29 juillet 2009 15:37 À : frnog@FRnOG.org Objet : [FRnOG] Administration de pare-feu Cisco ASA 5520 Salut à tous, nous sommes en train de terminer le déploiement de deux pare-feu Cisco ASA 5520. Notre architecture étant redondante, ils doivent avoir tous les deux les même règles de filtrage afin que la reprise en cas de panne se passe bien. Nous utilisions auparavant des OpenBSD avec pf. Avec un petit make et quelques commandes (SCP, pfctl), nous pouvions facilement répliquer la configuration. Nous cherchons le moyen d'avoir un fonctionnement similaire avec les Cisco. Par exemple, un fichier texte de ce type : <adresse ip> <group> qui nous permette, en une commande, de construire les groupes (auxquels nous appliquons les ACL) et de les pousser sur les deux pare-feu. Avant que l'on commence à scripter, connaissez vous une solution de ce type ? Comment faites vous pour bien gérer vos ASA ? Merci. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
