⚠️ Disclaimer
Ce qui suit est un retour d’expérience personnel, pas une documentation de référence. J’apprends, je fais des erreurs, et j’essaie d’en tirer des leçons honnêtes.
J’ai publié une série d’articles sur la mise en place de cette segmentation : phases 1 à 3 côté pfSense et MikroTik, phases 4 et 5 pour Proxmox et le durcissement. Ici, c’est un bilan d’ensemble : ce qui tourne, ce qui a surpris, et ce qui reste sur la table.
Vue d’ensemble de l’architecture après segmentation : 5 VLANs actifs, pfSense en routeur/firewall, MikroTik CRS310 en switch de cœur, couches de sécurité superposées (Suricata IPS, pfBlockerNG, Wazuh SIEM).
Ce qui tourne en production
La segmentation est opérationnelle depuis début mars. Cinq VLANs actifs : LAN pour les machines de confiance, MGMT strictement isolé pour l’administration, LAB pour les VMs Proxmox, IoT pour les Ring et Netatmo, SERVICES pour le NAS. La DMZ (VLAN 99) est réservée pour plus tard.
Les règles firewall pfSense tournent avec des alias bien définis. C’est la décision d’architecture dont je suis le plus content. Quand je dois modifier quelque chose, je touche à l’alias, pas à chaque règle une par une. Et le DNS interne via Unbound rend les logs lisibles : proxmox-asus.homelab.local au lieu de 192.168.20.94 dans les alertes Wazuh, ça change la vie.
Suricata tourne en mode IPS sur le WAN. pfBlockerNG bloque en DNS les domaines pub, malware et tracking sur tous les VLANs. Wazuh ingère les logs de pfSense (syslog), du nœud Proxmox (agent) et du NAS Synology (syslog), avec 18 règles custom dont 12 taguées MITRE ATT&CK.
Ce qui a cassé : les vrais bugs
Le routage asymétrique sur le nœud Proxmox ASUS a été le plus vicieux. Symptôme : ping depuis pfSense OK, ping dans l’autre sens, timeout. La cause était un bridge vmbr2 fantôme d’un ancien projet qui avait une IP configurée (192.168.10.1), créant une route plus spécifique que la route par défaut. Les réponses partaient par le mauvais bridge. Deux heures de diagnostic avec ip route show et tcpdump, deux minutes de fix (iface vmbr2 inet manual).
Les fausses alertes Suricata, c’était impressionnant. Plus de cent mille alertes dans les premières heures. 94% venaient de deux règles liées au checksum offload, comportement normal sur certaines NICs mais que Suricata interprète comme suspect. Désactiver une dizaine de SIDs a suffi. Déployer un IPS sans calibrage préalable, c’est surtout se noyer dans du bruit.
Côté Wazuh, un bug non documenté dans la version 4.14.3 m’a coûté une demi-journée. Quand plusieurs child decoders PCRE2 partagent le même parent, l’échec du premier empêche les suivants d’être testés. La solution est de créer un parent par type de log. Rien de complexe, mais il faut le trouver.
Et la Vulnerability Detection qui ne remontait rien pendant deux semaines. Deux causes combinées : le bloc <indexer> dans ossec.conf pointait vers 0.0.0.0:9200 au lieu de l’IP réelle de la VM, et le wazuh-keystore n’avait jamais reçu les credentials pour le module indexer-connector. Une fois corrigé : 169 CVE détectées d’un coup, 17 critiques. apt upgrade dans la foulée.
La suite
Le projet n’est pas fini, et c’est ce que j’apprécie dans ce type d’infrastructure : il y a toujours une prochaine étape qui a du sens.
La priorité dès que Wazuh sera finalisé, c’est l’audit de sécurité. Tester la segmentation avec les outils qu’on utiliserait en pentest : Nmap, scans inter-VLAN, vérification des règles. On construit une architecture, on la met à l’épreuve. Pas l’inverse.
Ensuite, l’Active Response Wazuh pour bloquer automatiquement les IPs via pfctl sur pfSense quand une tentative de brute force est détectée. L’API REST de pfSense CE n’est pas disponible (feature payante), donc ce sera SSH avec clé dédiée et pfctl -t wazuh_blocked -T add. Du SOAR artisanal mais fonctionnel.
Les interfaces admin tournent encore avec des certificats auto-signés, donc la prochaine étape logique sera de déployer une PKI interne ou du Let’s Encrypt en DNS challenge. Pareil pour le 2FA : Proxmox, MikroTik et le NAS ont un TOTP natif, seul pfSense CE nécessiterait FreeRADIUS.
À plus long terme, j’aimerais aller vers un bastion d’accès, du SSO, la migration SFP+ 10G pour le trunk pfSense/MINIFORUM (deux câbles DAC à vingt euros, le trunk actuel plafonne à 2.5G), et Azure Arc sur les machines Linux pour tester Sentinel en parallèle de Wazuh.
C’est un projet que je vais laisser vivre au cours de l’année 2026. L’améliorer petit à petit, tester, casser, corriger, avancer.
Ce que j’en retiens
C’est probablement le projet le plus formateur que j’ai fait sur le homelab. On met vraiment les mains dedans. Le paramétrage des règles pfSense entre les VLANs, la configuration du bridge MikroTik, le debug de Wazuh ligne par ligne avec wazuh-logtest : c’est concret, et ça ne pardonne pas les approximations.
La première leçon, et elle est commune à tous les projets que j’ai pu faire : ça ne sert à rien de commencer tête baissée. Cartographier ce qu’on a, faire un état des lieux, planifier. Pour ce projet, l’audit initial du réseau a directement conditionné la qualité des règles firewall. Sans savoir précisément quels équipements parlent à quels autres, sur quels ports, les règles inter-VLAN auraient été bancales. Le bug de routage asymétrique sur Proxmox en est la preuve : si j’avais cartographié les bridges existants avant de migrer, j’aurais vu le vmbr2 fantôme tout de suite.
Il y a eu des moments de stress, aussi. L’activation du VLAN Filtering sur le MikroTik, par exemple. Même en ayant un plan de retour en arrière (export de la config initiale du switch, accès physique en secours), il y a ce moment où on appuie sur “Apply” et où on ne sait pas si on va garder la main sur l’équipement. Ça m’a appris à systématiser les backups de configuration et à toujours prévoir un plan B pour réaccéder à une interface d’administration. Exporter la config du switch et du routeur avant chaque modification, c’est un réflexe que j’ai maintenant.
Avec le recul, je retrouve quelque chose que j’ai connu en gestion de projet dans mes années en BI : on a beau tout planifier, il y aura toujours des imprévus. C’est une constante. Le bridge fantôme, le bug PCRE2 non documenté, les credentials oubliés dans le keystore Wazuh : rien de tout ça n’était prévisible. Ce qui compte, c’est de comprendre pourquoi c’est arrivé et de mettre en place un correctif pour que ça ne se reproduise pas. La méthode reste la même, que ce soit sur un reporting Power BI ou sur une segmentation réseau.
Ce qui est intéressant aussi, c’est que tout ce que j’ai monté ici se transpose directement en entreprise. J’ai une dizaine de machines, c’est de la virtualisation sur Proxmox, mais sur le principe, c’est exactement ce que mettrait en place une PME en termes d’architecture réseau segmentée, de supervision SIEM, de règles firewall. L’échelle change, pas la logique.
Configs pfSense, MikroTik et Wazuh disponibles sur GitHub (Kurgran). Les tutoriels détaillés de chaque phase sont référencés dans le README.