Créer tes VLAN dans OPNsense : la vraie segmentation (partie 2)

Ton OPNsense tourne, il est à jour, et si tu as suivi la partie 1 de cette série, tu as maintenant une carte en tête : plusieurs zones, un principe simple, par défaut personne ne parle à personne. Ce que tu n’as pas encore, c’est le réseau lui-même. Pour l’instant, cette carte n’existe que sur un schéma. On va la rendre réelle.

C’est le pas-à-pas que je t’avais promis dans la partie 1, quand je te disais que la configuration des VLAN viendrait plus tard. On y est. À la fin de cet article, tu auras découpé ton réseau plat en zones étanches, chacune avec sa propre plage d’adresses, et surtout tu sauras écrire les règles qui décident qui a le droit de parler à qui. Si OPNsense n’est pas encore installé chez toi, commence par l’article précédent : on y pose les fondations, WAN sur vmbr0, LAN sur vmbr1, sur lesquelles tout le reste s’appuie.

Parce que c’est là qu’est le vrai sujet, et autant le dire tout de suite : créer un VLAN dans OPNsense et lui coller une adresse, c’est une poignée de clics. Ça ne protège rien. Un VLAN tout seul, c’est juste un deuxième réseau vide à côté du premier. Ce qui cloisonne, ce qui fait le travail de sécurité, ce sont les règles de pare-feu que tu poses derrière. La partie 1 t’a donné la philosophie du refus par défaut ; ici, on l’écrit, ligne par ligne. C’est pourquoi on ira assez vite sur la création des VLAN, pour consacrer l’essentiel de l’article aux règles.

Un mot sur ce qu’on fait et ce qu’on ne fait pas. On reste côté OPNsense : créer les VLAN, leur donner une adresse, distribuer le DHCP, et poser les règles d’isolation. La configuration détaillée de ton switch manageable, elle, aura son propre article, parce qu’elle dépend de ta marque et qu’elle mérite mieux qu’un paragraphe expédié. Ici, tu auras juste le minimum pour faire fonctionner et tester un VLAN de bout en bout. Dernier point : ton OPNsense tourne en machine virtuelle sur Proxmox, avec deux cartes réseau physiques, une vers ta box (le WAN) et une vers ton switch (le LAN). Ça change quelque chose à la manière de faire circuler tes VLAN. On verra pourquoi le moment venu.

Le vocabulaire qui débloque tout

Avant de cliquer quoi que ce soit dans OPNsense, il faut lever un malentendu, parce que c’est lui qui coince tous les débutants. Un VLAN, ce n’est pas un câble. Ce n’est pas une carte réseau en plus, ni une prise dédiée. C’est une étiquette. Tes zones vont passer dans les mêmes câbles, sur le même switch, par la même carte réseau d’OPNsense. Ce qui les sépare, ce n’est pas le cuivre, c’est un label collé sur chaque paquet qui dit à quelle zone il appartient. Une fois que tu as ça en tête, tout le reste s’éclaire.

L’étiquette : le tag

Quand un appareil envoie des données, ça part sous forme de petites trames Ethernet. Un VLAN, techniquement, c’est juste un numéro (son identifiant, entre 1 et 4094) qu’on vient glisser dans chacune de ces trames. Une trame qui porte le 20 appartient au VLAN 20, une trame qui porte le 30 appartient au VLAN 30. Le switch et OPNsense lisent ce numéro et savent aussitôt dans quelle zone ranger le paquet. C’est tout. Une trame « taggée », c’est une trame qui porte son étiquette. Une trame « non taggée » (untagged), c’est une trame nue, sans numéro.

Qui colle l’étiquette : access et trunk

C’est la vraie question : qui écrit l’étiquette, et qui la lit.

Ton PC, ta TV, ta prise connectée ne savent rien des VLAN. Ils envoient des trames nues et se fichent complètement de la notion de zone. C’est normal et c’est voulu : tu ne vas pas configurer chaque appareil de la maison un par un. C’est le port du switch sur lequel ils sont branchés qui fait le travail à leur place. On appelle ça un port access : il est configuré pour une seule zone, il colle l’étiquette sur tout ce qui entre depuis l’appareil, et il la retire sur tout ce qui repart vers lui. L’appareil reste dans son ignorance tranquille, et il atterrit quand même dans la bonne zone. C’est exactement ce que la partie 1 décrivait : chaque machine atterrit dans sa zone selon le port qu’elle occupe.

Maintenant, le câble unique entre ton switch et OPNsense doit, lui, transporter toutes les zones à la fois. Impossible de le dédier à une seule. Ce câble, c’est un port trunk : il laisse passer plusieurs VLAN en même temps, tous taggés, chacun reconnaissable à son numéro. Et ça répond à une question que tu te poses peut-être depuis la partie 1 : comment une seule carte réseau LAN sur OPNsense peut servir plusieurs zones ? Parce que le trunk lui apporte toutes les zones, étiquetées, sur le même fil. OPNsense lit les étiquettes et traite chaque zone séparément.

Deux conséquences à garder en tête :

• Il te faut un switch manageable. Un switch bête ne sait ni lire ni écrire ces étiquettes : il laisse tout passer à plat, et ton cloisonnement n’existe pas. C’est le seul vrai achat que la segmentation impose, et il n’est pas négociable.

• Sur le trunk vers OPNsense, on ne mélange pas taggé et non taggé. Tout est taggé, sans exception. La documentation officielle d’OPNsense insiste là-dessus : un VLAN non taggé qui traîne sur ce trunk fait fuiter des paquets d’une zone à l’autre. On y reviendra dans l’article dédié au switch.

Le passage d’une zone à l’autre : l’inter-VLAN routing

Dernière brique, et c’est elle qui donne tout son sens à OPNsense. Chaque VLAN est un réseau séparé, avec sa propre plage d’adresses (le VLAN 20 en 192.168.20.x, le VLAN 30 en 192.168.30.x). Deux appareils dans le même VLAN se parlent directement via le switch, sans que personne d’autre ait son mot à dire. Mais dès qu’un paquet veut passer d’une zone à une autre, il doit être routé, et le seul appareil capable de faire ce passage est celui qui a un pied dans chaque zone : OPNsense. Il est la passerelle de tous tes VLAN.

