Vérifier les Bridge-VLANs de Sophos Firewall après SFOS 22

Les interfaces de pont sur Sophos Firewall sont pratiques lorsqu’un réseau de couche 2 existant doit être maintenu de manière transparente ou lorsqu’une migration doit être effectuée sans changement immédiat d’IP. Cependant, avec des VLANs sur un pont, la conception peut rapidement devenir sujette aux erreurs : il y a alors un transfert entre les réseaux, du trafic vers le pare-feu lui-même, Device Access, DNS, AD, authentification et souvent d’anciennes configurations CLI.

C’est précisément à ce point qu’il y a un cas d’exploitation important avec SFOS 22. Sophos répertorie dans la liste actuelle des problèmes connus un problème où les interfaces de pont avec des configurations de tag VLAN CLI dans SFOS 22.0 GA et SFOS 22.0 MR1 ne traitent pas correctement le trafic VLAN tagué lorsque ce trafic provient du pare-feu Sophos lui-même ou se termine sur le pare-feu. Cela peut affecter, par exemple, Active Directory, DNS, Device Access, STAS, LDAP, RADIUS ou l’accès à la gestion, bien que le trafic normal soit transféré par le pont.

Cet article n’est pas un chapitre général sur les bases des VLANs. Pour la planification des zones, interfaces, VLANs, ponts et LAGs, commencez par Configurer les zones et interfaces de Sophos Firewall. Ici, nous nous concentrons spécifiquement sur le cas particulier des Bridge-VLANs après SFOS 22.

Quand ce sujet est-il pertinent ?

La vérification est utile lorsque plusieurs points se rejoignent :

• Le pare-feu fonctionne sur SFOS 22.0 GA ou SFOS 22.0 MR1.
• Il y a une interface de pont, par exemple br0.
• Les VLANs ont été historiquement construits par configuration de tag VLAN CLI comme system vlan-tag ou repris d’une ancienne configuration.
• Les services du pare-feu lui-même doivent atteindre un VLAN tagué.
• Après une mise à niveau, AD, DNS, authentification, surveillance ou accès à la gestion ne fonctionnent que partiellement.
• Le trafic client normal à travers le pont semble toujours fonctionner.

Le dernier point est important : si le pont continue de transférer du trafic entre les réseaux, le problème ne semble pas d’abord être une erreur de pont. En pratique, on cherche alors rapidement au mauvais endroit, par exemple dans les règles de pare-feu, DNS, STAS ou le contrôleur de domaine.

Comprendre la direction du trafic affecté

Il faut bien séparer trois types de trafic.

Si seule une application entre deux hôtes est testée, on ne détecte donc pas l’erreur de manière certaine. Le test doit consciemment inclure un service qui se termine sur le Sophos Firewall ou est généré par le pare-feu.

Symptômes typiques

Les signes possibles sont :

• Les règles basées sur les utilisateurs ne fonctionnent plus de manière fiable car AD, STAS ou LDAP ne sont pas accessibles de manière stable.
• Les requêtes DNS au pare-feu échouent depuis certains VLANs.
• Ping ou HTTPS sur les services locaux du pare-feu ne fonctionnent pas depuis un VLAN bien que les règles du pare-feu semblent plausibles.
• La surveillance ou Syslog semble incomplète lorsque le pare-feu doit atteindre une cible dans un VLAN tagué.
• Packet Capture montre que le trafic entre les systèmes finaux est visible, mais les services du pare-feu lui-même ne répondent pas comme prévu.
• Après une mise à niveau SFOS-22, les symptômes apparaissent sans qu’aucun changement conscient n’ait été fait au commutateur ou aux règles du pare-feu.

De tels symptômes ne devraient pas être immédiatement résolus avec des règles d’autorisation larges ou des autorisations Device Access. Il faut d’abord s’assurer que la conception de l’interface elle-même est affectée.

Délimitation rapide avant la modification

Avant de déplacer une IP de pont ou de créer de nouvelles interfaces VLAN sur le pont, il faut cerner la cause. Tous les problèmes après une mise à niveau ne sont pas automatiquement le cas des Bridge-VLANs SFOS-22.

Pour les problèmes DNS, il est également important de savoir si les clients utilisent le pare-feu comme résolveur ou si le pare-feu lui-même utilise des routes de requêtes DNS vers des serveurs internes. Le second cas concerne le trafic depuis le pare-feu et peut apparaître différemment des trafics clients normaux en cas de problèmes de Bridge-VLAN. Les bases sont expliquées dans Configurer les routes de requêtes DNS sur Sophos Firewall.

Si la délimitation rapide indique clairement des services locaux du pare-feu ou du trafic généré par le pare-feu, la modification doit tout de 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 en production.

Documenter la conception existante

Avant les modifications, il est important de documenter l’état actuel. Les éléments particulièrement importants sont :

• Nom de l’interface de pont, par exemple br0.
• Membres du pont, c’est-à-dire les interfaces physiques, VLANs, interfaces RED ou LAGs impliqués.
• Adresse IP du pont, si elle existe.
• IDs VLAN qui passent par le pont.
• Profil de port du commutateur : VLANs tagués, VLAN natif, port Trunk ou Access.
• Services qui se terminent sur le pare-feu : DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Services que le pare-feu doit atteindre : AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, surveillance.

Si la configuration provient d’une ancienne migration, il faut également vérifier si les VLANs ont été configurés via CLI. Ce type d’héritage est souvent oublié lorsque le pare-feu a été simplement mis à jour pendant des années.

