Configurer et tester une interface bridge sur Sophos Firewall

Une interface bridge relie plusieurs interfaces physiques ou virtuelles en couche 2. Une Sophos Firewall peut ainsi être insérée de manière transparente dans un chemin existant ou servir de gateway bridge routée de façon délibérée. La décision centrale précède la création : la bridge doit-elle uniquement transférer des frames ou posséder une adresse IP et router elle-même ?

⚠️ Une configuration bridge incorrecte peut provoquer une boucle de couche 2, une broadcast storm ou la perte de l’accès de gestion. Avant le câblage, il faut une sauvegarde, une fenêtre de maintenance, un accès administrateur indépendant et un chemin de secours clair. Les chemins redondants de couche 2 ne sont activés qu’une fois la conception STP et HA clarifiée.

Transparente ou routée

Une bridge transparente sans adresse IP transfère les frames entre ses members. Elle peut relier des réseaux sans agir comme gateway. Ce mode convient aux migrations contrôlées ou à un chemin inline où l’architecture IP existante doit rester inchangée.

Une bridge routée avec adresse IP est activée avec Enable routing on this bridge pair. Son IP peut alors servir de gateway ou d’endpoint local du pare-feu. Le filtrage VLAN de la bridge s’applique uniquement au trafic bridged, pas au trafic routé.

Sur les modèles XGS compatibles, une paire de ports bridge fixe au niveau matériel peut aussi servir de chemin Fail-to-Wire. Configurer et tester LAN Bypass de manière contrôlée explique la limite des modèles, la paire FTW, le trafic non analysé pendant la panne et le retour au fonctionnement protégé. Deux members quelconques ne reçoivent pas cette fonction matérielle.

Une bridge ne remplace pas universellement une interface WAN ou VPN dédiée. Sophos ne prend en charge ni Dynamic DNS, ni DHCP client, ni PPPoE, ni IPsec VPN sur les interfaces bridge. Pour de nouveaux réseaux segmentés, VLAN et routing sont souvent plus simples à exploiter. Zones et interfaces sur Sophos Firewall explique le choix entre alias, bridge, LAG, VLAN, XFRM et RED.

Planifier l’exemple et les members

L’exemple relie Port3 et Port4 de manière transparente. Les deux ports se trouvent sur le même chemin de couche 2 planifié et la bridge ne reçoit aucune adresse IP. Ces valeurs d’exemple sont remplacées par le câblage, les zones et la stratégie de gestion réels.

SFOS autorise jusqu’à 64 members. Il peut s’agir d’interfaces physiques, RED, LAG et d’interfaces VLAN sur une interface physique, RED ou LAG. Vérifier au préalable chaque member pour les adresses IP, VLAN, DHCP, NAT, règles, routing et accès administratifs existants.

Les zones des members restent pertinentes pour les règles de pare-feu. Une bridge n’autorise pas automatiquement le trafic. Si les deux members se trouvent par exemple dans LAN, le flux souhaité peut encore nécessiter une règle LAN-to-LAN appropriée.

Contrôles avancés de la bridge dans la Device Console

La configuration habituelle de la bridge reste dans WebAdmin. La Device Console fournit en plus trois contrôles globaux ou de bas niveau. Avant de les utiliser, sauvegarder le nom de la bridge, le hardware name, les members, les ID de port, la table MAC, le chemin d’administration et l’état CLI actuel. Ces commandes ne remplacent pas des règles de pare-feu manquantes ni un design de Layer 2 non résolu.

Traiter le trafic inconnu non routable

bypass-firewall-policy s’applique au trafic de bridge non routable auquel aucune Security Policy n’est appliquée. SFOS distingue dynamic et static. Commencer par lire l’état actuel des deux catégories :

system bridge bypass-firewall-policy unknown-network-traffic show dynamic
system bridge bypass-firewall-policy unknown-network-traffic show static

Les actions disponibles sont allow et drop. allow est sensible pour la sécurité, car ce trafic peut être transmis explicitement sans firewall policy. L’aide SFOS 22 n’indique ni valeur par défaut ni distinction exacte entre dynamic et static. Ne modifier aucune catégorie sur la base d’un soupçon. Si Sophos Support demande un changement, remplacer show par allow ou drop dans la même syntaxe, puis vérifier le statut, un Packet Capture et un flux de test positif ainsi qu’un flux négatif.