C’est là que se joue toute la sécurité. Comme la totalité du trafic entre zones est obligée de passer par OPNsense, c’est le point de contrôle unique où tu poses tes règles. Autoriser Perso à joindre Jellyfin sur Serveurs, interdire à l’IoT de parler à quoi que ce soit : ça se décide là, et nulle part ailleurs. Garde juste une chose dans un coin de ta tête pour la suite : le trafic à l’intérieur d’un même VLAN, lui, ne passe pas par OPNsense. Donc il n’est pas filtrable. On verra ce que ça change quand on écrira les règles.

Pour rassembler tout ça en une seule image, voici le trajet complet d’une trame, de l’appareil jusqu’à OPNsense, avec l’étiquette qui apparaît sur le trunk :

Les deux prérequis avant de toucher à OPNsense

Avant de créer le moindre VLAN dans l’interface d’OPNsense, il y a deux choses à mettre en place en amont. La première, tu la connais déjà si tu as suivi la section précédente. La seconde, presque aucun tuto ne la mentionne, et c’est précisément elle qui fait que « j’ai tout bien configuré et rien ne marche ».

Le switch manageable

On l’a vu : sans switch capable de lire et écrire les étiquettes VLAN, il n’y a pas de segmentation possible. C’est le seul achat que cette démarche impose, et il n’est pas contournable. Un switch manageable correct pour un homelab, ça se trouve en occasion pour le prix d’une sortie resto.

Sa configuration détaillée (quel port dans quelle zone, le trunk vers OPNsense, le trunk vers ton point d’accès Wi-Fi) dépend entièrement de ta marque, et elle mérite mieux qu’un paragraphe bâclé. Elle aura donc son propre article. Pour aujourd’hui, retiens juste le rôle : le switch reçoit le trunk d’OPNsense avec toutes les zones taguées, et les redistribue port par port aux appareils, chacun détagué dans sa zone.

Le bridge Proxmox en VLAN-aware

Voilà l’étape oubliée, et c’est la plus importante de tout l’article côté Proxmox. Ton OPNsense n’est pas une boîte physique posée sur une étagère : il tourne en machine virtuelle. Souviens-toi de l’article d’installation : tu as deux cartes réseau physiques, une reliée à ta box sur le pont vmbr0 (le WAN), et une reliée à ton switch manageable sur le pont vmbr1 (le LAN). C’est cette seconde carte, celle branchée sur le switch, qui va apporter le trunk taggé.

Le problème, c’est le trajet du tag. Quand le switch envoie ses trames taguées, elles arrivent sur la carte physique, puis sur le pont vmbr1, puis seulement dans la VM OPNsense. Et un pont Proxmox ordinaire ne sait pas quoi faire d’une trame taguée : dans le doute, il l’ignore ou la détague. Résultat, tes étiquettes VLAN sont arrachées avant même d’atteindre OPNsense. Tu peux créer tous les VLAN que tu veux dans l’interface, ils ne recevront jamais le moindre paquet. Tout est juste, et rien ne fonctionne. C’est le genre de panne qui coûte une soirée entière, je te le garantis pour l’avoir vécu.

La solution tient en une case à cocher

Il faut dire à ce pont de laisser passer les trames taguées telles quelles, sans y toucher, jusqu’à la VM. Chez Proxmox, ça s’appelle rendre le pont VLAN-aware. Une fois coché, le pont se comporte en trunk transparent : il transporte toutes tes zones taguées jusqu’à OPNsense, qui se charge lui-même de les trier.

En pratique, deux réglages, et l’ordre compte :

• Sur le pont vmbr1 (celui qui porte la carte physique reliée à ton switch) : Datacenter → ton nœud → System → Network, tu sélectionnes vmbr1, tu cliques sur Edit, et tu coches VLAN aware. Tu appliques avec Apply Configuration.

• Sur l’interface réseau LAN de la VM OPNsense (celle sur vmbr1) : tu laisses le champ VLAN Tag sur « no VLAN ». C’est contre-intuitif, alors je m’arrête dessus une seconde. Ce champ sert à enfermer une VM dans un seul VLAN. Or nous, c’est l’inverse qu’on veut : qu’OPNsense reçoive le trunk complet, toutes les zones à la fois, pour en être le routeur. Si tu mets un numéro ici, tu forces une seule zone et tu casses tout le reste. Le tri des VLAN, c’est le boulot d’OPNsense, pas celui de Proxmox.

Le piège du redémarrage : coche la case ne suffit pas

Voilà l’heure que je viens de perdre, et que je t’épargne. Quand tu coches VLAN aware sur un pont qui existe déjà, Proxmox applique bien la configuration, mais les cartes virtuelles des VM déjà démarrées gardent leur ancien réglage. Ton pont filtre désormais par VLAN, et le port de ta VM OPNsense n’est pas déclaré en trunk. Résultat : la trame taguée arrive sur le pont et n’est délivrée à personne. Tout est vert dans les deux interfaces, et rien ne circule. Après avoir coché la case, arrête complètement ta VM OPNsense depuis Proxmox (Shutdown puis Start, pas un reboot depuis OPNsense), pour que sa carte virtuelle soit recréée. Si le symptôme persiste, redémarre le nœud Proxmox entier. Ça n’est pas élégant, mais c’est ce qui a débloqué mon cas.

Et voici le second point qui m’a coûté une soirée : tout ça ne marche que parce que vmbr1 porte une vraie carte physique branchée sur ton switch. Un pont VLAN-aware sans carte physique en entrée n’a pas de trunk à transporter, il ne se passe rien. C’est la carte reliée au switch qui apporte le trunk réel. Si tu as suivi l’article d’installation, cette carte est déjà en place sur vmbr1. Il ne te reste qu’à cocher VLAN aware.

Une fois ces deux réglages posés, le trajet complet est en place : le switch envoie le trunk tagué, la carte physique le reçoit, le pont VLAN-aware le laisse passer intact, et il arrive enfin dans OPNsense prêt à être découpé. C’est ce découpage qu’on attaque maintenant.

Créer ton premier VLAN dans OPNsense

Le pont est prêt à laisser passer les étiquettes, OPNsense attend de l’autre côté. On va construire une zone complète, de zéro jusqu’à une interface active avec sa propre adresse. Comme promis, on ne le fait pas pour toutes les zones : on en construit une seule, de bout en bout, celle que tu pourras reproduire à l’identique pour toutes les autres.

J’ai pris l’IoT, et ce n’est pas un hasard. C’est la zone des objets connectés : la prise à 12 €, la TV qui cause à des serveurs à l’autre bout du monde, l’ampoule dont tu ne sauras jamais ce qu’elle raconte. Bref, tout ce en quoi on n’a aucune raison d’avoir confiance. La partie 1 en faisait la zone qui justifie à elle seule toute la démarche de segmentation, et c’est aussi celle dont les règles de pare-feu seront les plus parlantes quand on y arrivera. Autant apprendre sur l’exemple le plus utile.

