OPNsense + Tailscale : fondations réseau du homelab

OPNsense transforme un simple mini-PC en pare-feu professionnel. Combiné à Tailscale, vous accédez à votre homelab depuis n'importe où, sans exposer de port sur Internet. Ce guide pose les fondations réseau actuelles du homelab, avec une évolution prévue vers la segmentation VLAN.

Ce que vous allez mettre en place

À la fin de ce parcours, vous aurez :

Un pare-feu OPNsense sur un mini-PC dédié (ou VM)
Un LAN d'administration initial en 192.168.10.0/24
Un accès distant sécurisé avec Tailscale pour ne jamais perdre la main
Une base réseau propre avec DNS interne et règles simples
Une segmentation VLAN prévue pour la suite du parcours

Prérequis

Élément	Recommandation
Machine OPNsense	Mini-PC avec 2+ NICs (Intel N100 4-port idéal) ou VM avec 2 interfaces
Switch	Même un switch non-manageable suffit pour démarrer
Compte Tailscale	Gratuit sur tailscale.com
Temps estimé	1–2 heures pour une config de base

Pourquoi commencer par le réseau ?

Dans une architecture security-first, le réseau n'est pas "un truc à configurer plus tard". C'est la fondation sur laquelle tout le reste s'appuie :

Sans OPNsense	Avec OPNsense
Box FAI = routeur + firewall	Contrôle total des règles et des logs
DNS de la box (lent, logs chez le FAI)	DNS local, résolution interne, logs chez vous
VPN propriétaire ou aucun	WireGuard natif ou Tailscale intégré
Aucune visibilité sur le trafic	Logs, métriques, IDS Suricata
Segmentation impossible	VLANs possibles dès que nécessaire

Architecture cible

Le schéma qui suit sert de carte de destination, pas de plan à appliquer aujourd'hui. Regardez d'abord la position d'OPNsense : il s'intercale entre la box FAI et le switch, ce qui fait passer tout le trafic interne par un point de contrôle unique. C'est ce placement qui rend possibles les règles de filtrage, les logs et, plus tard, l'isolation des VLANs. Le second point à repérer est Tailscale : il se greffe sur OPNsense lui-même, pas sur chaque machine, ce qui explique pourquoi un seul nœud suffit à exposer tout le LAN.

Architecture réseau OPNsense avec VLANs et Tailscale

Étape 1 : Installer OPNsense

OPNsense s'installe comme n'importe quel OS : téléchargez l'image, vérifiez son empreinte SHA-256, bootez dessus, suivez l'assistant. Deux variantes existent pour l'architecture amd64 : l'image vga (.img) destinée aux clés USB, et l'image dvd (.iso) pensée pour un lecteur optique ou une VM. Pour un mini-PC, prenez la vga.

Téléchargez l'image et son fichier de sommes

Rendez-vous sur opnsense.org/download, choisissez amd64 puis le type d'image. Récupérez au passage le fichier OPNsense-<version>-checksums-amd64.sha256 publié dans le même répertoire du miroir.
Vérifiez l'empreinte avant toute écriture

Les images sont distribuées compressées en bzip2. Le fichier de sommes porte sur l'archive .bz2, il faut donc contrôler l'empreinte avant de décompresser.
Fenêtre de terminal
```
sha256sum --check --ignore-missing OPNsense-26.7-checksums-amd64.sha256
```
La sortie doit afficher OPNsense-26.7-vga-amd64.img.bz2: OK. Toute autre réponse signifie un téléchargement corrompu ou altéré : recommencez, n'écrivez rien sur la clé.

Décompressez puis créez la clé USB bootable

bzip2 -d OPNsense-26.7-vga-amd64.img.bz2

# Remplacez /dev/sdX par le périphérique réel, vérifié avec lsblk
sudo dd if=OPNsense-26.7-vga-amd64.img of=/dev/sdX bs=1M conv=fsync status=progress

Sous Windows, Rufus ou balenaEtcher acceptent directement l'image décompressée.

Installez sur le mini-PC
- Branchez la clé USB, démarrez le mini-PC
- Suivez l'assistant d'installation
- Choisissez le disque cible (NVMe/SSD)
- Définissez le mot de passe root
Configurez les interfaces (console)

Au premier boot, assignez les interfaces :
- WAN = interface vers la box FAI
- LAN = interface vers le switch/réseau interne

Guide détaillé : Installer OPNsense

Étape 2 : Mettre en place le LAN initial

À ce stade, l'objectif n'est pas encore de segmenter tout le homelab en VLANs. Je commence par un LAN unique en 192.168.10.0/24, suffisamment simple pour valider OPNsense, l'accès au réseau interne, les premiers services et l'administration distante.

Configuration de départ

