Remplacer l'ancien balisage VLAN avant SFOS 22 MR2

Les interfaces bridge de Sophos Firewall sont utiles pour conserver la transparence d’un réseau de couche 2 existant ou effectuer une migration sans modifier immédiatement les adresses IP. Si des balises VLAN ont auparavant été configurées sur un bridge avec system vlan-tag, remplacez-les par des interfaces VLAN dans WebAdmin avant de passer à SFOS 22.0 MR2 ou à une version ultérieure. Il ne s’agit pas d’une modification purement esthétique : sous GA et MR1, le trafic destiné au pare-feu ou généré par celui-ci peut échouer, et à partir de MR2 cette ancienne configuration bloque la mise à niveau.

Le problème NC-181672 concerne les interfaces bridge avec des configurations CLI VLAN tag sous SFOS 22.0 GA et MR1 : le trafic VLAN tagué provenant de Sophos Firewall ou qui lui est destiné n’est pas traité correctement. Cela peut affecter Active Directory, DNS, Device Access, STAS, LDAP, RADIUS ou l’accès à la gestion, même si le trafic normal est acheminé via le bridge.

Cet ancien balisage VLAN par CLI est obsolète : il bloque la mise à niveau vers SFOS 22.0 MR2 ou une version ultérieure, et une sauvegarde qui le contient ne peut pas être restaurée sous SFOS 22.0 GA ou ultérieur. Effectuez donc cette vérification avant la mise à niveau et avant de créer la sauvegarde qui lui est destinée. Le contrôle de mise à niveau SFOS 22 documente la version cible vérifiée MR2 Build 546, son chemin de mise à niveau et d’autres blocages propres à la version. Si un autre build cible est prévu, ce contrôle interne doit être actualisé avant le changement ; les données de MR2 ne doivent pas être transposées sans vérification.

Cet article n’est pas un chapitre général sur les VLAN. Pour planifier les zones, les interfaces, les VLAN, les bridges et les LAG, commencer par Configurer les zones et les interfaces sur Sophos Firewall. La procédure normale de configuration, de sécurisation et de validation est décrite dans Configurer une interface bridge sur Sophos Firewall. Cet article traite spécifiquement du cas particulier des VLAN sur bridge après SFOS 22.

Quand ce sujet est pertinent

Le contrôle prend tout son sens lorsque plusieurs points se rejoignent :

Le pare-feu fonctionne sur SFOS 22.0 GA ou SFOS 22.0 MR1.
Il existe une interface pont, par exemple br0.
Les VLAN ont été historiquement construits à l’aide d’une configuration de balise CLI VLAN comme system vlan-tag ou ont été repris à partir d’une ancienne configuration.
Les services de pare-feu eux-mêmes doivent atteindre un VLAN balisé.
Après une mise à niveau, AD, les accès DNS, authentification, surveillance ou gestion ne fonctionnent que partiellement.
Le trafic client normal via le pont semble toujours en cours.
Une mise à niveau vers SFOS 22.0 MR2 ou une version ultérieure est prévue ou bloquée par le legacy CLI VLAN tagging.

Le dernier point est important : si le pont continue à acheminer le trafic entre les réseaux, le problème ne semblera pas initialement être une défaillance du pont. En pratique, il est facile de chercher au mauvais endroit, comme dans les règles de pare-feu, DNS, STAS ou le contrôleur de domaine.

Comprendre le sens de circulation affecté

Il faut clairement séparer trois types de trafic.

Les types de trafic diffèrent considérablement :

Trafic transitant par le pont : Un client dans VLAN 100 parle à un serveur dans VLAN 100. Cela peut toujours fonctionner, mais ne prouve pas que le trafic vers le pare-feu fonctionne.
Trafic vers le pare-feu : Un client utilise le pare-feu comme serveur DNS ou destination WebAdmin. C’est précisément ce trafic qui peut être affecté car il aboutit au pare-feu.
Trafic du pare-feu : Le pare-feu interroge les destinations AD, DNS, LDAP, RADIUS, NTP ou Syslog. Ceci est également essentiel car le pare-feu lui-même est l’expéditeur.