Poser le plan avant de cliquer

Une bonne habitude qui t’évitera des migraines : chaque VLAN a un numéro (son tag) et sa propre plage d’adresses, et le plus simple est de faire correspondre les deux. Pour notre zone IoT :

Le tag 30 qu’on retrouve dans le 192.168.30.x, ce n’est pas obligatoire, mais quand tu auras plusieurs zones, tu seras content de lire l’adresse et de savoir immédiatement dans quelle zone tu es. L’adresse en .1, c’est OPNsense : il est la passerelle de cette zone, comme il l’est de toutes les autres.

Étape 1 : créer le device VLAN

Direction Interfaces → Devices → VLAN. Si tu cherches l’ancien menu « Other Types » vu dans de vieux tutos, il n’existe plus : sur OPNsense 26.7, c’est bien Devices. La liste est vide pour l’instant, c’est normal.

Clique sur le + pour ajouter une entrée, et renseigne :

• Parent : ton interface LAN. C’est celle qui est branchée sur vmbr1 côté Proxmox, et elle apparaît dans OPNsense sous le nom vtnet1 (les cartes réseau d’une VM sont des interfaces virtio, d’où le vtnet). C’est le tuyau par lequel arrive le trunk : tous tes VLAN seront des enfants de cette interface.

• VLAN tag : 30

• VLAN priority : laisse la valeur par défaut, tu n’en as pas besoin.

• Description : Iot. Mets-en une, toujours. Dans six mois, Iot te parlera, un nom de device brut beaucoup moins.

Le champ Device reste vide : ne le remplis pas. OPNsense nommera lui-même le device au moment de l’enregistrement, sous la forme vlanXX en numérotation séquentielle. Ce numéro n’a rien à voir avec ton tag : sur une installation neuve, ton premier VLAN taggé 30 s’appellera vlan01. C’est déroutant la première fois, c’est normal.

Tu enregistres. Tu viens de créer l’étiquette. À ce stade, elle n’existe que sur le papier : aucune interface utilisable, aucune adresse. Il faut maintenant la présenter au reste d’OPNsense.

Étape 2 : assigner l’interface

Va dans Interfaces → Assignments. Tu y vois déjà tes deux interfaces de base, le WAN sur vtnet0 et le LAN sur vtnet1.

Clique sur le + en bas à droite de la liste. Une fenêtre Edit Assignment s’ouvre. Déroule le menu Device : ton VLAN y apparaît, dans une catégorie vlan distincte des interfaces matérielles, avec son parent et son tag rappelés entre parenthèses. Sélectionne-le, donne-lui la description Iot, et enregistre.

OPNsense lui donne un identifiant générique du type opt1, et cette nouvelle interface apparaît désormais dans le menu Interfaces. Elle existe, mais elle est encore éteinte et sans adresse. Dernière étape.

Étape 3 : activer l’interface et lui donner son adresse

Dans le menu Interfaces, clique sur ta nouvelle interface Iot. Trois choses à régler.

D’abord, coche Enable interface. Sans ça, tout le reste est inerte. Vérifie au passage la Description : ce nom remplacera le générique opt1 partout dans l’interface, y compris dans les règles de pare-feu. Tu te remercieras.

Ensuite, règle IPv4 Configuration Type sur Static IPv4. Une section « Static IPv4 configuration » apparaît en bas de la page. Dans IPv4 address, saisis 192.168.30.1 et choisis /24 dans le menu à côté. C’est l’adresse d’OPNsense dans ta zone IoT, sa passerelle.

Tu enregistres, puis tu cliques sur Apply changes dans le bandeau qui apparaît en haut. Ta zone IoT est née. OPNsense a maintenant un pied dedans, à l’adresse 192.168.30.1, prêt à en être la passerelle.

Ce qui ne marche pas encore, et c’est normal

Si tu branchais un appareil dans cette zone maintenant, il ne se passerait rien. Pas d’adresse, pas de connexion. C’est attendu, pour deux raisons qu’on va lever dans les sections suivantes : personne ne distribue encore d’adresses dans cette zone (c’est le DHCP, juste après), et aucune règle de pare-feu n’autorise le moindre flux sur cette interface (c’est le cœur de l’article, ensuite).

Un mot de prudence pendant qu’on bâtit : ne touche pas à ton interface LAN existante, celle par laquelle tu administres OPNsense en ce moment. On construit la zone IoT à côté, sans couper la branche sur laquelle tu es assis. Le nettoyage final, quand toutes tes zones seront des VLAN et que le LAN par défaut n’aura plus lieu d’être, se fera proprement une fois que le switch sera configuré. Chaque chose en son temps.

Une deuxième zone, pour le Pi-hole

Avant d’aller plus loin, il faut régler une question de logement. Toute la suite de l’article repose sur un scénario simple : tes objets connectés vivent dans l’IoT, et ils ont le droit de joindre une seule machine ailleurs, le Pi-hole. Sauf que si tu as suivi la série, ton Pi-hole n’est nulle part. Il est resté sur vmbr0, sans étiquette, dans le réseau plat d’avant. Impossible de démontrer un cloisonnement entre deux zones quand l’une des deux n’existe pas.

Il te faut donc une seconde zone. On la crée exactement comme la première, avec les trois mêmes étapes, en changeant seulement les valeurs :

Pas de DHCP sur la zone Serveurs, et c’est volontaire

Tu vas configurer un serveur DHCP sur l’IoT dans la section suivante. Sur les Serveurs, tu n’en mets aucun. Ce n’est pas un oubli, c’est une règle générale qui vaut pour tout ton réseau :

• Une machine qu’on joint depuis ailleurs a une adresse fixe. Le Pi-hole, le NAS, Jellyfin, les interfaces d’administration. Si leur adresse bouge, tes règles de pare-feu, tes signets et tes redirections cassent d’un coup, sans prévenir.

• Une machine qui va et vient prend son adresse en DHCP. Un téléphone, une tablette, une prise connectée. Personne ne les joint par leur adresse, tu n’as aucune raison de la figer à la main.

Traduit sur les zones de la partie 1 : DHCP sur Perso, IoT et Démo, rien sur Admin et Serveurs. Les machines de ces deux zones-là reçoivent leur adresse à la main, et pointent directement vers le résolveur d’OPNsense pour le DNS. Souviens-toi de la raison donnée en partie 1 : l’infrastructure ne doit pas dépendre d’un service qu’elle est censée faire tourner ou réparer.

