Migration d'un cluster HA pfSense V2.1 : échec de restore complet



  • Bonjour à toutes et à tous,

    Avant tout, descriptif de l'environnement :
    ### CONTEXTE ###

    • Milieu Pro

    ### MATERIEL ###

    • Cluster HA CARP/VIP

    • Deux unités rigoureusement identiques (https://www.osnet.eu/fr/shop/appliances/firewall-fwa-3025)

    • Un lien LAN, WAN et OPT1 par firewall,

    • Lien dédié PFSYNC sur OPT1

    • CARP et VIP sur l'interface LAN, ainsi que WAN

    • pfSense V2.1-RELEASE (amd64)
      built on Wed Sep 11 18:17:48 EDT 2013
      FreeBSD 8.3-RELEASE-p11

    Le cluster est opérationnel : il bascule de l'un à l'autre si perte d'un des membre.

    • Packages installés :
      cron, mailreport, ntop, OpenVPN export utility, pfblocker.

    ### OBJECTIF A ATTEINDRE ###

    • Sauvegarde de la configuration actuelle V2.1,
    • Restore de la configuration actuelle sur une autre machine installé en pfSense V2.1 (PC type amd64, même nombre de cartes réseau : 4)
    • Mise à jour des unités en production
    • Tests complets
    • Mise en production du cluster HA migré en dernière version

    Bien évidemment :

    • Besoin de migrer le VPN IPSec et OpenVPN (donc les Utilisateurs et Certificats)

    ### PROBLÈMES RENCONTRÉS ###

    • La restore (ALL AREA) du backup sur la 3eme unité n'aboutit pas à un état démarrable du firewall (lors de l'import, la réaffectation des cartes réseau est bien demandée et semble s'appliquer => via la console, les adresses IP sont bien affectées et correctement adressées à chaque interface physique).

    Voici une copie d'écran consécutif au reboot : le firewall ne boote plus :-(

    ### CONSTATATIONS ###

    • Un import unitaire de backup (interfaces, rules, Masquerade, etc…) ne pose pas de soucis, mais suite à l'import du backup filter-config, les OpenVPN ne sont pas repris

    ### ACTIONS ENVISAGEABLES ###

    • Se reprendre tout from scratch :-(
    • Refaire les imports un par un, et observer à chaque reboot => nécessiter de réinstaller pfSense lors du crash.

    Qui d'entre vous a déjà eu ce genre de soucis ?
    Si oui, par quels moyens avez vous rectifié les erreurs ?

    Merci d'avance pour votre aide et vos avis.

    Cordialement.



  • Salut salut

    J'ai monté un cluster avec deux machines identiques.
    J'ai eu le soucis avec une des deux machines ;

    • j'ai du faire une install par 0.
    • faire le paramétrage par défault en premier lieu
    • ajouter les addons ensuite avec ajouter les back up des conf.

    c'est qu'ensuite que le cluster après une xième synchro et reboot que le cluster fut opérationnel.
    c'est ensuite après le passage vers la v2.3 que cela se faire presque tout seul, sauf pour la v2.3.2_1 que j'ai du relance plus de 10/15 fois avant d'avoir un update fonctionnelle.

    J'ai peu être eu de la chance mais c'est la seule grosse tuile que j'ai eu coté de update, je ne parle pas des problèmes matériel.
    Donc sur deux machines je n'ai eu qu'a reposer intégralement l'une d'elle par chance l'esclave.

    Ne pas oublier que l'ajout/réintégration de fichiers de conf nécessite un reboot machine après.
    Ont-ils été fait ?

    Vous etes sur un passage de v2.1 à v2.3, il est important de passer par la v2.2 avant, c'est presque un passage incontournable si l'on ne veut pas se taper une full réinstallation.
    Le pourquoi est le changement de paramètre d'option dans les xml de conf.
    Depuis il y a un roolback auto si cela plante sur ce type d'opération.

    Vous avez deux options

    • update de la 2.1 a 2.3 via 2.2, attention ne pas oublier que les addon ne sont pas forcément exportable / réimportable non plus en fonction des versions.
    • un full install 2.3.2-1 avec repose des addons un par un.

    Cordialement.



  • @Tatave:

    Ne pas oublier que l'ajout/réintégration de fichiers de conf nécessite un reboot machine après.
    Ont-ils été fait ?

    Oui, a chaque import, reboot du PC.

    J'ai avancé sur le sujet (du PC à restorer avec la config V2.1).

    1 - Install en V2.1 sur le PC
    2 - Import Interfaces / Users / Certificates (CA - et CERT) / Aliases / Filter rules / NAT / IPSec / OpenVPN(reboot à chaque fois)
    3 - Mise à jour en V 2.3.2
    4 - Reboot = échec

    => Full install 2.3, puis restore sur le PC des configs un par un…

    Ma crainte est donc qu'un plantage survienne lors des MàJ des appliances FWA-3020 => un seul sera migré (le 2eme) dans un premier temps, après avoir rompu le HA/pfSync.



  • salut salut

    et faire une copie du hdd de la machine vers l'autre ? et rajout des params de la première ?
    J'en conviens cela n'est pas très orthodoxe mais bon a tenter.
    autre idée, switcher les hdd entre les machine et voir si avec le hdd de l'autre la machine remonte bien, apres cela pourra etre une piste pour mettre hors de cause la mise a jour ou le hdd, les reste malheureusement cela risque d'etre plus tendu.

    ++



  • @Tatave:

    salut salut

    et faire une copie du hdd de la machine vers l'autre ? et rajout des params de la première ?
    J'en conviens cela n'est pas très orthodoxe mais bon a tenter.
    autre idée, switcher les hdd entre les machine et voir si avec le hdd de l'autre la machine remonte bien, apres cela pourra etre une piste pour mettre hors de cause la mise a jour ou le hdd, les reste malheureusement cela risque d'etre plus tendu.

    ++

    Bonjour Tatave,

    Dans mon cas, il n’était pas possible de faire un transfert de HDD : PC d'un côté, boitier Altix de l'autre ;-)

    J'ai avancé sur le point de préparation d'un environnement de secours : à ce jour, j'ai un cluster HA (PC + Altix), qui servira d’environnement ponctuel lors de la migration des aplliances FWA-3020.

    Merci pour vos réponses !



  • Pour un simple test, la semaine passée, j'ai installé une version 2.1 sur une carte flash et je démarre sans problème sur un Watchguard. La tentative de mise à jour vers la dernière version se solde aussi par un échec et le watchguard ne boot pas sur la nouvelle version.
    L’objectif était de vérifier la faisabilité de ce type de mise à jour, sur des équipements hors production.
    J'ai prévu, lorsque j'en aurait le temps un nouveau test en passant par les versions successives, ce que je fais habituellement (et avec des précautions décrites dans un message plus ancien).
    Je confirme que cla mise à jour directe de 2.1.5 vers 2.2.3 semble problématique.



  • @ccnet:

    Je confirme que cla mise à jour directe de 2.1.5 vers 2.2.3 semble problématique.

    Merci ccnet pour cette précision  ;)



  • @Tatave:

    salut salut

    et faire une copie du hdd de la machine vers l'autre ? et rajout des params de la première ?
    J'en conviens cela n'est pas très orthodoxe mais bon a tenter.
    autre idée, switcher les hdd entre les machine et voir si avec le hdd de l'autre la machine remonte bien, après cela pourra être une piste pour mettre hors de cause la mise a jour ou le hdd, les reste malheureusement cela risque d'etre plus tendu.

    ++

    Une autre technique serait de refaire une installe propre, de configurer les bases manuellement (interfaces, packages, etc) d'exporter la configuration, et de les fusionnez manuellement via un editeur de texte, section par section, puis de réimporter la config fusionner qui ne contiendra que les règles, CA, USER, OPENVPN, etc …
    C'est ce que j'avais fait quand je suis passé d'un Lanner LEC-2126 à nos OSnet FWA-7010, si tu le fait en prenant ton temps, ce sera nickel.

    Cordialement.