Si une seule application est testée entre deux hôtes, l’erreur ne peut pas être identifiée avec certitude. Le test doit volontairement inclure un service qui se termine sur le Sophos Firewall ou qui est créé par le pare-feu.

Symptômes typiques

Les signes possibles sont :

Les règles basées sur l’utilisateur ne fonctionnent plus de manière fiable car AD, STAS ou LDAP ne peuvent pas être atteints de manière stable.
Les requêtes DNS adressées au pare-feu échouent à partir de VLAN individuels.
Ping ou HTTPS sur les services de pare-feu locaux ne fonctionnent pas à partir d’un VLAN, même si les règles de pare-feu semblent plausibles.
La surveillance ou Syslog apparaît incomplète si le pare-feu doit atteindre une cible dans un VLAN balisé.
Packet Capture indique que le trafic entre les systèmes finaux est visible, mais que les services de pare-feu eux-mêmes ne répondent pas comme prévu.
Après une mise à niveau SFOS-22, les symptômes apparaissent sans rien changer consciemment sur les règles du switch ou du pare-feu.

De tels symptômes ne doivent pas être immédiatement traités par des règles d’autorisation générales ou des approbations d’accès aux appareils. Tout d’abord, il doit être clair si la conception de l’interface elle-même est affectée.

Démarcation rapide avant conversion

Avant de déplacer un pont IP ou de créer de nouvelles interfaces VLAN sur le pont, vous devez en déterminer la cause. Tous les problèmes après une mise à niveau ne correspondent pas automatiquement au cas SFOS-22-Bridge-VLAN.

Classement pratique :

Une seule application entre deux hôtes ne fonctionne pas : Il est plus probable qu’il s’agisse d’une règle de pare-feu, NAT, du système cible ou du chemin de retour. Tout d’abord tester la règle de pare-feu et pour les suppressions analyser les paquets abandonnés.
WebAdmin, DNS ou ping vers le pare-feu depuis un VLAN ne fonctionne pas : Vérifiez Device Access, zone, service local ou pont VLAN cas particulier. Testez ensuite le trafic vers le pare-feu séparément.
Le pare-feu n’atteint pas AD, LDAP, RADIUS, DNS ou Syslog en VLAN : Vérifiez le trafic du pare-feu, du routage, du DNS ou du pont VLAN cas particulier. Utilisez les tests directement à partir de la configuration du pare-feu et des journaux de service appropriés.
Le trafic client normal est en cours d’exécution, mais les services du pare-feu lui-même ne le sont pas : Le cas particulier du pont VLAN devient plus probable. Vérifiez la conception du pont, l’ancienne configuration des balises CLI VLAN et l’interface VLAN pour le pont.
Il n’y a aucune entrée de journal correspondante : Vérifiez la journalisation, le filtre, le service local ou le pont non journalisé/NAT cas particulier. Combinez Log Viewer, Packet Capture et les Sophos Firewall journaux de service.

Pour les problèmes DNS, il est également important que les clients utilisent le pare-feu comme résolveur ou que le pare-feu lui-même utilise les routes de requêtes DNS vers les serveurs internes. Le deuxième cas concerne le trafic provenant du pare-feu et peut apparaître différent du trafic client normal pour les problèmes Bridge VLAN. Les bases se trouvent dans Configuration des routes de requêtes DNS sur Sophos Firewall.

Si la démarcation rapide pointe clairement vers les services de pare-feu locaux ou le trafic généré par le pare-feu, la conversion doit quand même être planifiée. Une correction de pont sans sauvegarde, fenêtre de maintenance et chemin d’accès alternatif est trop risquée pour les réseaux productifs.

Inclure la conception existante

Avant d’apporter des modifications, vous devez documenter l’état actuel. Sont particulièrement importants :