Déménager le Pi-hole dans la zone Serveurs

Ton conteneur Pi-hole existe déjà, il n’y a rien à réinstaller. Trois changements dans Proxmox, sur son onglet Network :

• Bridge : passe de vmbr0 à vmbr1, le pont VLAN-aware.

• VLAN Tag : saisis 20. C’est ce champ, laissé vide dans l’article d’installation du Pi-hole, qui le fait atterrir dans la zone Serveurs.

• IPv4 : adresse statique 192.168.20.10/24, passerelle 192.168.20.1.

Redémarre le conteneur. Il vit maintenant dans la zone Serveurs, à une adresse stable, et il est joignable uniquement par les chemins que tu autoriseras.

Le réglage qui va te bloquer, et personne ne le dit

Par défaut, Pi-hole n’accepte de répondre qu’aux requêtes venant de son propre sous-réseau. Il est en 192.168.20.10/24, tes objets IoT arrivent depuis 192.168.30.x : il les voit, et il les ignore purement et simplement. Le symptôme est trompeur, parce que le ping passe et que seule la résolution de noms échoue. Tu retrouveras d’ailleurs le motif exact dans les messages du Pi-hole : ignoring query from non-local network. La correction est dans Settings → DNS, section Interface settings : passe de « Allow only local requests » à « Permit all origins ». L’avertissement affiché est légitime, mais chez toi le risque est déjà couvert en amont : OPNsense n’autorise que le VLAN 30 à atteindre le port 53 de cette machine. On ouvre côté applicatif parce qu’on a déjà fermé côté réseau.

Distribuer les adresses : le DHCP de la zone

Ta zone IoT existe, OPNsense y a une adresse, mais elle est encore déserte. Branche un appareil dedans maintenant, il attend une adresse que personne ne lui donne, et il reste muet. Chaque VLAN est un réseau isolé, donc chaque VLAN a besoin de son propre distributeur d’adresses. C’est le rôle du serveur DHCP, et on va le configurer pour l’IoT.

Le bon serveur DHCP en 2026

Petit détour obligatoire, parce que si tu suis un tuto d’il y a deux ans, il va t’envoyer droit dans le mur. Le paysage DHCP d’OPNsense a changé, et sur ta version 26.7 tu as trois services en apparence, mais un seul vrai choix pour une install neuve.

Une confidence, parce que ce blog ne te vend jamais un choix sans son revers : ma propre prod tourne encore en ISC DHCP, par héritage, parce qu’on ne migre pas une installation qui marche juste pour le plaisir. Mais pour une install neuve aujourd’hui, la réponse est différente. OPNsense affiche désormais ISC comme legacy : il ne reçoit plus vraiment de développement et finira par disparaître. Documenter en 2026 un tuto débutant sur une techno que l’éditeur enterre, ce serait t’envoyer sur une voie sans issue. On part donc sur du durable.

Reste Dnsmasq et Kea. Sur le papier, OPNsense recommande Dnsmasq pour les petits réseaux, et pour la plupart des gens ce serait le bon réflexe. Mais toi, tu as déjà un Pi-hole qui fait le DNS de ton réseau, et Dnsmasq veut faire le DNS en plus du DHCP.

Sois précis sur ce que ça implique, parce qu’on lit beaucoup d’approximations là-dessus. Sur OPNsense 26.7, Dnsmasq n’écoute pas sur le port 53 par défaut : l’éditeur l’a placé sur un port décalé (53053) pour qu’il cohabite avec le résolveur Unbound. Il n’y a donc pas de collision DNS immédiate avec ton Pi-hole. Le vrai conflit est ailleurs, sur le port 67, celui du DHCP : Dnsmasq l’occupe, et c’est lui qui empêchera Kea de démarrer. On y vient dans la section suivante.

Reste l’argument de fond, celui qui décide : Kea ne fait qu’une chose, distribuer des adresses. Il ne touche pas au DNS, donc pas de recouvrement de responsabilité avec ton Pi-hole, pas de réglage à surveiller pour que les deux se supportent. Une responsabilité par outil, c’est plus propre et ça tombe en panne moins souvent. On part sur Kea.

Sa seule limite honnête : Kea n’enregistre pas automatiquement les noms d’hôtes dans le DNS. Mais chez toi c’est le Pi-hole qui gère les noms locaux, donc ça ne te coûte rien de plus.

D’abord, éteindre Dnsmasq

Ne saute pas cette étape, sinon Kea refusera de démarrer et tu ne comprendras pas pourquoi. Sur une installation neuve d’OPNsense 26.7, Dnsmasq est actif par défaut et il occupe le port 67, celui du DHCP. Kea démarre, ne peut pas prendre le port, et s’arrête aussitôt. Rien ne te prévient : pas de bandeau rouge, pas de message d’erreur à l’écran. Simplement un service qui ne reste pas allumé, et des appareils qui n’obtiennent jamais d’adresse.

Le symptôme visible est ce bouton play vert, dans le bandeau de contrôle en haut à droite de la page Kea, qui revient obstinément après chaque clic. Quand un service tourne, c’est le bouton stop qui est proposé. Si tu vois le play, ton service est à l’arrêt, quelle que soit la configuration que tu viens d’enregistrer.

Va dans Services → Dnsmasq DNS & DHCP → General, décoche Enable, et applique.

Si un jour tu tombes quand même sur le symptôme, le diagnostic est dans Services → Kea DHCP → Log File. Kea y écrit noir sur blanc ce qui le bloque : failed to bind fallback socket to address 192.168.30.1, port 67, reason: Address already in use. Un service qui te dit exactement pourquoi il refuse de démarrer, c’est assez rare pour être signalé.

Activer Kea sur la zone IoT

Direction Services → Kea DHCP → Kea DHCPv4. Deux onglets à remplir, dans l’ordre.

Sur l’onglet Settings, tu actives le service (Enabled), tu ajoutes ton interface Iot à la liste des Interfaces sur lesquelles Kea écoute, et tu laisses la case Firewall rules cochée. Cette case dit à OPNsense d’ajouter tout seul les quelques règles qui autorisent le dialogue DHCP sur l’interface. Sans ça, tes appareils ne pourraient même pas demander une adresse. Attention, ce sont uniquement les règles techniques du DHCP : elles n’ouvrent rien d’autre, et surtout pas le cloisonnement qu’on va écrire juste après.