Ce commutateur n’est ni LAN Bypass ni une stateful firewall bypass rule. Il n’active pas un chemin fail-to-wire et ne retire pas une connexion connue de la Stateful Inspection.

Définir des entrées MAC statiques uniquement de façon ciblée

La bridge forwarding table apprend normalement les adresses MAC de façon dynamique et détermine par quel port transmettre les frames. static-entry peut lier une adresse MAC à une bridge, une interface et un port. Le modèle officiel de la commande est :

system bridge static-entry [add | delete | show] [interface] {interface ID} [bridge name] [Port] {PortID} [macaddr] {MAC Address} [priority] [dynamic | static]

Les crochets et accolades décrivent la syntaxe et ne sont pas copiés dans la commande. Avant add, vérifier les ID réels avec show, la complétion par Tab et leur correspondance dans WebAdmin. Une entrée statique incorrecte ou obsolète peut diriger les frames vers le mauvais port ou rendre la destination inaccessible. Pour le rollback, supprimer exactement l’entrée documentée avec delete. L’apprentissage MAC, les chemins aller et retour et l’accès d’administration doivent ensuite fonctionner de nouveau.

Ne pas utiliser la limite de members comme objectif de dimensionnement

Afficher la limite interne actuelle avec :

system bridge max_bridge_members show

La Device Console accepte des valeurs max_bridge_members de 2 à 256 et fournit aussi reset :

system bridge max_bridge_members set limit <2-256>
system bridge max_bridge_members reset

Cette plage ne doit pas être assimilée à la limite publiée pour WebAdmin. Sophos continue d’indiquer un maximum de 64 members pour une bridge. La plage CLI supérieure n’est donc pas un objectif de design pris en charge pour une bridge de 256 interfaces. Ne la modifier que pour une exception démontrée et après coordination avec Sophos Support. Comme l’aide n’indique pas la valeur par défaut obtenue après reset, consigner si l’état initial était une valeur personnalisée ou la valeur par défaut. Le rollback rétablit exactement cet état.

Ajouter la bridge dans WebAdmin

1. Ouvrir Network > Interfaces > Add interface > Add bridge.
2. Saisir un Name descriptif de 58 caractères maximum, par exemple Bridge_Inline.
3. Définir un Hardware name immuable de 10 lettres, chiffres et _ maximum, par exemple brinline. Les noms système tels que all, ipsec0, xfrm, Port, eth, WLAN ou Halink sont réservés.
4. Activer Enable routing on this bridge pair uniquement si la bridge doit délibérément recevoir une adresse IP et router.
5. Ajouter les Member interfaces préparées et leurs zones.
6. Pour une bridge routée, configurer IPv4 ou IPv6 et la gateway prévue pour les members WAN.
7. Vérifier les paramètres VLAN, ARP, STP, MTU, MSS et EtherType.
8. Sélectionner Save, puis vérifier la liaison, les règles et un flux réel.

Le nom d’affichage peut être modifié ultérieurement. Le Hardware name reste immuable et doit correspondre à la convention de nommage avant l’enregistrement.

Comprendre les filtres VLAN et EtherType

Avec Filter VLANs, seuls les VLAN saisis sous Permitted VLAN ID or ID range sont transférés. Les plages comme 20-35 sont possibles. Si le filtre est activé et que la liste est vide, SFOS abandonne tout le trafic VLAN tagged ; le trafic untagged reste intact.

Ce filtre agit uniquement sur les frames bridged. Ce n’est pas une règle de pare-feu pour le trafic routé. Le cas lié aux versions avec les anciennes configurations system vlan-tag est traité séparément dans Vérifier les Bridge-VLAN après SFOS 22.

Filter Ethernet frames permet de limiter les EtherTypes. Sans valeur autorisée, toutes les frames sont abandonnées à l’exception des types toujours permis ARP, IPv4, IPv6, 8021Q et EXTE. Les autres types sont ajoutés avec leur ID hexadécimal à quatre chiffres, par exemple 809B, 8138, 8863 ou 8864. Ces autorisations ne sont ajoutées que pour un besoin de protocole concret.