Nom de l’interface du pont, par exemple br0.
Membres du pont, c’est-à-dire les interfaces physiques participantes, les VLAN, les interfaces RED ou les LAG.
Adresse IP du pont, si disponible.
VLAN ID qui passent sur le pont.
Profil de port du switch : Tagged VLAN, Native VLAN, Trunk ou port d’accès.
Services se terminant sur le pare-feu : DNS, Ping, HTTPS, SSH, User Portal, VPN Portail.
Services que le pare-feu doit atteindre : AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoring.

Si la structure provient d’une ancienne migration, vous devez également vérifier si les VLAN ont été configurés via la configuration CLI. C’est précisément cet héritage qui est souvent oublié lorsque le pare-feu n’a été mis à jour qu’au fil des années.

⚠️ Vous ne devez pas expérimenter spontanément les interfaces de pont et les VLAN lors des opérations quotidiennes. Une modification incorrecte peut affecter l’accès à la gestion, le DNS, l’authentification ou des réseaux clients entiers. Avant la correction, une sauvegarde, une fenêtre de maintenance et un chemin d’accès alternatif sont requis.

Pièges spécifiques aux bridges avant la correction

Trois restrictions liées aux bridges doivent être vérifiées attentivement avant le changement.

Premièrement : un bridge sans adresse IP peut supprimer du trafic si ce trafic correspond à une règle de pare-feu avec filtrage web proxy ou à une règle NAT. Ces suppressions ne sont pas journalisées. Si une règle NAT reste nécessaire, elle doit être limitée de façon que la traduction source pour le bridge sans adresse IP reste sur Original. Sinon, on risque de chercher dans Log Viewer une suppression qui n’y apparaît jamais.

Deuxièmement : le VLAN filtering sur le bridge s’applique uniquement au trafic bridgé, pas au trafic routé. Si Filter VLANs est activé, mais qu’aucun VLAN ID autorisé n’est saisi, le trafic tagué de tous les VLANs est supprimé ; le trafic non tagué n’est pas concerné. Pendant les tests, cela peut ressembler à un problème VLAN incohérent.

Troisièmement : les interfaces bridge ne remplacent pas tous les designs. Des restrictions s’appliquent à Dynamic DNS, DHCP client, PPPoE et IPsec VPN. Si l’une de ces fonctions fait partie du design cible, il ne faut pas appliquer le workaround bridge de manière isolée ; le design des interfaces doit être réévalué.

Créer des interfaces VLAN prises en charge

Le workaround pris en charge consiste à créer des interfaces VLAN dans Network > Interfaces avec le bridge comme parent. Les interfaces physiques, RED, bridge et LAG sont des parents autorisés.

Avant SFOS 18.0, system vlan-tag était nécessaire pour activer le trafic VLAN tagué sur les bridges. Depuis SFOS 18.0, VLAN-over-bridge est disponible dans WebAdmin. Aucun chemin Device Console ou Advanced Shell, numéro de menu, invite ou niveau de privilège n’est précisé pour la commande CLI suivante. Utilisez uniquement le contexte CLI pris en charge du pare-feu dans lequel la commande est disponible. Si elle ne l’est pas, arrêtez-vous et consultez Sophos Support au lieu de deviner le shell ou le contexte. Vérifiez d’abord l’ancienne configuration avec cette commande en lecture seule :

system vlan-tag show

Les conceptions nouvelles ou corrigées ne doivent plus s’appuyer sur system vlan-tag. Si de telles balises CLI existent encore, il faut les documenter, les migrer vers des interfaces VLAN dans WebAdmin, puis seulement poursuivre la mise à niveau du firmware. Cela réduit à la fois le cas particulier du pont SFOS 22 et les blocages de mise à niveau ultérieurs.

Exemples :

VLAN 100 : br0.100
VLAN 200 : br0.200

