Migrer d'un Netgate 3100 vers un cluster OPNsense en haute disponibilité

Le Netgate 3100 a longtemps été mon pare-feu principal, déjà déployé en haute disponibilité — deux appliances en cluster CARP, ce n'est donc pas la HA en elle-même qui posait problème. Le déclencheur a été le modèle de licence de pfSense Plus : passé environ un an d'utilisation, Netgate impose un abonnement payant pour continuer à l'utiliser dans de bonnes conditions (mises à jour, support), un coût récurrent qui double mécaniquement puisque chaque nœud du cluster doit être couvert. Plutôt que de payer indéfiniment cet abonnement, j'ai basculé vers OPNsense, en conservant l'architecture en cluster haute disponibilité. Voici le retour d'expérience complet : pourquoi ce choix, comment la migration s'est déroulée, et surtout ce que ça apporte concrètement en sécurité.

Illustration : badges stylisés aux couleurs des deux projets (pas les logos officiels).

1. Pourquoi quitter le Netgate 3100

Le matériel en lui-même n'était pas le problème — les deux appliances ont tourné plusieurs années sans le moindre souci matériel. Les raisons du changement sont ailleurs :

• Coût récurrent obligatoire : au-delà de la période initiale, pfSense Plus nécessite un abonnement payant (support TAC) pour rester à jour et supporté dans de bonnes conditions — facturé par appliance, donc doublé pour un cluster HA de deux nœuds.
• Dépendance matérielle : pfSense Plus n'est officiellement supporté que sur du matériel Netgate (ou avec des limitations sur du matériel tiers), ce qui verrouille les évolutions futures de l'infra et lie le coût de la licence à celui du matériel.
• Envie de repasser sur une solution 100% ouverte : pas de distinction entre une édition gratuite et une édition payante pour les correctifs de sécurité, pas de renouvellement à surveiller chaque année.

2. Pourquoi OPNsense plutôt qu'un autre pfSense

OPNsense est un fork de pfSense (lui-même dérivé de m0n0wall), maintenu par Deciso, avec un modèle de développement resté entièrement ouvert et un cycle de publication très régulier (deux versions majeures par an, publiées avec un changelog de sécurité détaillé). Plusieurs points ont pesé dans le choix, au-delà de la simple gratuité :

• Rythme de correctifs plus rapide et transparent : les CVE affectant les composants embarqués (OpenSSL, Unbound, PHP, le noyau) sont patchées et publiées sans distinction entre une édition "gratuite" et une édition "payante" — tout le monde reçoit les mêmes correctifs, en même temps.
• Authentification renforcée sur l'interface d'administration : 2FA (TOTP) natif pour l'accès au back-office, sans plugin tiers à installer.
• IDS/IPS Suricata intégré nativement, avec des règles ET Open / Emerging Threats et une interface de gestion des règles beaucoup plus lisible que l'équivalent pfSense (Snort en add-on payant pour les règles VRT à jour).
• Zenarmor (ex-Sensei) disponible en plugin pour de l'inspection applicative L7 et du filtrage par catégorie, utile pour du contrôle parental ou de la visibilité applicative fine.
• Unbound DNS avec listes de blocage intégrées pour bloquer les domaines de phishing/malware/pub directement au niveau résolution DNS, sans device supplémentaire.
• WireGuard et OpenVPN natifs, sans dépendre de paquets tiers moins bien maintenus.
• Base FreeBSD durcie et surface d'attaque de l'interface web réduite (framework Phalcon, séparation plus stricte entre logique métier et présentation) par rapport à l'ancienne base pfSense.

3. Conserver la haute disponibilité : le principe CARP + pfsync

Bonne nouvelle pour qui vient de pfSense : le mécanisme de HA est exactement le même sous OPNsense, les deux partageant la même généalogie. Pas besoin de repartir de zéro sur l'architecture, seulement de la recréer sur les nouveaux boîtiers : CARP (Common Address Redundancy Protocol) pour la bascule d'adresse IP entre les deux nœuds, et pfsync pour la synchronisation en temps réel des tables d'états entre les deux pare-feu.