Les quatre valeurs ci-dessous se fixent une fois pour toutes, parce que changer un plan d'adressage après coup oblige à reprendre les baux DHCP, les enregistrements DNS et les règles de filtrage. Le choix de 192.168.10.0/24 plutôt que le classique 192.168.1.0/24 évite un conflit fréquent : quand vous vous connectez à un réseau tiers qui utilise déjà 192.168.1.0/24, le routage Tailscale vers votre homelab devient ambigu et cesse de fonctionner.

Élément	Valeur
Interface LAN	interface interne d'OPNsense
Réseau	`192.168.10.0/24`
Passerelle OPNsense	`192.168.10.1`
Usage	administration, Proxmox, premiers services

Ce que cette base permet

Un LAN plat n'est pas une architecture définitive, mais il rend testables les quatre briques qui doivent fonctionner avant toute segmentation. Tant que ces quatre points ne sont pas verts, ajouter des VLANs revient à empiler un problème de routage inter-segments sur un problème de base non diagnostiqué. Traitez donc cette liste comme une porte de sortie : chaque ligne se valide indépendamment des autres.

Avec ce LAN unique, vous pouvez déjà :

Connecter Proxmox et les premières machines
Administrer OPNsense et le switch
Tester la résolution DNS locale
Accéder au homelab à distance avec Tailscale

Configuration DHCP (optionnelle)

Vous pouvez activer le serveur DHCP d'OPNsense sur ce LAN pour distribuer automatiquement les adresses. Le point qui compte ici est la plage : en la démarrant à .100, vous réservez tout l'espace .1 à .99 aux adresses statiques de vos équipements d'infrastructure. Sans cette séparation, un bail DHCP finit tôt ou tard sur l'IP que vous aviez fixée à la main sur Proxmox, et le service devient injoignable au pire moment.

Plage : 192.168.10.100 à 192.168.10.200
Passerelle : 192.168.10.1
DNS : 192.168.10.1 (OPNsense)

Les machines principales (Proxmox, switch, hyperviseurs) gardent une IP statique hors de cette plage. Pour les postes de passage, le DHCP suffit.

Étape 3 : Poser les premières règles réseau

Avec un seul LAN, la configuration firewall reste simple. L'objectif est de sécuriser les flux de base avant de passer à la suite.

Règles essentielles sur le LAN

Trois règles sont créées automatiquement à l'installation, et c'est la troisième qui mérite votre attention. La règle anti-lockout est ce qui vous empêche de vous couper l'accès à l'interface web en vous trompant dans un filtre. Certains tutoriels conseillent de la désactiver pour « durcir » la configuration : ne le faites pas tant que vous n'avez pas un accès console physique vérifié, sinon la moindre erreur de règle transforme le pare-feu en boîte noire injoignable.

Pour un LAN unique, les règles par défaut d'OPNsense suffisent généralement :

Règle	Effet
LAN → Internet	Accès sortant autorisé (mises à jour, navigation)
LAN → OPNsense	Administration de l'interface web
Anti-lockout	Empêche de se couper l'accès à OPNsense

Ce que vous pouvez ajuster

Ces trois ajustements se prennent dans cet ordre, du moins risqué au plus risqué. Activer les logs ne casse rien et vous donne la matière pour décider ensuite quoi bloquer : sans observation préalable, un blocage de ports sortants coupe presque toujours un service dont vous ignoriez la dépendance. Le troisième point, restreindre l'accès à l'interface d'administration, se teste depuis la machine concernée avant d'être appliqué, sinon vous vous exposez au verrouillage décrit plus haut.

Même avec un LAN unique, quelques ajustements peuvent être utiles :

Bloquer certains ports sortants si vous souhaitez restreindre les flux
Limiter l'accès à l'interface OPNsense à certaines IPs
Activer les logs sur les règles pour observer le trafic

Guide détaillé : Administration OPNsense

Étape 4 : Accéder au homelab avec Tailscale

Avant d'aller plus loin, assurez-vous de toujours avoir un moyen d'accéder à votre homelab depuis l'extérieur. C'est une sécurité essentielle : si vous perdez l'accès local, vous pouvez quand même intervenir.

Pourquoi Tailscale

Dans mon homelab, j'utilise Tailscale pour l'accès distant. L'argument décisif n'est pas la rapidité d'installation mais l'absence de port ouvert sur la box : le nœud sort en connexion sortante vers les serveurs de coordination, puis établit un tunnel WireGuard direct avec vos autres appareils. La surface d'attaque exposée sur Internet reste donc nulle, là où un VPN auto-hébergé impose une redirection de port et un service en écoute permanente.

Installation via le plugin OPNsense
Pas de port à ouvrir sur la box FAI
Traverse les NAT complexes automatiquement
Plan Personal gratuit jusqu'à 6 utilisateurs sur un même tailnet

Configuration de base