Lors de la création du VLAN dans WebAdmin, trois champs sont décisifs : Interface doit être le bridge, Zone doit correspondre à l’objectif de sécurité du VLAN et VLAN ID doit être unique. WebAdmin accepte les IDs VLAN de 1 à 4094 ; le même VLAN ID ne doit pas être planifié plusieurs fois sur le même parent interface.

Le processus dépend du fait que le pont lui-même possède déjà une adresse IP.

Si le pont n’a pas besoin d’une adresse IP

Si le pont est uniquement censé transmettre de manière transparente, il peut être utilisé sans sa propre adresse IP. L’adresse IP du VLAN concerné se trouve alors sur l’interface VLAN, par exemple br0.100.

Processus pratique :

Exportez une sauvegarde à titre documentaire, mais ne comptez pas sur sa restauration pour revenir en arrière sous SFOS 22.
Documentez le pont actuel et la configuration VLAN.
Dans Network > Interfaces, choisir Add interface > Add VLAN.
Sélectionnez le pont comme interface parent, par exemple br0.
Saisissez l’ID VLAN.
Choisissez consciemment votre zone.
Définissez l’adresse IP sur l’interface VLAN si le pare-feu doit se trouver dans ce VLAN Gateway ou un service local.
Vérifiez Device Access pour la zone.
Vérifiez les règles de pare-feu et les règles NAT.
Validez la modification avec un client de test et ne créez une nouvelle sauvegarde qu’après la réussite des tests.

La zone n’est pas seulement un ordre dans le WebAdmin. Cette décision affecte les règles de pare-feu, Device Access, les journaux et de nombreuses étapes de dépannage ultérieures. Si un VLAN est destiné à être un réseau de gestion, de serveur ou de client, celui-ci doit être visible dans la zone.

Si le bridge avait auparavant l’adresse IP de production

Si le pont utilise actuellement l’adresse IP, qui devra être accessible dans VLAN à l’avenir, vous devez être particulièrement prudent. Il existe deux variantes propres pour la conversion : le pont reçoit une adresse IP différente, ou le pont reste sans adresse IP. L’adresse productive précédente est alors attribuée à l’interface VLAN.

C’est un changement avec un risque d’échec. Il convient de préciser au préalable :

Quelle adresse est utilisée pour joindre WebAdmin ?
Quels clients utilisent le pare-feu par défaut Gateway ?
Quels paramètres DNS ou DHCP pointent vers cette adresse ?
Quelles règles d’accès aux appareils s’appliquent à la zone précédente ?
Existe-t-il un deuxième accès de gestion depuis un réseau non concerné ?

Pour les sites éloignés, ce changement ne doit pas être planifié sans un chemin de retour local. Si WebAdmin et SSH passent exactement par le pont concerné IP, une erreur peut interrompre l’accès administratif.

Supprimer l’ancienne configuration et préparer la mise à niveau

Créez d’abord les interfaces VLAN requises dans Network > Interfaces avec le bridge comme parent, déplacez si nécessaire l’adresse IP du bridge vers l’interface VLAN appropriée et validez les chemins de données et d’administration. En HA, vérifiez dans l’interface d’état prise en charge que le pair et la synchronisation sont sains, et sauvegardez chaque nœud lorsque la plateforme et la procédure de support l’exigent. Si l’état est dégradé ou incertain, arrêtez-vous avant le reset ou la mise à niveau et escaladez ; n’inventez aucune commande HA ou de synchronisation. Une fois le mapping documenté, l’accès alternatif actif et les prérequis HA satisfaits, supprimez le réglage dans le même contexte CLI pris en charge décrit ci-dessus :

system vlan-tag reset

