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

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).

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

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.

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

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

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.