Les quatre étapes ci-dessous forment une séquence : les trois premières se font dans OPNsense, la quatrième dans la console d'administration Tailscale. C'est cette dernière qui piège le plus de monde. Annoncer une route depuis OPNsense ne suffit pas, elle reste inactive tant qu'un administrateur ne l'a pas approuvée côté tailnet, et rien dans l'interface OPNsense ne signale cette attente.

Installez le plugin Tailscale depuis OPNsense (System → Firmware → Plugins)
Connectez-vous à votre compte Tailscale via l'interface OPNsense
Activez le subnet routing pour exposer votre LAN (192.168.10.0/24)
Approuvez les routes dans la console admin Tailscale

Une fois configuré, vous pouvez accéder à OPNsense, Proxmox et toutes vos machines depuis n'importe où via leur IP locale (192.168.10.x).

Guide détaillé : Tailscale + OPNsense

Étape 5 : Ajouter le DNS interne

Même avec un LAN unique, un DNS interne est très utile. Il permet de résoudre des noms locaux plutôt que de retenir des IPs.

Exemples de résolution locale

Le tableau donne une convention de nommage, pas une configuration à copier. Le point à retenir est le suffixe : lab.local est lisible mais .local est réservé par mDNS (le protocole derrière Avahi et Bonjour), ce qui provoque des résolutions erratiques sur les postes macOS et sur les distributions qui activent nss-mdns. Un domaine que vous possédez, ou un sous-domaine interne du type lab.exemple.fr, évite complètement ce conflit.

Nom	IP
`opnsense.lab.local`	`192.168.10.1`
`proxmox.lab.local`	`192.168.10.10`
`authentik.lab.local`	`192.168.10.20`
`openbao.lab.local`	`192.168.10.21`

Configuration avec Unbound

Unbound est le résolveur DNS récursif livré par défaut avec OPNsense, actif dès l'installation. Vous n'avez donc rien à installer : le travail consiste à lui ajouter vos enregistrements statiques (Services, Unbound DNS, Overrides) et, si vous le souhaitez, à activer le blocage. Attention à un effet de bord : les listes de blocage publicitaire s'appliquent à tout le LAN, y compris aux serveurs, et un faux positif sur un domaine de dépôt logiciel casse silencieusement vos mises à jour.

Résoudre des noms locaux : proxmox.lab.local vers 192.168.10.10
Bloquer la pub (avec des listes de blocage)
Améliorer la vie privée (DNS over TLS vers des serveurs de confiance)

Activez-le dès maintenant ou après avoir déployé vos premières VMs.

Guide détaillé : Gestion des plugins OPNsense

Étape 6 : Préparer la future segmentation VLAN

Une fois le LAN initial validé, l'étape suivante consistera à séparer les usages avec des VLANs dédiés. Cette segmentation n'est pas encore en place, mais voici ce qui est prévu.

Plan de segmentation cible

Ce plan bascule volontairement du préfixe 192.168.10.0/24 vers l'espace 10.0.x.0/24. Ce n'est pas un détail cosmétique : passer aux VLANs implique de renuméroter, donc autant profiter de l'opération pour aligner l'ID de VLAN sur le troisième octet du subnet. Un paquet capturé sur le trunk avec le tag 30 se rattache alors immédiatement à 10.0.30.0/24, ce qui accélère tous les diagnostics futurs. La colonne à lire en priorité est Usage : c'est elle qui déterminera les règles d'isolation, le VLAN IOT n'ayant par exemple aucune raison d'atteindre MGMT.

VLAN	ID	Subnet	Usage
MGMT	10	`10.0.10.0/24`	Administration (OPNsense, Proxmox, switches)
SERVERS	20	`10.0.20.0/24`	VMs et conteneurs
IOT	30	`10.0.30.0/24`	Objets connectés, isolés

Ce qui changera

Le changement matériel est le seul qui coûte de l'argent, et c'est aussi celui qui bloque tout le reste : sans switch capable de gérer le 802.1Q, aucune des deux autres évolutions n'est réalisable. Prévoyez également une coupure de service le jour de la bascule, puisque le port qui relie OPNsense au switch devient un trunk et cesse de fonctionner en mode accès.

Le switch passera en mode manageable avec des ports VLAN
Les règles firewall isoleront les segments
Le trunk entre OPNsense et le switch portera tous les VLANs

Guides pour la suite :

Administration OPNsense

Valider que la base est saine

Avant de passer au déploiement du premier nœud Proxmox admin, vérifiez que vos fondations réseau fonctionnent.

Checklist minimale

Cochez ces cinq points dans l'ordre, car ils vont du plus local au plus distant et chaque échec renseigne sur le précédent. Si l'accès Internet ne passe pas alors qu'OPNsense répond en local, le problème se situe côté WAN ou passerelle, pas côté LAN. Le dernier point n'est pas un test mais une précaution : l'accès console physique est ce qui vous sauve quand les quatre autres tombent en même temps.