ARP, STP, MTU et MAC aging

Permit ARP broadcast est activé par défaut. Sans broadcasts ARP, la bridge ne peut pas construire une table MAC normale via ARP. La désactivation n’est donc pas une protection générale contre les broadcasts, mais une mesure limitée face à une storm confirmée et exige des entrées statiques adaptées sous Neighbors (ARP–NDP).

Spanning Tree Protocol (STP) protège contre les boucles de couche 2 et peut activer un chemin redondant. Toutefois, STP ne peut pas être activé sur les interfaces bridge lorsque HA est actif. Un design ne doit pas dépendre simultanément d’un mécanisme de prévention des boucles inconnu et de HA. STP max age vaut 20 secondes par défaut et n’est modifié qu’en accord avec l’ensemble du domaine STP.

MAC aging supprime par défaut les adresses MAC inactives après 300 secondes. Des valeurs plus courtes peuvent convenir aux réseaux dynamiques et des valeurs plus longues aux réseaux stables. Les modifications reposent sur le comportement du switch et des applications, pas sur un conseil général de performance.

Si les MTU de la bridge et de ses members diffèrent, la bridge hérite de la valeur la plus basse. Un member avec une MTU de 1500 limite donc aussi une bridge configurée à 9000. Utiliser Override MSS uniquement pour un problème TCP ou MTU confirmé. Vérifier MTU et MSS sur Sophos Firewall fournit une méthode contrôlée.

Règles, NAT et web proxy

Le trafic entre les members nécessite une règle de pare-feu adaptée entre les zones concernées. Source, destination et service sont limités autant que possible, et le logging reste actif pendant la validation. Règles de pare-feu sur Sophos Firewall explique le fonctionnement général.

Une bridge sans adresse IP possède une condition d’arrêt importante : si le trafic correspond à une règle avec web proxy filtering ou à une règle NAT, SFOS peut abandonner les paquets sans log. Ce comportement ne doit pas être interprété comme un drop ordinaire dans Log Viewer.

Si une règle NAT est inévitable, utiliser Override source translation for specific outbound interfaces pour cette bridge précise, définir Outbound interface sur la bridge et Translated source (SNAT) sur Original. Une modification NAT large n’est pas un test sûr. Le web proxy filtering n’est utilisé sur une bridge transparente que si le design le prend explicitement en charge.

Tester la bridge de manière contrôlée

Après l’enregistrement, tester séparément le control plane et le trafic utilisateur :

1. Sous Network > Interfaces, comparer bridge, members, zones, mode IP et état de liaison au plan.
2. Confirmer la Firewall Rule ID attendue avec un flux de test contrôlé.
3. Comparer l’entrée et la sortie dans Packet Capture ; adresses MAC, tag VLAN et EtherType doivent correspondre au design.
4. Tester un service autorisé dans les deux sens et effectuer un test négatif d’un service délibérément interdit.
5. Avec STP, activer les chemins redondants individuellement uniquement pendant une fenêtre de maintenance et mesurer topologie et failover.
6. Avec HA, revérifier bridge, members, apprentissage MAC et applications après un changement de rôle contrôlé.

Pour les drops Bridge ACL, activer Bridge ACLs sous System services > Log settings > Firewall. Dans Log Viewer, filtrer ensuite sur Log component > Bridge ACLs et les sous-types ARP broadcasts, EtherType filtering ou VLAN filtering.

Si le datapath reste incertain, Packet Capture sur Sophos Firewall explique comment lire ensemble les interfaces d’entrée et de sortie, Rule ID, status et reason.

Revenir en arrière en sécurité

Avant la suppression, documenter Object Usage, règles, NAT, VLAN, DHCP, routes, hosts et accès de gestion de la bridge et de tous les members. Créer d’abord un chemin de remplacement et le tester avec du trafic réel. Supprimer ensuite seulement les dépendances de production, la bridge, puis réaffecter les members de manière contrôlée.

Un seul ping réussi ne suffit pas comme preuve de rollback. Revérifier ensuite gateway, DNS, gestion, applications de production, Firewall Rule ID et chemin retour.

Questions fréquentes