Objectif
Créer un VLAN sur un FortiGate sans perturber les réseaux existants, en préparant la sous-interface 802.1Q, la passerelle, le DHCP éventuel, les objets d’adresses et les règles de sécurité, puis en validant le chemin complet depuis un port ou SSID pilote.
Prérequis
- VLAN ID, nom, sous-réseau, masque, passerelle et plage DHCP validés dans le plan d’adressage.
- Identification de l’interface physique ou agrégée FortiGate qui transporte le trunk 802.1Q.
- Accès aux switchs et connaissance des ports trunk/access concernés.
- Liste des flux attendus : DNS, DHCP, Internet, serveurs internes, impression, supervision et ressources métier.
- Sauvegarde récente de la configuration FortiGate et possibilité d’accès hors bande si le changement touche un lien d’administration.
Procédure pas à pas
Documenter l’état initial et les conflits potentiels
Avant toute création, relevez l’interface parent, les VLAN déjà présents, les routes et les objets proches du sous-réseau cible. Cette étape évite de réutiliser un VLAN ID déjà transporté ailleurs ou un réseau déjà référencé dans une policy, un tunnel IPsec ou un serveur DHCP. Conservez une capture de la configuration et notez précisément les ports qui devront transporter le nouveau tag.
show system interfaceget router info routing-table all- Le VLAN ID et le sous-réseau cibles ne sont pas déjà utilisés dans un contexte incompatible.
- L’interface parent et le chemin trunk jusqu’au switch d’accès sont identifiés.
Créer la sous-interface VLAN sur le FortiGate
Créez une interface de type VLAN sur l’interface parent prévue. Utilisez un nom explicite et stable afin de rendre les policies et les logs compréhensibles. Renseignez le VLAN ID exact et l’adresse de passerelle du nouveau sous-réseau. L’exemple CLI contient volontairement des placeholders : adaptez chaque valeur avant exécution.
config system interface
edit "<VLAN-NAME>"
set vdom "root"
set interface "<PARENT-TRUNK>"
set type vlan
set vlanid <VLAN-ID>
set ip <GATEWAY-IP> <NETMASK>
set allowaccess ping
next
end- L’interface VLAN apparaît active lorsque le lien parent est opérationnel.
- La table de routage contient le réseau connecté correspondant.
Créer l’objet réseau et le DHCP si nécessaire
Créez un objet d’adresse représentant exactement le sous-réseau afin de l’utiliser proprement dans les règles. Si le FortiGate fournit le DHCP, définissez une plage qui exclut la passerelle, les réservations et les équipements statiques. Si le DHCP est centralisé, utilisez un relay et vérifiez le chemin retour ainsi que les règles nécessaires.
config firewall address
edit "<VLAN-NAME>_NET"
set subnet <NETWORK-IP> <NETMASK>
next
endconfig system dhcp server
edit <ID>
set interface "<VLAN-NAME>"
set default-gateway <GATEWAY-IP>
set netmask <NETMASK>
config ip-range
edit 1
set start-ip <START-IP>
set end-ip <END-IP>
next
end
next
end- L’objet réseau représente le bon préfixe.
- Le DHCP est activé uniquement si le FortiGate doit réellement distribuer les baux.
Autoriser le VLAN sur le trunk et préparer un port pilote
Sur les switchs, ajoutez le VLAN aux trunks nécessaires sans remplacer la liste des VLAN existants. Sur le switch d’accès, configurez un seul port pilote dans le nouveau VLAN. Si le VLAN est destiné au Wi-Fi, vérifiez le mapping SSID/VLAN et le tagging jusqu’au contrôleur ou au FortiGate. Ne généralisez pas encore la configuration.
- Le tag 802.1Q est transporté de bout en bout.
- Un seul port ou SSID pilote permet de tester sans affecter le reste du parc.
Créer les firewall policies minimales
Définissez les flux selon le principe du moindre privilège. Une policy VLAN vers Internet nécessite généralement le NAT si le FortiGate est la sortie Internet ; une policy vers un serveur interne n’a normalement pas besoin de NAT. Évitez une règle ALL vers ALL comme état final et activez les logs au moins pendant le pilote.
config firewall policy
edit 0
set name "<VLAN-NAME>-to-Internet"
set srcintf "<VLAN-NAME>"
set dstintf "<WAN-INTERFACE>"
set srcaddr "<VLAN-NAME>_NET"
set dstaddr "all"
set action accept
set schedule "always"
set service "DNS" "HTTP" "HTTPS"
set nat enable
set logtraffic all
next
end- Seuls les flux nécessaires sont autorisés.
- Les accès inter-VLAN sensibles restent bloqués sans règle explicite.
Tester DHCP, passerelle, DNS et routage depuis le poste pilote
Connectez un poste au port ou SSID pilote et renouvelez son bail. Contrôlez l’adresse, le masque, la passerelle et les DNS reçus. Testez ensuite la passerelle, une ressource interne autorisée et Internet. La séquence doit distinguer un problème de couche 2, DHCP, DNS ou firewall au lieu de modifier plusieurs composants simultanément.
ipconfig /allipconfig /releaseipconfig /renewping <GATEWAY-IP>nslookup <INTERNAL-NAME>Test-NetConnection <DESTINATION> -Port <TCP-PORT>- Le poste reçoit une adresse du bon scope.
- Les flux autorisés fonctionnent et les flux non prévus restent refusés.
Lire les logs et lancer un debug ciblé si nécessaire
Si le poste reçoit bien son adresse mais qu’un flux ne traverse pas le FortiGate, commencez par les logs de policy. Pour un cas précis, utilisez un debug flow filtré sur l’IP source ou destination et arrêtez-le dès que le test est reproduit. Sur les modèles avec accélération NPU, un flux offloadé peut ne pas apparaître comme prévu : évitez de désactiver globalement l’offload sans mesurer l’impact.
diagnose debug resetdiagnose debug flow filter cleardiagnose debug flow filter saddr <CLIENT-IP>diagnose debug flow show function-name enablediagnose debug enablediagnose debug flow trace start 50diagnose debug flow trace stopdiagnose debug disablediagnose debug reset- Le debug indique la route et la policy utilisées ou la raison du drop.
- Le debug est stoppé et réinitialisé après le test.
Étendre le VLAN par vagues et documenter
Une fois le pilote stable, étendez progressivement le VLAN aux ports, AP ou hyperviseurs concernés. Contrôlez le volume de baux DHCP, les logs de sécurité et les équipements qui utilisaient encore des IP statiques. Mettez à jour le plan IP, le schéma réseau, les trunks et la matrice de flux afin que le VLAN reste maintenable.
- Chaque vague est validée avant la suivante.
- Le plan d’adressage et la matrice de flux reflètent l’état réel.
Validation
La procédure est validée lorsque :
- Un poste pilote reçoit une adresse du bon VLAN, atteint la passerelle et résout les noms attendus.
- La route connectée et les policies FortiGate correspondent au nouveau réseau.
- Les trunks transportent le VLAN uniquement sur les liens nécessaires.
- Les flux autorisés fonctionnent, les flux non prévus restent bloqués et les logs ne montrent pas de drop inexpliqué.
Retour arrière
- Retirer d’abord les ports/SSID pilotes du nouveau VLAN afin de stopper tout nouveau trafic utilisateur.
- Supprimer ou désactiver les policies créées, puis le DHCP/relay et les objets devenus inutiles.
- Retirer le VLAN des trunks et supprimer la sous-interface seulement après avoir vérifié qu’aucun équipement ne l’utilise.
- Restaurer la sauvegarde de configuration si plusieurs dépendances ont été modifiées et que le retour manuel n’est plus maîtrisé.
Dépannage / erreurs fréquentes
- Pas de DHCP : vérifier le VLAN access du port, le trunk, le VLAN ID FortiGate et le serveur/relay DHCP avant la firewall policy.
- Le poste ping la passerelle mais pas Internet : vérifier policy, route par défaut, NAT et DNS séparément.
- Le debug flow ne montre rien : confirmer que le trafic atteint le FortiGate et tenir compte de l’offload NPU ; utiliser aussi une capture ciblée.
- Un seul sens fonctionne entre VLANs : rechercher une route asymétrique, une policy inverse manquante ou un équipement intermédiaire qui ne transporte pas le tag.