Exécutez de nouveau system vlan-tag show. Si une configuration subsiste, si le reset échoue ou si le résultat est ambigu, arrêtez : ne lancez pas la mise à niveau et n’approuvez pas la nouvelle sauvegarde comme point nettoyé. Conservez les sorties, le precheck et la configuration, puis contactez Sophos Support sans essayer de commandes non documentées. Il n’existe aucune annulation documentée de system vlan-tag reset au niveau commande : réussir les contrôles confirme le nettoyage, pas le retour arrière. Après le reset, ne recréez pas l’ancien réglage avec une commande supposée. Si le changement doit être annulé, arrêtez-vous et escaladez pour une restauration approuvée par le fournisseur sur le firmware d’origine pris en charge. Après validation, créez une nouvelle sauvegarde, relancez le precheck, puis mettez à niveau. Pour une sauvegarde restaurable, nettoyez de même le pare-feu source, créez si nécessaire l’interface VLAN, validez, puis sauvegardez. Cela ne répare pas une ancienne sauvegarde contenant system vlan-tag.

Device Access et vérifiez ensuite les règles du pare-feu

Après avoir créé l’interface VLAN, il ne suffit pas de simplement tester l’adresse IP. Device Access et les règles de pare-feu doivent correspondre à la nouvelle conception de l’interface et de la zone.

Pour vérifier :

Administration > Device access : les portails Ping/Ping6, DNS, HTTPS, SSH, User Portal ou VPN sont-ils autorisés uniquement dans les zones appropriées ?
Rules and policies > Firewall rules : Y a-t-il des règles pour la nouvelle zone ?
Rules and policies > NAT rules : le trafic est-il traduit de manière inattendue ?
Network > DNS ou routes de requête DNS : le pare-feu atteint-il les bons serveurs DNS ou AD ?
Authentication > Servers : AD, LDAP ou RADIUS sont-ils accessibles après le changement ? Pour les services de pare-feu locaux, Device Access configurer en toute sécurité Sophos Firewall est l’article approfondi approprié. Sophos Firewall Tester la règle avec Log Viewer et Packet Capture facilite l’analyse des règles.

Validation après correction

Un test propre doit contenir plus d’un ping.

Test du VLAN concerné

Vérifiez auprès d’un client dans le VLAN concerné :

Atteignez la valeur par défaut Gateway.
Testez le pare-feu IP sur la nouvelle interface VLAN via ping, si autorisé.
Testez DNS par rapport au pare-feu si le pare-feu sert de résolveur DNS.
Testez WebAdmin ou le portail uniquement à partir des réseaux de gestion autorisés.
Vérifiez une application typique ou une connexion au serveur.
Vérifiez Log Viewer pour faire correspondre l’ID de règle et la zone.

Test depuis le pare-feu

Des tests distincts sont requis pour le trafic généré par le pare-feu lui-même :

Testez les serveurs AD ou LDAP dans Authentication > Servers.
Vérifiez la résolution DNS via le pare-feu.
Vérifiez NTP, Syslog ou la cible de surveillance si ces services sont en VLAN.
Sous Diagnostics > Packet capture, vérifiez l’interface VLAN. Generated identifie les paquets créés par le pare-feu et Consumed ceux qui lui sont destinés ; comparez aussi In interface, Out interface, Rule ID, Status et Reason.

Si STAS ou les règles basées sur l’utilisateur sont affectées, Configurer STAS sur Sophos Firewall doit également être coché. Pour les mises à niveau SFOS-22, ce point appartient également au SFOS 22 Upgrade Check.

Retour arrière et clôture

Avant le changement, notez l’adresse IP et la zone du bridge, les IDs de VLAN, le profil du port du switch ainsi que les règles et services dépendants. Préparez un accès de gestion alternatif ou local et un plan de récupération approuvé par le fournisseur. Avant system vlan-tag reset, les modifications WebAdmin prévues peuvent être annulées dans l’ordre documenté : retirez d’abord l’IP de l’interface VLAN avant de la réattribuer au bridge, puis rétablissez zone, règles, Device Access et profil du switch et vérifiez la connectivité. Cela n’annule pas le reset. Après le reset, aucune annulation au niveau commande n’est documentée : en cas d’échec, arrêtez-vous et escaladez pour une restauration approuvée sur le firmware d’origine pris en charge. En HA, ne réinitialisez ni ne mettez à niveau aucun nœud si le pair ou la synchronisation est dégradé ou incertain, et conservez la sauvegarde applicable de chaque nœud.

