Table of Contents

Architecture Homelab

Cette page documente la topologie physique et logique de mon réseau personnel.

Diagramme Réseau

Plan d'adressage (IPAM)

VLAN ID Nom du réseau Sous-réseau (CIDR) Passerelle (OPNsense) Remarques
VLAN 10 Trusted 192.168.10.0/24 192.168.10.1 Réseau principal
VLAN 20 Guests 192.168.20.0/24 192.168.20.1 Isolé du réseau Trusted
VLAN 30 IoT_Gaming 192.168.30.0/24 192.168.30.1 Objets connectés, consoles de jeu, accès internet restreint
VLAN 40 Homelab 192.168.40.0/24 192.168.40.1 Proxmox et services homelab
Équipement IP Fixe Remarques
OPNsense (LAN) 192.168.10.1 Interface igc1
OPNsense (WAN) DHCP (Publique) Interface igc0 (Liée au port 4 Freebox), lien 2.5GbE
MikroTik CRS310-8G+2S+IN 192.168.10.2 Interface vlan10-mgmt, remplace le Cisco 2960
TP-Link EAP225 192.168.10.5 Géré en Trunk, VLAN 10 natif (untagged), VLAN 20/30 tagués
Proxmox (VLAN 40) Access sur ether2 du CRS310, passage en trunk prévu à terme

Switch MikroTik CRS310-8G+2S+IN

Remplace le Cisco Catalyst 2960 (décommissionné). RouterOS 7.24.2. Modèle de VLAN basé sur un bridge unique avec table VLAN centralisée (voir note ci-dessous sur la différence avec Cisco IOS).

Port Rôle Mode PVID VLANs taguées VLAN untagged
ether1 AP TP-Link EAP225 Trunk avec natif 10 20, 30 10
ether2 Proxmox Access 40 — 40
ether3 Poste utilisateur Access 10 — 10
ether4 Uplink OPNsense Trunk pur 1 (neutre) 10, 20, 30, 40 —
ether5–8, sfp-sfpplus1–2 Libres — 1 aucune aucune

Note technique — modèle RouterOS vs Cisco IOS : RouterOS ne fonctionne pas port par port comme l'IOS (switchport mode access/trunk). Un bridge unique porte une table VLAN centralisée qui déclare, pour chaque VLAN ID, quels ports sont tagged= et lesquels sont untagged=. Le PVID par port ne classe que le trafic untagged entrant — il n'a aucun effet sur le trafic sortant taggé. Un port ne peut jamais être à la fois tagged= et untagged= pour la même VLAN.

Configuration de référence (état de production) :

/interface bridge
add admin-mac=38:32:7A:32:8C:9A auto-mac=no name=bridge vlan-filtering=yes

/interface vlan
add interface=bridge name=vlan10-mgmt vlan-id=10

/interface bridge port
add bridge=bridge comment=Link-To-Wifi interface=ether1 pvid=10
add bridge=bridge comment=PROXMOX interface=ether2 pvid=40
add bridge=bridge comment=Poste-utilisateur interface=ether3 pvid=10
add bridge=bridge comment=Uplink-OPNsense interface=ether4

/interface bridge vlan
add bridge=bridge comment=VLAN-TRUSTED tagged=ether4 untagged=ether3,ether1 vlan-ids=10
add bridge=bridge comment=VLAN-GUEST tagged=ether1,ether4 vlan-ids=20
add bridge=bridge comment=VLAN-IOT tagged=ether1,ether4 vlan-ids=30
add bridge=bridge comment=VLAN-HOMELAB tagged=ether4 untagged=ether2 vlan-ids=40

/ip address
add address=192.168.10.2/24 interface=vlan10-mgmt network=192.168.10.0

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.10.1

/ip dns
set servers=192.168.10.1

Troubleshooting & Procédures

Perte de connectivité WAN sur OPNsense

Symptôme : Après le passage de la Freebox en mode “Bridge”, l'interface WAN (igc0) d'OPNsense ne récupère plus d'adresse IP publique et la connexion internet est coupée.

Explication : Il ne s'agit pas d'un problème de configuration logicielle sur OPNsense, mais d'une limitation matérielle de la Freebox en mode bridge.

