CARP on Mook’s Lab Chronicles

Je voulais juste mettre à jour mes OPNsense

Sat, 15 Aug 2026 20:00:00 +0200

J’étais parti pour une petite révision tranquille de mes deux OPNsense. Une sauvegarde, une mise à jour du premier firewall, quelques contrôles, puis la même chose sur le second.

Le premier venait de terminer. J’ai lancé la mise à jour du second, puis contrôlé l’état du cluster pendant qu’elle avançait.

Un cluster qui fonctionnait… presque

Mon réseau repose sur deux firewalls, fw-core-p1 et fw-core-p2, avec neuf adresses IP virtuelles CARP. En temps normal, p1 porte les neuf VIP et p2 attend sagement en secours.

Après la mise à jour du premier nœud, l’état était un peu plus créatif :

1
2


8 VIP : p1 BACKUP / p2 MASTER
VIP LAN : p1 MASTER / p2 MASTER

Le réseau fonctionnait encore. Les interfaces répondaient, pfsync synchronisait toujours les connexions et rien ne semblait cassé à la maison. Mais la VIP du LAN était portée par les deux firewalls en même temps.

C’était le genre de problème assez discret pour passer inaperçu, jusqu’au jour où il décide de ne plus l’être.

Je n’ai rien tenté au milieu de l’opération. p1 a repris les neuf VIP avant le redémarrage du second, puis j’ai simplement surveillé le trafic jusqu’à son retour. Quelques minutes plus tard, les deux nœuds étaient bien en OPNsense 26.7.2_2 sur FreeBSD 15.1 et tous les services répondaient.

La mise à jour était terminée. Restait à comprendre ce petit double-MASTER.

P2 discutait avec lui-même

Le CARP du LAN utilisait l’unicast. Chaque firewall devait envoyer ses annonces directement à l’adresse réelle de l’autre :

1
2


P1 devait cibler 10.0.0.3
P2 devait cibler 10.0.0.2

Dans la configuration réelle, les deux ciblaient 10.0.0.3.

Pour p1, c’était correct. Pour p2, beaucoup moins : il envoyait ses annonces CARP à sa propre adresse.

Le plus amusant, c’est que la synchronisation HA faisait exactement ce que je lui demandais. p1 copiait sa configuration vers p2, y compris ce pair unicast qui aurait justement dû être différent sur chaque machine. Corriger uniquement le second nœud n’aurait servi à rien : la synchronisation suivante aurait remis la mauvaise valeur.

Mes huit autres VIP fonctionnaient déjà avec le multicast CARP classique. J’ai donc vérifié que les annonces envoyées vers 224.0.0.18 traversaient bien le bridge Proxmox et arrivaient sur p2. C’était le cas.

J’ai supprimé le pair unicast du LAN et laissé CARP revenir à son fonctionnement normal :

1
2
3


P1 ─┐
 ├── 224.0.0.18
P2 ─┘

Cette fois, les deux firewalls pouvaient partager exactement la même configuration sans que l’un d’eux finisse par se parler à lui-même.

Le petit test qui évite les grandes suppositions

Une fois la correction appliquée, j’ai placé p1 en maintenance. p2 a repris les neuf VIP, le DNS a continué de répondre et mes routes applicatives sont restées accessibles. En quittant le mode maintenance, p1 est redevenu MASTER par préemption et p2 est retourné en BACKUP.

1
2
3
4


fw-core-p1 : MASTER 9/9
fw-core-p2 : BACKUP 9/9
demotion : 0
pfsync : synchronisé

Au final, la mise à jour vers la série OPNsense 26.7 s’est passée sans incident. Elle m’a surtout donné une bonne excuse pour regarder un peu plus loin que le voyant vert.

Je voulais faire une petite révision. J’ai retiré une adresse dans un champ, relancé un vrai failover et mon cluster est maintenant plus simple qu’avant.

C’est déjà pas mal pour une matinée de maintenance.

J’ai doublé mon firewall pour pouvoir en éteindre un

Tue, 31 Mar 2026 00:00:00 +0000

Mon premier OPNsense fonctionnait très bien. C’était justement le problème.

Tout le cœur du réseau reposait sur fw-core-p1 : le LAN, huit VLANs, l’accès Internet et les routes entre mes différentes zones. Tant que la VM tournait, je n’avais aucune raison d’y penser. Dès qu’une mise à jour demandait un redémarrage, la question revenait : qu’est-ce qui reste accessible si ce firewall s’arrête ?

Pas grand-chose.

Je ne cherchais pas à transformer mon homelab en infrastructure bancaire. Je voulais simplement pouvoir maintenir un firewall sans couper volontairement tout ce qui passait derrière lui. C’est comme ça que fw-core-p2 est arrivé.

Une seconde VM ne fait pas encore un cluster

Le plus facile aurait été de cloner fw-core-p1, de démarrer la copie et d’appeler ça de la haute disponibilité. Deux firewalls mal coordonnés savent surtout produire deux fois plus de problèmes.