Un mot sur ce champ Interfaces, parce qu’il vaut pour toute la suite : Kea est un seul service, pas un serveur par zone. Tu déclares un sous-réseau par VLAN et tu coches les interfaces d’écoute. Trois zones en DHCP, ce sera trois sous-réseaux et trois cases cochées, toujours dans le même écran. Ici, une seule : Iot.

Tu appliques, puis tu vérifies que le service tourne réellement. Dans le bandeau de contrôle en haut à droite, le bouton play doit avoir laissé la place au bouton stop. Tant que le play est actif, Kea est à l’arrêt, quelle que soit la configuration que tu viens d’enregistrer.

L’onglet Subnets est encore vide, on va le remplir. Clique sur le + et renseigne la zone IoT :

• Subnet : 192.168.30.0/24. C’est la plage complète de la zone.

• Pools : 192.168.30.100-192.168.30.200. C’est la fourchette d’adresses que Kea distribuera automatiquement. On la garde volontairement plus petite que le réseau entier : les adresses hors de cette fourchette restent libres pour d’éventuelles adresses fixes.

• DHCP option data → Auto collect option data : décoche cette case. C’est le point clé de ton cas. Cochée, elle remplit toute seule la passerelle et le DNS avec les valeurs par défaut d’OPNsense, et tes appareils IoT utiliseraient alors OPNsense comme DNS, en contournant le Pi-hole. On veut l’inverse. En la décochant, deux champs apparaissent, qu’on remplit à la main.

• Routers (gateway) : 192.168.30.1. C’est OPNsense, la passerelle de la zone.

• DNS servers : 192.168.20.10, l’adresse de ton Pi-hole dans la zone Serveurs. C’est cette ligne, et elle seule, qui force tes objets connectés à passer par ton filtre DNS. Sans elle, tout ce qu’on va construire ensuite dans le pare-feu autorise un flux que personne n’emprunte.

Tu enregistres, puis tu appliques.

Un détail qui va coincer, et c’est voulu

Regarde ce que tu viens de faire : tu as dit à tes objets connectés « pour le DNS, vous passez par le Pi-hole, il est à cette adresse ». Sauf qu’il y a un hic, et il est énorme. Le Pi-hole habite dans la zone Serveurs. Tes objets IoT, eux, sont enfermés dans la zone IoT. Et depuis le début, la règle du jeu c’est : aucune zone ne parle à aucune autre. Tant que rien n’a changé, ta consigne DNS n’est qu’un vœu pieux : ton ampoule va gentiment frapper à la porte du Pi-hole pour demander sa résolution, et se prendre le mur du pare-feu en pleine face. Personne ne répond.

Et c’est exactement là que je voulais t’emmener. C’est tout le message de cet article, tiens-le bien : créer un VLAN, distribuer des adresses, pointer un DNS, rien de tout ça ne « marche » tant que tu n’as pas ouvert, à la main et une par une, les portes que tu acceptes d’ouvrir. Le reste est fermé, par défaut, pour de bon. Alors allons ouvrir cette porte, maintenant, et regardons de près comment on décide qui a le droit de parler à qui.

Le pare-feu : là où le cloisonnement devient réel

Voilà le cœur du réacteur. Jusqu’ici, tu as créé une zone, tu lui as donné une adresse, tu as posté un distributeur d’adresses à l’entrée. Mais ta zone IoT est un cul-de-sac : rien n’entre, rien ne sort, même pas le DNS. C’est maintenant que tu décides, porte par porte, ce que tu autorises. Et c’est la seule chose qui compte vraiment. Tout le reste, c’était de la tuyauterie. Ça, c’est la sécurité.

Trois principes à avoir en tête avant de cliquer

Sinon tu vas écrire des règles au hasard et te demander pourquoi rien ne se comporte comme prévu.

Les règles se posent sur l’interface d’où part le trafic. Dans OPNsense, chaque interface a son propre onglet de règles, et une règle y filtre ce qui entre depuis les appareils de cette zone. Donc les règles de l’IoT se posent dans l’onglet Iot, et elles décrivent ce que tes objets connectés ont le droit d’aller faire. Retiens la question à te poser à chaque fois : « depuis cette zone, vers où ? »

Elles se lisent de haut en bas, la première qui correspond gagne. Dès qu’un paquet coche une règle, c’est fini, les suivantes sont ignorées. L’ordre n’est donc pas cosmétique, c’est le fond. Une même liste de règles dans le mauvais ordre produit l’inverse de ce que tu veux.

Par défaut, une zone VLAN toute neuve ne laisse rien passer. C’est une différence majeure avec le LAN d’origine, celui par lequel tu administres OPNsense : lui, il est né avec une règle « autorise tout » posée pour toi. Tes VLAN, non. Ils partent de zéro, tout est refusé tant que tu n’as rien écrit. C’est exactement ce qu’on veut : on part du plus fermé, et on ouvre au compte-gouttes.

Et il faut que je sois honnête avec toi sur un point tout de suite, parce que c’est la limite du système : le pare-feu ne voit que ce qui passe d’une zone à l’autre. Deux appareils dans la même zone IoT se parlent en direct, par le switch, sans jamais remonter jusqu’à OPNsense. Le pare-feu n’est pas sur leur chemin, il ne peut donc pas les empêcher de se voir entre eux. Isoler les appareils à l’intérieur d’un même VLAN, c’est un réglage du switch et du point d’accès (l’isolation client), et ça relèvera de l’article dédié au switch. Ici, on cloisonne entre zones, et c’est déjà l’essentiel du travail.

D’abord, un outil qui va te resservir : l’alias

On va avoir besoin de désigner « tout mon réseau local, toutes zones confondues » en une seule fois. Plutôt que de lister tes VLAN un par un, on crée un alias : une étiquette réutilisable qui regroupe plusieurs plages d’adresses sous un seul nom.

Va dans Firewall → Aliases. La liste que tu vois contient déjà des entrées : les alias par défaut d’OPNsense et ceux qu’il génère automatiquement pour chacune de tes interfaces. On ne touche à rien, on ajoute le nôtre avec le +.

• Name : Reseau_Privee. OPNsense n’accepte que des lettres, des chiffres et des underscores : pas d’espace, pas de tiret. Choisis ton orthographe une bonne fois et tiens-la, parce qu’une règle qui pointe vers un nom d’alias inexistant ne bloque strictement rien, en silence.