• CARP : chaque interface "publique" (WAN, LAN, DMZ...) reçoit une IP virtuelle (VIP) partagée par les deux nœuds. Le nœud maître répond normalement au trafic ; en cas de panne (perte de lien, crash, reboot), le nœud secondaire prend automatiquement la main sur la VIP en quelques secondes.
• pfsync : dédié à la réplication en temps réel des tables d'états (connexions actives, sessions NAT, tables d'états du firewall). Sans ça, une bascule CARP couperait quand même toutes les connexions en cours au moment du failover.
• XMLRPC config sync : OPNsense permet de synchroniser automatiquement la configuration (règles de firewall, NAT, aliases, certificats...) du nœud maître vers le nœud secondaire, pour ne jamais avoir à répliquer un changement à la main sur les deux boîtiers.

4. Étapes de la migration

1. Choix du matériel : deux boîtiers identiques (mini-PC x86 avec au moins 3 interfaces réseau chacun : WAN, LAN, et le lien pfsync dédié), en remplacement des deux appliances Netgate 3100 existantes, pour conserver la même architecture en cluster.
2. Installation d'OPNsense sur les deux nœuds, configuration réseau de base identique (mêmes interfaces nommées de la même façon), sans encore activer CARP.
3. Configuration CARP : création des VIP sur chaque interface publique (une VIP par interface, avec un VHID unique par cluster si plusieurs clusters partagent le même segment réseau — sinon collision garantie).
4. Configuration pfsync sur l'interface dédiée entre les deux nœuds, puis activation de la synchronisation de configuration (XMLRPC) du maître vers le secondaire.
5. Migration des règles depuis l'export de configuration du Netgate 3100 (format XML compatible, avec quelques ajustements manuels sur les alias et les règles NAT spécifiques à pfSense Plus).
6. Bascule en parallèle : les deux clusters (ancien Netgate, nouveau cluster OPNsense) tournent en parallèle sur un port de test avant la bascule définitive du câblage WAN/LAN, pour valider le comportement sans risquer une coupure en pleine journée de travail.
7. Test de failover : débranchement volontaire du nœud maître pendant un transfert réseau actif pour valider que la bascule est réellement transparente (perte de quelques paquets tout au plus, pas de coupure de session).

# Vérifier l'état CARP depuis la ligne de commande (shell OPNsense)
$ ifconfig | grep carp

# Statut attendu sur le nœud maître : MASTER
# Statut attendu sur le nœud secondaire : BACKUP
# Après un failover volontaire, les rôles doivent s'inverser
# en quelques secondes, sans intervention manuelle.

5. Ce que la migration apporte concrètement en sécurité

La HA était déjà acquise depuis le Netgate — le vrai gain de cette migration est ailleurs : plusieurs mesures ont pu être activées à cette occasion, profitant des fonctionnalités natives d'OPNsense qui n'avaient pas d'équivalent aussi direct côté pfSense :

• Suricata en mode IPS (blocage actif) sur l'interface WAN, avec les règles Emerging Threats Open mises à jour automatiquement.
• 2FA TOTP obligatoire pour tout accès à l'interface d'administration, en plus de la restriction d'accès au LAN uniquement (l'interface web n'est jamais exposée sur le WAN).
• Mises à jour automatiques planifiées pendant une fenêtre de maintenance nocturne, avec bascule CARP transparente pendant le redémarrage du nœud en cours de mise à jour — un nœud reste toujours actif pendant que l'autre se met à jour et redémarre.
• Filtrage DNS via Unbound avec listes de blocage de domaines malveillants/phishing, appliqué à tout le réseau sans configuration côté poste client.
• Certificat TLS valide sur l'interface d'administration (remplaçant le certificat auto-signé par défaut), pour éliminer l'habitude dangereuse de cliquer sur des avertissements de sécurité navigateur.

La haute disponibilité n'est pas qu'une question de disponibilité au sens strict : un cluster permet aussi d'appliquer les mises à jour de sécurité sans jamais avoir de fenêtre de coupure — donc sans jamais être tenté de repousser un correctif critique parce que "ça coupera le réseau en pleine journée".

Conclusion

Migrer un cluster HA existant vers une autre plateforme demande une configuration soigneuse (CARP, pfsync, synchronisation de config) mais ne repart pas de zéro sur l'architecture — le concept reste le même, seul l'éditeur change. Le bénéfice principal n'est donc pas la haute disponibilité, déjà acquise avec les Netgate, mais l'affranchissement d'un abonnement payant récurrent et l'accès à des fonctionnalités de sécurité natives (IDS/IPS intégré, 2FA, DNS filtrant, mises à jour sans coupure) qui demandaient davantage d'efforts ou de coûts additionnels côté pfSense. Le résultat est un périmètre réseau au moins aussi résilient qu'avant, plus difficile à compromettre, et sans facture de licence à renouveler chaque année.