J’ai donc commencé par leur donner la même forme. Les deux VM vivent sur deux nœuds Proxmox différents et possèdent exactement le même ordre d’interfaces : le WAN, le LAN, les huit VLANs du homelab, puis une dernière interface réservée à la synchronisation.

1
2
3
4
5
6


pve-forum pve-fuji
fw-core-p1 fw-core-p2
 MASTER ─── VLAN 999 SYNC ─── BACKUP
 │ pfsync │
 │ XML-RPC │
 └────── 9 VIP CARP partagées ──┘

Cette symétrie n’est pas seulement jolie dans Terraform. pfsync associe les états aux interfaces : si leur ordre ou leur nom diffère entre les deux machines, la réplication ne raconte plus la même histoire des deux côtés.

CARP, pfsync et XML-RPC ne font pas le même travail

J’avais tendance à ranger tout cela dans la boîte « HA ». En pratique, trois mécanismes distincts coopèrent.

CARP (Common Address Redundancy Protocol) détermine quel firewall porte les adresses IP virtuelles. Les machines du réseau utilisent ces VIP comme passerelles et n’ont pas besoin de savoir si p1 ou p2 répond derrière.

pfsync réplique la table d’états. Quand p2 reprend le trafic, il connaît déjà les connexions suivies par p1 au lieu de repartir avec une feuille blanche.

XML-RPC synchronise la configuration depuis le primaire : règles, alias, NAT et objets partagés. Le second nœud reste ainsi un vrai pair, pas une vieille copie que j’espère encore correcte six mois plus tard.

La documentation HA d’OPNsense recommande justement une interface dédiée à pfsync. J’ai appliqué ce principe avec le VLAN 999, utilisé également pour la synchronisation de configuration.

Dans Terraform, ce choix tient dans quelques lignes :

1
2
3
4
5
6


# vtnet10 -> SYNC (pfsync + xmlrpc HA)
network_device {
 bridge = var.fw_core_lan_bridge
 vlan_id = var.fw_core_sync_vlan
 model = "virtio"
}

Ce petit vtnet10 est pourtant l’une des pièces les plus importantes du montage. Le trafic utilisateur et les échanges qui permettent au cluster de rester cohérent ne se disputent pas la même interface logique.

Le moment où neuf VIP ont changé de côté

Une interface verte dans OPNsense ne prouve pas grand-chose. Le cluster est devenu réel le jour où j’ai placé fw-core-p1 en maintenance et regardé fw-core-p2 reprendre les neuf VIP.

1
2
3


fw-core-p1 : BACKUP
fw-core-p2 : MASTER
VIP CARP : 9/9 sur p2

Le DNS continuait de répondre et mes routes applicatives restaient accessibles. En quittant le mode maintenance, p1 a repris son rôle par préemption et p2 est retourné attendre en secours.

C’est un test très simple, mais il change complètement la confiance que j’accorde au montage. Avant lui, j’avais deux VM configurées pour faire du CARP. Après lui, j’avais un cluster que je pouvais réellement utiliser pendant une intervention.

La haute disponibilité synchronise aussi les erreurs

Le piège le plus intéressant est arrivé plus tard. Une VIP utilisait un pair CARP unicast propre à p1. XML-RPC a parfaitement synchronisé cette valeur vers p2, qui s’est alors mis à envoyer ses annonces… à sa propre adresse.

La synchronisation n’était pas cassée. Elle exécutait fidèlement une configuration qui n’aurait pas dû être identique sur les deux nœuds.

J’ai raconté cette petite surprise dans ma révision du cluster OPNsense. Elle m’a rappelé qu’un cluster ne rend pas une configuration correcte par magie. Il propage aussi très efficacement les mauvaises idées.

Le retour au multicast CARP a supprimé cette exception locale et rendu les deux configurations réellement partageables. Depuis, mon test ne consiste plus seulement à vérifier que les deux firewalls affichent du vert : je provoque la bascule et je contrôle ce qui continue à fonctionner.

Ce que ce second firewall a réellement changé

Je n’ai pas supprimé tous les points de panne. Les deux VM dépendent toujours du réseau physique, des bridges Proxmox et de ce qui se trouve en amont. La haute disponibilité du firewall ne rend pas magiquement le reste du homelab redondant.

Elle a en revanche retiré un blocage très concret : je peux éteindre un OPNsense sans considérer la coupure comme une étape normale de la maintenance.

Le bénéfice n’est pas spectaculaire quand tout va bien. fw-core-p2 passe l’essentiel de son temps en BACKUP, ce qui est exactement ce que je lui demande. Sa valeur apparaît quand je mets à jour p1, quand je redémarre une VM ou quand je veux vérifier une modification sans jouer toute la connectivité du homelab sur un seul clic.

Au fond, j’ai doublé mon firewall pour pouvoir enfin en éteindre un sereinement. C’était tout le projet.