• Type : Network(s). Ce point n’est pas négociable et c’est le piège classique. Tu vas saisir des plages en notation CIDR, pas des adresses uniques. Avec le type Host(s), OPNsense attend des machines individuelles, ton alias reste vide en pratique, et la règle de blocage qui s’appuie dessus ne se déclenche jamais. Tout a l’air correct à l’écran, et rien n’est bloqué.

• Content : les trois plages d’adresses privées, une entrée par ligne : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.

• Description : une phrase claire, tu la reliras dans six mois.

Tu enregistres et tu appliques. Cet alias représente maintenant l’intégralité de ton réseau interne, présent et futur. C’est tout son intérêt : le jour où tu ajoutes une zone, tu n’as aucune règle à réécrire, elle est déjà couverte.

Les règles de la zone IoT

Direction Firewall → Rules → Iot. Souviens-toi du contrat de la partie 1 pour cette zone : l’IoT a le droit de joindre le Pi-hole pour le DNS, et le reste de ton réseau lui est interdit. Voici les règles, dans cet ordre précis :

L’onglet démarre vide, et OPNsense te le dit explicitement : tant qu’aucune règle Pass n’est posée, toutes les connexions entrantes sur cette interface sont bloquées. C’est le refus par défaut dont on a parlé, écrit noir sur blanc.

Chaque règle se crée de la même façon. Voici la première en détail, l’autorisation DNS vers le Pi-hole ; les trois autres suivent la même mécanique, seuls la destination et l’action changent.

Commence par la partie haute du formulaire : Description (mets-en une, toujours), Quick coché, Action sur Pass, Direction sur In, Version IPv4, Protocol sur TCP/UDP, et Source sur Iot network.

Puis la destination : Single host or Network avec l’adresse 192.168.20.10, et Destination Port sur DOMAIN (53).

Enfin la partie basse, où tu laisses State type sur keep state et Gateway sur None.

Reprenons dans l’ordre, parce que chaque ligne dépend de celle du dessus.

La règle 1 ouvre la seule porte que l’IoT a le droit de franchir vers une autre zone : le Pi-hole, sur le port 53. Elle est tout en haut pour une raison précise. Les deux blocages qui suivent vont ratisser large, et c’est cette exception, posée avant eux, qui garde le DNS légitime en vie. Ton Pi-hole (192.168.20.10) est une machine de ton réseau privé et il parle DNS : sans cette règle en tête, il serait fauché par les suivantes comme tout le reste.

La règle 2 est celle que tes objets vont détester, et c’est exactement pour ça qu’elle existe. Voilà le problème qu’elle règle : beaucoup d’appareils connectés (Chromecast, TV, ampoules Tuya, Google Home) se moquent éperdument du serveur DNS que Kea leur distribue. Ils ont une adresse de DNS public codée en dur dans leur firmware (8.8.8.8, 1.1.1.1) et vont l’interroger directement, en contournant purement et simplement ton Pi-hole. Si tu ne fais rien, ta règle de sortie internet (la 4) leur laisse ce passage grand ouvert, et tout ton filtrage DNS ne sert à rien pour ces appareils-là. La règle 2 ferme la porte : elle bloque toute requête DNS sur le port 53 vers n’importe quelle destination. Comme la règle 1 a déjà laissé passer le Pi-hole juste au-dessus, lui reste parfaitement joignable ; tout autre résolveur, lui, se prend le mur. Traduction : « le DNS, oui, mais uniquement par le Pi-hole, et pas moyen de tricher ».

La règle 3 coupe l’IoT du reste de ton réseau : blocage vers l’alias Reseau_Privee, c’est-à-dire vers toutes tes autres zones. C’est le cloisonnement pur, et c’est la règle qui fait tout le travail de sécurité de cet article.

La règle 4, en dernier, ne peut plus concerner que ce qui a survécu au-dessus : ni le Pi-hole (autorisé), ni le DNS sauvage (bloqué), ni ton réseau local (bloqué). Ne reste qu’internet en clair. L’ordre transforme un « autorise tout » brutal en un « autorise ce qui reste, c’est-à-dire le web ».

Un mot qui va te soulager : les règles d’OPNsense sont à état. Tu écris uniquement le sens de départ (l’IoT qui va vers le Pi-hole), et la réponse revient automatiquement. Pas besoin d’écrire une règle retour, OPNsense suit la conversation tout seul.

La limite de ce blocage, et la zone grise à assumer

Deux choses à savoir, parce que je ne vais pas te vendre une étanchéité parfaite.

D’abord, ce blocage se voit. Un appareil privé de son DNS codé en dur peut renâcler : un Chromecast qui ne joint plus 8.8.8.8 peut mettre un peu plus de temps à démarrer, voire bouder une fonction ici ou là. Dans l’immense majorité des cas, il bascule sagement sur le DNS que tu lui imposes, ton Pi-hole, et tout roule. Mais si un objet fait la tête juste après cette manip, tu sauras où regarder. C’est le prix de reprendre le contrôle, et il est presque toujours dérisoire.

Ensuite, la règle 2 arrête le DNS en clair sur le port 53. Tu peux la durcir en ajoutant le port 853, celui du DNS chiffré façon DoT, dans la même règle. Mais aucune des deux ne bloque le DoH, le DNS sur HTTPS. Lui passe par le port 443, impossible à distinguer d’une navigation web normale, donc impossible à couper avec une simple règle de port sans casser tout internet au passage. Un appareil vraiment têtu peut donc encore faire fuiter sa résolution par là. La parade propre (rediriger de force tout le trafic du port 53 vers le Pi-hole, et traiter le cas épineux du DoH) sort du cadre de cet article débutant : ce sera le sujet d’un article dédié au bypass DNS. Pour aujourd’hui, la règle 2 rattrape déjà la grande majorité des objets récalcitrants, et c’est un monde d’écart avec le réseau plat du départ.

La décision qui t’appartient : l’IoT et internet

Il faut que je lève une ambiguïté que tu as peut-être relevée, parce qu’elle est réelle. En partie 1, je te décrivais mon propre réseau, où la zone IoT ne joint que le Pi-hole : pas d’internet, sauf pour deux appareils nommément désignés. Or la règle 4 qu’on vient de poser ouvre le web à toute la zone. Ce n’est pas une contradiction, c’est un curseur, et il t’appartient. Deux écoles :