Après validation, créer une nouvelle sauvegarde. L’ancienne sauvegarde contenant le legacy CLI VLAN tagging n’est pas un retour arrière valable sous SFOS 22.0 GA ou ultérieur. Si le precheck le signale encore, conserver la configuration et le message puis contacter Sophos Support sans tenter d’autres commandes CLI non documentées.

Erreurs courantes

Pièges typiques :

Tester le trafic client-serveur uniquement : Le pont semble sain, bien que les services de pare-feu locaux soient affectés. Testez également le trafic vers et depuis le pare-feu.
Déplacer le pont IP sans plan : WebAdmin, DNS ou Gateway peuvent échouer. Préparez la sauvegarde, les fenêtres de maintenance et les accès alternatifs.
Sélectionnez la zone de manière incorrecte pour la nouvelle interface Device Access : Les règles, Device Access et les journaux ne correspondent pas. Choisissez une zone en fonction de raisons de sécurité et non d’habitude.
Device Access ouverture trop large : Le problème semble résolu, mais les services de gestion sont inutilement accessibles. Local Service ACL plan spécifiquement.
Ne vérifiez pas le port du commutateur : VLAN arrive incorrect ou non étiqueté. Validez le profil Tagged/Untagged, Native VLAN et Trunk.
Ignorer l’ancienne configuration CLI : L’erreur reste inexpliquée après la mise à niveau. Documentez l’ancienne conception et migrez vers les interfaces WebAdmin-VLAN.

Liste de contrôle

Version SFOS et pertinence des problèmes connus vérifiées.
Interface du pont, membres du pont et identifiants VLAN documentés.
Clarification si l’ancienne configuration de balise CLI VLAN était utilisée.
Suppressions spécifiques au bridge via NAT/web proxy et VLAN filtering vérifiées.
Mise à niveau prévue vers SFOS 22.0 MR2 ou une version ultérieure vérifiée par rapport aux legacy CLI VLAN tags.
Services concernés vers et depuis le pare-feu identifiés.
Sauvegarde de chaque nœud concerné et accès de gestion alternatif disponibles ; pair et synchronisation HA sains.
Interface VLAN prévue avec bridge comme interface parent.
Zone, Device Access, règles de pare-feu et règles NAT vérifiées.
Tests effectués depuis le VLAN et depuis le pare-feu.
Limite de récupération documentée : aucune annulation documentée pour system vlan-tag reset ; nouvelle sauvegarde créée après la correction.
Résultat enregistré dans le journal des modifications ou dans la documentation réseau.

FAQ

Pourquoi le trafic normal passe-t-il via le pont, mais pas le DNS vers le pare-feu ?

Dans ce cas particulier SFOS-22, le trafic transité VLAN peut continuer à fonctionner, tandis que le trafic balisé VLAN se terminant sur ou provenant du pare-feu est affecté. Par conséquent, vous devez tester les services de pare-feu locaux séparément.

Devez-vous généralement éviter les VLAN de pont sur Sophos Firewall ?

Pas généralement. Les ponts peuvent être utiles pour les migrations ou les conceptions transparentes. Toutefois, pour les nouveaux réseaux segmentés, les interfaces VLAN distinctes avec des zones claires sont généralement plus claires et plus faciles à utiliser.

Le problème peut-il être résolu avec une règle de pare-feu ?

Pas fiable. Si la conception de l’interface est affectée, une règle d’autorisation supplémentaire ne modifiera pas la cause. Vous devez d’abord vérifier si le VLAN doit être créé correctement en tant qu’interface sur le pont.

Que devez-vous vérifier avant d'apporter des modifications au pont IP ?

Vous devez préciser si WebAdmin, DNS, DHCP, Gateway par défaut, l’authentification ou la surveillance utilisent cette adresse. De plus, une sauvegarde actuelle et un chemin d’accès alternatif sont requis.