Carnet de maintenance on Mook’s Lab Chronicles

J’ai enfin activé Hyperscan sur mes deux OPNsense

Mon, 24 Aug 2026 15:20:00 +0200

Tout est parti d’un article publié sur le blog de Suricata : Faster Suricata startups with Hyperscan caching.

Le sujet était le cache MPM (Multi-Pattern Matching) introduit avec Suricata 8. Au lieu de recompiler toutes les bases de motifs Hyperscan à chaque démarrage ou rechargement des règles, Suricata peut les conserver sur disque et les réutiliser. L’article annonçait un temps de démarrage réduit jusqu’à 50 %.

En le lisant, je me suis surtout posé une question beaucoup plus basique : est-ce qu’Hyperscan tournait réellement sur mes firewalls ?

La réponse était non.

Suricata fonctionnait déjà sur mes deux OPNsense, les événements remontaient bien dans VictoriaLogs et mon cluster HA faisait son travail. Mais le moteur de recherche de motifs capable de profiter des instructions vectorielles du processeur n’était pas actif.

Le verrou ne se trouvait pas vraiment dans Suricata. Mes deux VM utilisaient encore le modèle de CPU générique kvm64, pratique pour la compatibilité, mais trop conservateur pour exposer les instructions que je voulais utiliser. Avant de jouer avec le cache, il fallait donc commencer par activer le moteur lui-même.

Donner le bon CPU virtuel à Suricata

J’ai passé fw-core-p1 et fw-core-p2 en x86-64-v3. FreeBSD voyait alors correctement AVX2, AES et FMA, et je pouvais enfin demander explicitement Hyperscan à Suricata :

1
2
3


cpu {
 type = "x86-64-v3"
}

1

opnsense_ids_mpm_algo: "hs"

Le hs sélectionne Hyperscan comme moteur MPM. C’est la partie de Suricata qui cherche plusieurs motifs à la fois dans le trafic et écarte rapidement les signatures qui ne peuvent pas correspondre. La documentation OPNsense le présente d’ailleurs comme le meilleur choix sur les plateformes compatibles.

Le changement posait tout de même une question importante : mes hôtes Proxmox mélangent des processeurs Intel et AMD. J’ai donc fait migrer une VM de test d’Intel vers AMD, puis de nouveau vers Intel, avant de considérer x86-64-v3 comme un socle suffisamment portable chez moi.

Je n’ai pas touché aux règles de placement HA. Les deux firewalls restent volontairement séparés sur deux hôtes différents.

Le test qui comptait vraiment

Voir mpm-algo = hs sur les deux nœuds était une bonne nouvelle, mais cela ne disait encore rien sur le comportement du cluster pendant une vraie bascule.

J’ai donc laissé p2 reprendre les neuf VIP CARP. Pendant qu’il était MASTER avec Hyperscan actif, la sortie Internet continuait de fonctionner. Je n’ai observé aucune perte de paquets pendant le failover, avec une latence maximale de 13 ms.

Après le test, la situation normale était revenue : p1 MASTER, p2 BACKUP et neuf VIP au bon endroit. Le moteur de détection avait changé sans perturber le cluster.

Seize heures plus tard

Le premier contrôle montrait déjà Suricata autour de 356 à 359 Mio de mémoire, contre environ 548 Mio auparavant. J’ai laissé tourner avant de regarder de nouveau les compteurs.

Mesure	Après environ 16 heures
CPU Suricata	0 à 0,1 % sur les deux nœuds
Mémoire sur P1	233 Mio, soit −57,5 % par rapport au repère de 548 Mio
Mémoire sur P2	356 Mio, stable depuis le premier contrôle
Capture sur P1	51 044 239 paquets, 4 669 drops, soit 0,0091 %
Capture sur P2	1 078 301 paquets, aucun drop
Événements TLS	22 056 événements centralisés dans VictoriaLogs

Les 4 669 drops de capture observés sur p1 n’avaient pas augmenté depuis plus de deux heures lors du dernier relevé. Aucun drop Suricata n’apparaissait dans les échantillons contrôlés et la qualité de capture restait supérieure à 99,99 %.

Surtout, l’enrichissement n’avait pas disparu au passage : 926 SNI, 370 empreintes JA4, 55 empreintes de certificats et 23 émetteurs distincts remontaient toujours dans VictoriaLogs.

Ce n’est pas un benchmark. p1 et p2 n’ont ni le même rôle ni le même volume de trafic, et je ne vais pas attribuer toute la baisse à une seule option. La tendance observée reste néanmoins assez nette : CPU négligeable, mémoire en baisse et aucune dégradation visible de la détection ou du failover.

La configuration est maintenant décrite dans Terraform et Ansible. Le plan Terraform ne montrait aucun drift, le second passage Ansible terminait avec changed=0, et les sept tests du rôle passaient avec le syntax-check et ansible-lint.

Assez ironiquement, un article consacré au cache m’aura d’abord fait découvrir que je n’utilisais même pas le moteur. Le cache pourra venir ensuite. Pour l’instant, Hyperscan tourne enfin sur mes deux firewalls — et c’était déjà le vrai chantier.

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.