OPNsense accessible localement (https://192.168.10.1)
Interfaces assignées : WAN et LAN correctement configurés
Accès Internet fonctionnel depuis le LAN
Accès distant opérationnel : Tailscale connecté
Accès de secours prévu : console physique sur le mini-PC OPNsense

Tests simples

Le premier bloc se lance depuis une machine du LAN et sépare deux causes de panne. Un ping qui aboutit sur 192.168.10.1 mais échoue sur 8.8.8.8 isole le problème sur le WAN ou le NAT sortant. À l'inverse, si les deux ping passent mais que la navigation web reste bloquée, la cause est la résolution DNS, pas le routage.

# Depuis une machine sur le LAN
ping 192.168.10.1    # Gateway OPNsense
ping 8.8.8.8         # Sortie Internet

Le second bloc se joue depuis l'extérieur, sur un appareil connecté au même tailnet. tailscale status doit d'abord lister le nœud OPNsense comme joignable. Si ce nœud apparaît bien mais que le ping vers 192.168.10.1 reste sans réponse, la cause n'est presque jamais le pare-feu : c'est la subnet route qui n'a pas été approuvée dans la console d'administration Tailscale. Vérifiez-le sur la page Machines avant de toucher à la moindre règle.

# Depuis l'extérieur (via Tailscale)
tailscale status
ping 192.168.10.1    # OPNsense via Tailscale

Dépannage courant

Les trois pannes ci-dessous couvrent la quasi-totalité des blocages rencontrés sur cette base. Le point commun de leur résolution : on repart toujours du niveau le plus bas accessible, la console physique ou l'interface WAN, plutôt que de modifier des règles à l'aveugle.

"Je n'accède plus à OPNsense après un changement"

C'est le scénario du verrouillage : une règle ou un changement d'adressage vous a coupé de l'interface web. La console série ou VGA reste accessible parce qu'elle ne dépend d'aucune configuration réseau, et son menu numéroté permet de réaffecter une adresse en quelques secondes. Notez que le menu console d'OPNsense propose aussi l'option de réinitialisation des règles de pare-feu aux valeurs d'usine, utile quand vous ne savez plus quelle règle a provoqué la coupure.

Connectez-vous à la console (écran + clavier directement sur le mini-PC)
Tapez 2 pour "Set interface IP address"
Réaffectez une IP sur l'interface LAN (192.168.10.1)
Accédez à l'interface web et corrigez

"Pas d'accès Internet depuis le LAN"

Ces trois vérifications se font dans cet ordre parce qu'elles remontent la chaîne : sans adresse sur le WAN, la passerelle est forcément absente, et tester le ping avant les deux autres ne vous apprendrait rien. Le ping depuis la console d'OPNsense est décisif car il élimine le LAN de l'équation. S'il aboutit alors que la même commande échoue depuis un poste interne, la panne est côté NAT sortant ou DNS, pas côté connexion opérateur.

Vérifiez que l'interface WAN a bien une IP (DHCP ou statique)
Vérifiez la passerelle par défaut dans OPNsense
Testez un ping depuis la console OPNsense : ping 8.8.8.8

"Tailscale ne voit pas les subnet routes"

Une subnet route demande deux accords indépendants : le nœud doit l'annoncer, et un administrateur doit l'approuver. Les deux étapes vivent dans des interfaces différentes, ce qui explique la fréquence de cette panne. Commencez par la console d'administration : l'annonce côté OPNsense est en général correcte, c'est l'approbation qui manque.

Dans la console admin Tailscale, approuvez les routes de votre machine OPNsense
Dans OPNsense, vérifiez que "Advertise Routes" contient votre subnet (192.168.10.0/24)

À retenir

OPNsense d'abord : c'est la fondation sur laquelle tout le reste s'appuie
Commencez par un LAN unique : validez la base avant de segmenter
Vérifiez l'empreinte SHA-256 de l'image avant d'écrire la clé USB
Tailscale dès le départ : accès distant sans port exposé sur la box
Une route annoncée n'est pas une route active : l'approbation se fait côté console Tailscale
DNS interne utile immédiatement : même avec un seul réseau
VLANs ensuite : une fois la fondation solide, la segmentation devient traitable
Ne vous enfermez jamais : console physique et Tailscale sont vos deux voies de secours

Prochaines étapes

Premier nœud Proxmox admin Déployez authentik et OpenBao sur un nœud dédié

Formation OPNsense complète Architecture, installation, administration et greffons du pare-feu

Guide Tailscale détaillé Mesh WireGuard, ACL grants, exit node, subnet router, MagicDNS et Headscale souverain