Résolution :

  1. Côté physique : Le câble réseau reliant l'interface WAN de l'OPNsense à la Freebox doit impérativement être branché sur le port Ethernet 4 de la Freebox.

  1. Redémarrer l'interface WAN ou redémarrer OPNsense si le bail DHCP public n'est pas renouvelé immédiatement.

Impossible de joindre un SSID spécifique (ex: Trusted)

Symptôme : Les appareils se connectent au SSID “Trusted” diffusé par l'AP TP-Link EAP225, mais n'obtiennent pas d'adresse IP (pas de DHCP), ou récupèrent une IP hors plan d'adressage (ex: 192.168.2.x) — signe que l'AP est retombé en fallback DHCP/NAT usine faute de VLAN natif joignable.

Explication : L'AP envoie le SSID Trusted en trafic untagged sur son port trunk. Si aucune VLAN n'est déclarée untagged sur ce port côté switch, ce trafic est classé dans un VLAN neutre inexistant et droppé — l'AP ne reçoit plus de réponse DHCP et bascule en mode autonome.

Résolution (MikroTik CRS310) :

  1. Déclarer le VLAN 10 comme untagged en plus de son statut tagué existant sur le port trunk (ether1), en une seule commande pour éviter le conflit tagged/untagged :
/interface bridge vlan set [find vlan-ids=10] tagged=ether4 untagged=ether3,ether1
/interface bridge port set [find interface=ether1] pvid=10

Résolution (ancien Cisco 2960, conservé pour référence) :

  1. Déclarer le VLAN Trusted (VLAN 10) comme VLAN natif (Native VLAN) sur le port Trunk du switch Cisco.
  1. Exemple de configuration Cisco :
Switch> enable
Switch# configure terminal
Switch(config)# interface FastEthernet 0/1
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk native vlan 10
Switch(config-if)# end
Switch# copy running-config startup-config

PVID appliqué par erreur sur un port trunk déjà taggé (MikroTik)

Symptôme : Perte de connectivité sur un port trunk après ajout d'un PVID, alors que le port fonctionnait avant.

Explication : Ajouter un PVID correspondant à une VLAN sur un port déjà listé en tagged= (et pas untagged=) pour cette même VLAN crée une asymétrie : le trafic entrant est classé par le PVID, mais le trafic sortant reste taggé. Un client qui ne parle pas 802.1Q (PC, AP mal configuré) perd la connectivité.

Règle à retenir : un port trunk pur (tagged sur toutes ses VLANs) n'a besoin d'aucun PVID pertinent. Un port trunk avec VLAN native doit avoir cette VLAN à la fois en untagged= dans la table et en PVID sur le port — jamais l'un sans l'autre.

Résolution : rebrancher temporairement sur un port access fonctionnel (ex: ether3) pour reprendre la main via l'IP de management, puis corriger :

/interface bridge port set [find interface=<port concerné>] pvid=1

Lien 2.5GbE négocié en 1Gbps (OPNsense ↔ CRS310)

Symptôme : /interface ethernet monitor sur le port switch affiche rate=1Gbps malgré un CRS310 (8 ports 2.5GBASE-T) et une interface OPNsense toutes deux capables de 2.5G, avec du câblage Cat6 sur toute l'infra.

Explication : Le port switch annonçait correctement advertising: 2.5G-baseT, mais link-partner-advertising ne montrait que 1G-baseT-full — le plafond venait de la négociation côté OPNsense (interface LAN laissée en médiat forcé ou en mauvais port), pas du switch ni du câblage.

Résolution :

  1. Dans OPNsense : Interfaces → [interface concernée] → Media, repasser en autoselect (ou forcer 2.5Gbase-T <full-duplex> si l'autoselect ne suffit pas).
  2. Vérifier après application : ifconfig <interface> media côté OPNsense, et /interface ethernet monitor ether4 côté CRS310 — les deux doivent annoncer et négocier 2.5G.
  3. Cause fréquente sur ce type de souci : mauvais port physique assigné à l'interface LAN dans Interfaces → Assignments, notamment quand la carte réseau expose plusieurs ports de vitesses différentes.