Sophos Firewall Vérifier les VLAN de pont pour SFOS 22

Les interfaces de pont sur Sophos Firewall sont pratiques si un réseau de couche 2 existant doit être poursuivi de manière transparente ou si une migration doit être mise en œuvre sans modifications IP immédiates. Cependant, avec des VLAN sur un pont, la conception devient rapidement sujette aux erreurs : il y a ensuite le transfert entre les réseaux, le trafic vers le pare-feu lui-même, Device Access, DNS, AD, l’authentification et souvent d’anciennes configurations CLI.

Exactement à ce stade, il existe un cas de fonctionnement important avec SFOS 22. Sophos répertorie un problème dans la liste actuelle des problèmes connus où les interfaces de pont avec des configurations de balises CLI VLAN dans SFOS 22.0 GA et SFOS 22.0 MR1 ne traitent pas correctement le trafic balisé VLAN si ce trafic provient du Sophos Firewall lui-même ou se termine sur le pare-feu. Par exemple, 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 pont.

Sophos décrit désormais aussi le legacy CLI VLAN tagging comme deprecated. Ces configurations héritées peuvent empêcher les mises à niveau vers SFOS 22.0 MR2 et les versions ultérieures. Cette vérification n’est donc pas seulement du troubleshooting après une mise à niveau, mais aussi une préparation utile avant la prochaine fenêtre de maintenance.

Cet article n’est pas un chapitre général sur les principes fondamentaux VLAN. Pour planifier les zones, les interfaces, les VLAN, les ponts et les LAG, Sophos Firewall Configurer les zones et les interfaces convient en premier. Il s’agit spécifiquement du cas particulier du pont VLAN 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

Sophos décrit trois restrictions liées aux bridges qu’il faut vérifier consciemment 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. Selon Sophos, 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. Sophos mentionne des restrictions pour 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é.

Solution et préparation de la mise à niveau

Un moyen pratique consiste à créer des interfaces VLAN dans Network > Interfaces en utilisant l’interface pont comme interface parent.

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. Sophos autorise les IDs VLAN WebAdmin 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 :

Créez une sauvegarde.
Documentez le pont actuel et la configuration VLAN.
Ajoutez une nouvelle interface VLAN sous Network > Interfaces.
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 avec un client de test.

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.

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.
Utilisez Packet Capture sur l’interface VLAN lorsqu’il n’est pas clair si les paquets quittent le pare-feu.

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.

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.
Accès de sauvegarde et de gestion alternative disponible.
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.
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.