Outre le fait que modifier IPCOP peut-être une source d'instabilité, gérer un système qui concentre trop de fonctionnalités peut aussi devenir plus que génant quand il tombe en panne. Il faut définir un plan de secour à toute épreuve.
Personnellement
, je privilègierai la mise en place de plusieurs FW IPCOP (au prix d'un vieux PC PII ou PIII à chaque fois). Le plantage d'une machine affectera une partie limité des utilisateurs et/ou du système d'information. On aura pris le soin de préparer une machine de spare prête à recevoir la disquette de sauvegarde IPCOP pour redémarrer dans les meilleurs délais. Il est vrai qu'un outil de supervision
centralisé (Nagios???) de routeurs IPCOP évitant la connexion individuelle à chacun d'entre eux serait un plus et un moyen de voir plus ambitieux pour entrer dans les entreprises. Et puis après tout on est sûr qu'on limitera des excès de latence générer par la gestion des I/O sur une même machine, avec un kernel 2.4.
Cela dit ajouter des cartes réseaux supplémentaires manuellement ne doit pas être si complexes que cela, par contre toute la gestion via l'interface d'administration est proscrite tant qu'aucune adaptation des scripts perl et javascript n'est réalisée... a éviter!
. Ensuite les règles de filtrage peuvent être adaptés à sa sauce dans /etc/rc.d/rc.firewall.local. La maîtrise des iptables est nécessaire. Si on analyse ce que génère IPCOP à ce niveau c'est déjà impressionnant mais pas insurmontable.
Rester simple peut être la meilleure stratégie et les petits surcoûts compenseront la perte de temps imposée par la complexité.
Good luck!