• La version pragmatique, celle qu’on vient de poser et que je te recommande pour commencer : tu gardes cette règle 4. Tes objets connectés atteignent internet (beaucoup en ont besoin pour leur appli mobile ou leur cloud), mais ils ne voient absolument rien de ton réseau. Rien que ça, comparé au réseau plat du départ, c’est un monde d’écart : une ampoule compromise ne peut plus scanner ton NAS.

• La version stricte, celle de mon propre réseau décrite en partie 1 : tu supprimes cette règle 4, et tu n’autorises internet qu’à quelques appareils nommés, par leur adresse, ceux qui en ont réellement besoin (chez moi, la TV et l’imprimante 3D). Tout le reste vit hors ligne, coupé du monde. C’est plus contraignant, plus sûr, et c’est le cran d’après une fois que tu es à l’aise.

Il n’y a pas de bon choix universel là-dessus, il y a le tien. Mais dans les deux cas, le blocage vers les autres zones, lui, n’est pas négociable : c’est lui qui fait tout le travail de cloisonnement.

Et pour les autres zones ?

Le plus dur est fait, parce que tu tiens maintenant la méthode, et c’est toujours la même. Pour chaque zone : tu ouvres son onglet de règles, et tu te poses une seule question, « qu’est-ce que cette zone a le droit d’aller faire, et rien d’autre ? ». Tu réponds en quelques règles, tu refermes, tu passes à la suivante. Et si un jour tu croules sous les zones avec des règles qui se répètent, OPNsense sait factoriser tout ça avec les groupes d’interfaces (les Security Zones) : tu écris une règle une fois pour plusieurs VLAN. On n’en a pas besoin ici, mais retiens le nom pour quand ta liste s’allongera.

Concrètement, ça donne quoi ? Ta zone Perso pourra regarder un film sur Jellyfin et ouvrir Homarr, donc joindre ces services sur les Serveurs, mais elle n’aura aucun chemin vers les interfaces d’administration. Tes Serveurs, eux, répondent quand on les sollicite mais ne partent jamais toquer ailleurs de leur propre initiative. Et l’administration d’OPNsense ou de Proxmox ne se laissera approcher que depuis une seule machine bien précise, la tienne, pas depuis toute une zone.

Tu l’as sûrement reconnue : c’est la carte des flux que je te montrais en partie 1. Sauf que cette fois, tu ne la regardes plus, tu l’écris. Zone après zone, tu traduis le schéma en règles réelles. Et le principe ne bouge jamais d’un pouce : tout est fermé par défaut, tu n’ouvres que des exceptions, et chacune doit tenir dans une phrase qui commence par « parce que ». Le jour où tu tombes sur une règle que tu ne sais plus justifier, tu la supprimes.

Un réflexe à garder : ne te verrouille pas dehors

Tant que tu administres OPNsense depuis le LAN d’origine, tu es tranquille : une anti-lockout rule protège cet accès par défaut, tu ne peux pas te couper la branche sous les pieds. Mais le jour où tu déplaceras ton poste d’administration sur un VLAN dédié (une zone Admin, par exemple), cette protection ne couvre plus cette interface. Avant de fermer le LAN d’origine, vérifie que tu as bien une règle autorisant ton poste à joindre l’interface d’administration. Sinon, tu te retrouves dehors, sans clé.

Prouver que ça tient vraiment

Tu as écrit des règles. Ne les crois pas sur parole pour autant. La pire des situations, c’est de penser qu’une zone est cloisonnée alors qu’une règle mal placée laisse une porte ouverte sans que tu le saches. Alors on vérifie, et on vérifie les deux sens : ce qui doit passer passe, et surtout ce qui doit être bloqué est bel et bien bloqué.

Pour ça, il te faut un appareil témoin dans la zone IoT. Sur ton environnement de démo, branche une machine de test sur un port de switch réglé pour l’IoT, ou connecte-la au Wi-Fi IoT. C’est elle qui va nous servir de cobaye.

Test 1 : l’appareil reçoit-il une adresse ?

Regarde la configuration réseau de ta machine témoin. Elle doit avoir attrapé une adresse dans la fourchette que tu as définie, entre 192.168.30.100 et 192.168.30.200, avec 192.168.30.1 comme passerelle et 192.168.20.10 comme DNS. Ces trois valeurs ensemble, c’est toute la chaîne Kea qui se vérifie d’un coup d’œil.

Si l’appareil n’a aucune adresse ou une adresse bizarre en 169.254.x.x, c’est que la demande DHCP n’arrive pas jusqu’à Kea. Le problème est en amont : soit le service Kea ne tourne pas, soit le VLAN ne descend pas jusqu’à OPNsense, soit le pont VLAN-aware n’a pas été repris par la VM.

Test 2 : le DNS passe-t-il bien par le Pi-hole ?

C’est le test le plus satisfaisant, parce qu’il prouve deux choses d’un coup. Depuis ta machine témoin, ouvre une page web quelconque. Si elle charge, c’est que la résolution de noms fonctionne. Mais ne t’arrête pas là : va voir le journal des requêtes de ton Pi-hole. Tu dois y voir apparaître, en direct, les requêtes DNS émises par ton appareil IoT, avec son adresse en 192.168.30.x dans la colonne Client.

Ça, c’est la double preuve. D’abord, ta règle numéro 1 marche : l’IoT atteint bien le Pi-hole sur le port 53, à travers deux zones. Ensuite, et c’est le point que la partie 1 promettait, ton Pi-hole voit désormais ce que tes objets connectés essaient de contacter. Tu tiens là, sans t’en rendre compte, ton premier outil d’observabilité. On y reviendra dans la partie 3.

Test 3 : internet fonctionne

Ta machine témoin doit pouvoir sortir sur le web normalement, puisqu’on a gardé la règle de sortie. Rien de spécial à faire, si les pages chargent, c’est réglé. Si tu as choisi la version stricte et supprimé cette règle, c’est l’inverse qu’il faut constater : à part le DNS, ton appareil ne doit atteindre aucun site.

Test 4 : le vrai test, l’isolation

Voilà celui qui compte. Depuis ta machine témoin dans l’IoT, essaie d’atteindre une autre zone. Tente d’ouvrir l’interface de Proxmox, ou celle d’OPNsense, ou de joindre n’importe quelle machine de la zone Serveurs autre que le Pi-hole. Le résultat attendu, c’est le silence : ça tourne, ça tourne, et ça finit en timeout. Rien ne répond.

Ce silence, c’est ta règle numéro 3 qui fait son travail. Ton appareil IoT est dans une pièce fermée : il voit le Pi-hole pour le DNS, il voit internet, et c’est tout. Le reste de ton réseau n’existe pas pour lui.