⚠️ Il ne faut pas expérimenter spontanément avec les interfaces de pont et les VLANs pendant les heures de travail. Une modification incorrecte peut affecter l’accès à la gestion, 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 nécessaires.

Solution de contournement : Créer des interfaces VLAN sur le pont

Une méthode pratique consiste à créer des interfaces VLAN dans Network > Interfaces en utilisant l’interface de pont comme interface parente.

Exemples :

La procédure dépend de la question de savoir si le pont lui-même a déjà une adresse IP.

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

Si le pont doit simplement transférer de manière transparente, il peut être exploité sans adresse IP propre. L’adresse IP pour le VLAN concerné se trouve alors sur l’interface VLAN, par exemple br0.100.

Procédure pratique :

1. Créer une sauvegarde.
2. Documenter la configuration actuelle du pont et des VLANs.
3. Ajouter une nouvelle interface VLAN sous Network > Interfaces.
4. Sélectionner le pont comme interface parente, par exemple br0.
5. Entrer l’ID VLAN.
6. Choisir consciemment la zone.
7. Définir l’adresse IP sur l’interface VLAN si le pare-feu doit être la passerelle ou le service local dans ce VLAN.
8. Vérifier Device Access pour la zone.
9. Vérifier les règles de pare-feu et les règles NAT.
10. Valider avec un client de test.

La zone n’est pas seulement une question d’ordre dans WebAdmin. Cette décision influence les règles de pare-feu, Device Access, les journaux et de nombreux futurs dépannages. Si un VLAN est destiné à être un réseau de gestion, de serveur ou de client, cela doit être visible dans la zone.

Si le pont a actuellement l’adresse IP productive

Si le pont utilise actuellement l’adresse IP qui doit être accessible dans le VLAN à l’avenir, il faut procéder avec prudence. Pour la modification, il existe deux variantes propres : le pont reçoit une autre adresse IP, ou le pont reste sans adresse IP. L’adresse productive actuelle est ensuite attribuée à l’interface VLAN.

C’est un changement avec un risque de panne. Il faut d’abord clarifier :

• Quelle adresse est utilisée pour accéder à WebAdmin ?
• Quels clients utilisent le pare-feu comme passerelle par défaut ?
• Quelles configurations DNS ou DHCP pointent vers cette adresse ?
• Quelles règles Device Access dépendent de la zone actuelle ?
• Existe-t-il un deuxième accès de gestion depuis un réseau non affecté ?

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

Vérifier Device Access et les règles de pare-feu après

Après la création de l’interface VLAN, il ne suffit pas de tester l’adresse IP. Device Access et les règles de pare-feu doivent correspondre au nouveau design d’interface et de zone.

À vérifier :

• Administration > Device access : Ping/Ping6, DNS, HTTPS, SSH, User Portal ou VPN Portal sont-ils autorisés uniquement dans les bonnes zones ?
• 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êtes DNS : Le pare-feu atteint-il les bons serveurs DNS ou AD ?
• Authentication > Servers : AD, LDAP ou RADIUS sont-ils accessibles après la modification ?

Pour les services locaux du pare-feu, Configurer Device Access en toute sécurité sur Sophos Firewall est l’article d’approfondissement approprié. Pour l’analyse des règles, Tester la règle de pare-feu Sophos avec Log Viewer et Packet Capture est utile.

Validation après la correction

Un test propre doit inclure plus qu’un simple ping.

Test depuis le VLAN affecté

Depuis un client dans le VLAN affecté, vérifier :

1. Atteindre la passerelle par défaut.
2. Tester l’IP du pare-feu sur la nouvelle interface VLAN par ping, si autorisé.
3. Tester DNS contre le pare-feu, si le pare-feu sert de résolveur DNS.
4. Tester WebAdmin ou le portail uniquement depuis les réseaux de gestion autorisés.
5. Vérifier une application typique ou une connexion serveur.
6. Contrôler Log Viewer pour l’ID de règle et la zone appropriées.

Test depuis le pare-feu

Pour le trafic généré par le pare-feu lui-même, des tests séparés sont nécessaires :

• Tester le serveur AD ou LDAP dans Authentication > Servers.
• Vérifier la résolution DNS via le pare-feu.
• Vérifier la cible NTP, Syslog ou de surveillance si ces services se trouvent dans le VLAN.
• Utiliser Packet Capture sur l’interface VLAN si l’on n’est pas sûr que les paquets quittent le pare-feu.

Si STAS ou des règles basées sur les utilisateurs sont affectées, Configurer STAS sur Sophos Firewall doit également être vérifié. Pour les mises à niveau SFOS-22, ce point fait également partie du Contrôle de mise à niveau SFOS 22.

Erreurs fréquentes

Liste de contrôle

• Version SFOS et pertinence des problèmes connus vérifiées.
• Interface de pont, membres du pont et IDs VLAN documentés.
• Clarifié si une ancienne configuration de tag VLAN CLI a été utilisée.
• Services affectés vers le pare-feu et depuis le pare-feu identifiés.
• Sauvegarde et accès de gestion alternatif disponibles.
• Interface VLAN avec pont comme interface parente planifiée.
• Zone, Device Access, règles de pare-feu et règles NAT vérifiées.
• Tests depuis le VLAN et depuis le pare-feu effectués.
• Résultat consigné dans le journal des modifications ou la documentation réseau.

FAQ