Si au contraire tu arrives à joindre une autre zone, trois choses à vérifier dans cet ordre, ce sont les trois causes qui couvrent presque tous les cas :

• As-tu cliqué sur Apply ? Des règles enregistrées mais non appliquées existent dans l’interface et pas dans le pare-feu.

• Le nom de l’alias dans la règle correspond-il exactement à celui de l’alias ? Une différence d’une lettre, et la règle pointe vers rien.

• L’alias est-il bien de type Network(s) ? En Host(s), il ne matche aucune de tes plages.

Un dernier réflexe si tout semble correct : une connexion déjà ouverte avant la règle survit au blocage. Vide la table dans Firewall → Diagnostics → States et retente.

La preuve par les logs

Il reste une manière de voir les choses de tes propres yeux, du côté d’OPNsense cette fois. Va dans Firewall → Log Files → Live View. C’est le journal en temps réel de toutes les décisions du pare-feu. Filtre sur ton interface IoT, et relance ton test d’isolation : tu vas voir défiler, en direct, les paquets bloqués, avec leur source, leur destination et le nom de la règle qui les a arrêtés. C’est ton pare-feu qui te montre, ligne par ligne, ce qu’il refuse pour toi.

Un conseil au passage : sur ta règle de blocage inter-zones (la numéro 3), coche l’option Log. Par défaut tu vois surtout les refus implicites ; en activant le journal sur ta propre règle, tu la repères d’un coup d’œil et tu confirmes que c’est bien elle qui agit. À l’inverse, ne coche pas le log sur ta règle 4, la sortie internet : elle laisse passer tout le trafic web normal de tes objets, tu noierais tes journaux sous le bruit. Et garde ça en tête, parce que c’est tout le sujet de la partie 3 : ces logs qui défilent, aujourd’hui tu les regardes deux minutes pour un test, demain on apprendra à les faire parler tout seuls.

Si tes quatre tests passent, c’est gagné. Ta zone IoT est réelle, peuplée, et hermétique. Tu viens de transformer une ligne sur un schéma en un vrai mur. Il ne te reste plus qu’à rejouer la même partition pour tes autres zones.

Une précision qui compte : tout ça, c’est de l’IPv4

Cet article configure et vérifie ton cloisonnement en IPv4, et pour un homelab qui débute, c’est le terrain principal. Mais sois vigilant sur un point : si ta box distribue de l’IPv6 et qu’il est actif sur tes VLAN, tes appareils peuvent avoir une connectivité IPv6 qui échappe complètement aux règles IPv4 qu’on vient d’écrire. Autrement dit, ton mur a peut-être une porte dérobée que tu ne vois pas. Deux options propres : soit tu répliques ces mêmes règles en IPv6, soit tu désactives l’IPv6 sur ces interfaces tant que tu ne le maîtrises pas. Le traiter sérieusement mériterait son propre article ; d’ici là, au minimum, vérifie que tu n’as pas laissé une IPv6 grande ouverte là où tu croyais tout fermé.

On a construit un vrai mur

Regarde le chemin parcouru. Tu es parti d’un OPNsense fraîchement installé, posé sur un réseau encore plat, et tu as bâti deux zones complètes de bout en bout : des VLAN taggés qui descendent proprement du pont Proxmox jusqu’à OPNsense, des interfaces avec leur propre adresse, un serveur Kea qui distribue les baux sans marcher sur ton Pi-hole, et surtout les règles de pare-feu qui décident, au paquet près, qui a le droit de parler à qui. Puis tu as vérifié, dans les deux sens, que le mur tient.

Si tu ne devais retenir qu’une phrase de tout cet article, ce serait celle-ci : un VLAN, tout seul, ne protège rien. Créer la zone, lui coller une adresse, distribuer le DHCP, c’est de la plomberie. Ce qui cloisonne, ce qui fait la sécurité, ce sont les règles du firewall que tu poses derrière, dans le bon ordre, avec le refus par défaut comme socle et chaque ouverture justifiée en une phrase. La partie 1 t’avait donné la carte ; tu sais maintenant la construire.

Il te reste deux chantiers, et tu as déjà tout ce qu’il faut pour les mener. D’abord, rejouer cette partition pour tes autres zones : Perso, Admin, et le reste de tes Serveurs. Le geste est identique à chaque fois, seule la liste des exceptions change.

Ensuite, la pièce qu’on a volontairement laissée de côté : la configuration de ton switch manageable, celle qui décide quel port appartient à quelle zone et comment le trunk relie tout ça à OPNsense. Elle dépend trop de ta marque pour tenir dans un paragraphe, alors elle aura son propre article, bientôt.

Et puis il y a la suite de la série. Ton réseau est maintenant cloisonné, mais souviens-toi de la question que posait la première partie : un réseau bien découpé où personne ne regarde ce qui s’y passe, c’est une maison blindée dont personne ne surveille les caméras. Pendant tes tests, tu as entrevu deux de ces caméras : le journal de ton Pi-hole, qui voit ce que tes objets contactent, et la vue en temps réel d’OPNsense, qui montre chaque paquet refusé. Aujourd’hui tu les as regardées deux minutes. Dans la partie 3, on apprendra à les faire parler toutes seules : collecter les logs, repérer l’anomalie dans le bruit, se faire alerter quand quelque chose cloche. Le tout en auto-hébergé, évidemment.

D’ici là, tu as de quoi t’occuper. Tu as des zones à construire !

Ta tech, tes règles, ta liberté.

Sources

• OPNsense, documentation officielle, VLAN and LAGG Setup : docs.opnsense.org/manual/how-tos/vlan_and_lagg.html

• OPNsense, documentation officielle, Devices : docs.opnsense.org/manual/other-interfaces.html

• OPNsense, documentation officielle, KEA DHCP : docs.opnsense.org/manual/kea.html

• OPNsense, documentation officielle, DHCP (fin de vie d’ISC, Dnsmasq, Kea) : docs.opnsense.org/manual/dhcp.html

• OPNsense, documentation officielle, Firewall Aliases : docs.opnsense.org/manual/aliases.html

• OPNsense, Community Edition 26.7 : docs.opnsense.org/releases/CE_26.7.html

• Proxmox VE, documentation officielle sur le réseau (pont VLAN-aware) : pve.proxmox.com/wiki/Network_Configuration

• Pi-hole, documentation officielle, configuration DNS et origines autorisées : docs.pi-hole.net/ftldns/dnsmasq_warn