Configurer et tester une interface de pont sur Sophos Firewall

Une interface de pont relie au moins deux interfaces au niveau de la couche 2. Elle permet d’insérer Sophos Firewall dans un chemin réseau existant sans modifier le sous-réseau ni la passerelle par défaut des clients. Le pont peut fonctionner de manière transparente, sans adresse IP, ou assurer le routage avec sa propre adresse IP.

Dans l’exemple de cet article, le pare-feu est placé entre un routeur existant et le commutateur cœur de réseau. Port4, orienté vers le routeur, appartient à la zone WAN ; Port3, orienté vers le commutateur interne, appartient à la zone LAN. Le pont lui-même ne reçoit aucune adresse IP. WebAdmin reste accessible par un port d’administration distinct.

⚠️ Lors de l’enregistrement, le pont prend en charge ses interfaces membres. Une zone incorrecte, l’absence de chemin d’administration ou un chemin redondant de couche 2 peuvent couper l’accès ou provoquer une boucle. Créez au préalable une sauvegarde, documentez le câblage et testez un accès d’administration indépendant. Ne raccordez un second chemin physique qu’après avoir défini le fonctionnement de STP et, le cas échéant, l’architecture HA.

Quel fonctionnement du pont choisir selon l’objectif ?

Pont transparent sans adresse IP

Un pont transparent transfère les trames Ethernet entre ses membres, mais ne sert pas de passerelle. Les adresses IP, le sous-réseau et la passerelle par défaut des terminaux restent inchangés. Cette configuration convient à une migration maîtrisée ou à l’ajout d’une couche de sécurité entre un routeur existant et le réseau interne. Selon la règle et la licence, SFOS peut y appliquer l’inspection DPI, l’IPS, l’analyse antimalware et l’analyse des e-mails, même si le routeur existant demeure la passerelle.

Transparent ne signifie pas non filtré. Les zones des membres déterminent la règle de pare-feu susceptible de s’appliquer. Dans l’exemple, le chemin de Port3, en zone LAN, vers Port4, en zone WAN, nécessite une règle LAN-to-WAN adaptée. Si les deux membres se trouvent dans la zone LAN, il faut à la place une règle LAN-to-LAN.

L’article Planifier les zones et les interfaces sur Sophos Firewall explique comment choisir les niveaux de confiance, créer des zones personnalisées et leur affecter des interfaces. Toutes les décisions propres au pont sont détaillées ici ; l’article de référence est utile si le modèle de zones est nouveau ou manque de cohérence.

Sans adresse IP sur le pont, l’administration doit passer par une autre interface. Dans l’exemple, Port2 dessert un réseau d’administration distinct. WebAdmin reste ainsi accessible même si le pont, ses règles ou son câblage ne sont pas encore corrects.

Pont routé avec adresse IP

Avec Enable routing on this bridge pair, le pont reçoit une adresse IP et peut servir de passerelle ou de point de terminaison local du pare-feu. Sa fonction change alors fondamentalement : au transfert de couche 2 s’ajoutent du trafic routé, des services locaux et, éventuellement, des dépendances à une passerelle.

Le filtrage VLAN du pont continue de s’appliquer uniquement aux trames transférées par celui-ci. Il ne filtre pas le trafic routé par le pont. Si le pont sert de passerelle, il faut donc également contrôler le routage, Device Access, les règles de pare-feu et la NAT.

La documentation de SFOS 22 est ambiguë au sujet de DHCP. Pour l’attribution d’adresse IP à un pont routé, elle mentionne Static et DHCP, mais cite aussi les clients DHCP parmi les fonctions de pont non prises en charge dans le même document. Une adresse statique est donc préférable pour une architecture de production prévisible. N’utilisez DHCP sur un pont qu’après avoir vérifié la version précise de SFOS et obtenu confirmation de Sophos.

Mode pont dans l’assistant de configuration

Le Bridge Mode proposé par le premier assistant de configuration et une interface de pont créée ultérieurement sous Network > Interfaces reposent sur le même principe de couche 2, mais correspondent à deux procédures distinctes.

Sur une appliance neuve, le port A utilise par défaut l’adresse 172.16.16.16/24, tandis que le port B obtient la sienne par DHCP. Pour la configuration initiale, vous pouvez par exemple attribuer l’adresse 172.16.16.2/24 à un ordinateur et le raccorder au port A. WebAdmin est alors accessible à l’adresse https://172.16.16.16:4444. Dans l’assistant, sélectionnez Internet gateway (Bridge Mode). Une fois l’enregistrement et les paramètres de protection et de notification terminés, SFOS applique la configuration et redémarre.

Ce mode est destiné au déploiement initial complet. Il ne faut pas relancer l’assistant sur un pare-feu existant uniquement pour ajouter une nouvelle paire d’interfaces en pont. Si l’assistant est exécuté après la mise en place d’une configuration HA, il désactive HA.

Bridge Mode prend en charge HA. En revanche, la fonction STP de SFOS ne peut être activée sur aucune interface de pont tant que HA est actif. Cette restriction est distincte du transfert des paquets STP, RSTP et de routage multicast. Un pont transparent peut laisser passer ces trames sans participer lui-même à la prévention des boucles au moyen de l’option SFOS Turn on Spanning Tree Protocol (STP).

Planifier l’exemple avant la configuration

Topologie et valeurs d’exemple

Le routeur existant reste la passerelle par défaut du réseau 10.20.0.0/24. Le pare-feu est inséré de manière transparente sur son chemin LAN :

Internet
   |
Routeur existant : 10.20.0.1
   |
Port4, zone WAN
[ Bridge_Inline / brinline / aucune adresse IP ]
Port3, zone LAN
   |
Commutateur cœur de réseau et clients : 10.20.0.0/24

Chemin d’administration distinct :
Port2, zone LAN, 10.99.0.1/24

Après l’installation, un client configuré en 10.20.0.50/24 continue d’utiliser 10.20.0.1 comme passerelle. Le pont ne reçoit ni adresse du réseau 10.20.0.0/24 ni route par défaut. Il faut adapter les numéros de port, les zones, le réseau d’administration et les règles. Ne transposez pas aveuglément ce réseau d’exemple dans un environnement de production.

Avant la modification, consignez deux états : les connexions qui fonctionnent avant l’installation et le chemin permettant d’administrer le pare-feu si le chemin de données de production tombe en panne. Vérifiez au minimum le DNS, la passerelle, une application représentative, le débit attendu et l’accès à WebAdmin.

Vérifier les membres, les zones et les dépendances

Un pont peut compter jusqu’à 64 membres. Peuvent en être membres :

• les interfaces physiques ;
• les interfaces RED ;
• les LAG ;
• les interfaces VLAN rattachées à une interface physique, RED ou LAG.

Multiplier les membres n’est pas un gage de qualité. Chaque connexion supplémentaire étend le domaine de couche 2 et la table MAC, tout en augmentant le nombre de boucles possibles. Deux membres suffisent généralement pour un chemin en ligne.

Avant d’ajouter une interface, vérifiez ses adresses IP, VLAN, services DHCP, passerelles, règles NAT et de pare-feu, routes, paramètres Device Access et références dans Object Usage. Le fait d’intégrer un port à un pont ne supprime pas automatiquement son ancienne fonction de tous les objets qui en dépendent.

Selon Sophos, les interfaces de pont ne prennent en charge ni Dynamic DNS, ni PPPoE, ni IPsec VPN. Comme indiqué précédemment, les informations relatives à DHCP sont elles aussi contradictoires. Un pont ne remplace donc pas universellement une interface WAN ou VPN. Pour de nouveaux réseaux clairement segmentés, les VLAN et le routage sont souvent plus simples à exploiter.

LAN Bypass est une fonction matérielle distincte, et non le comportement normal de n’importe quel pont. L’article Configurer LAN Bypass et le tester de manière contrôlée précise les modèles et paires de ports compatibles ainsi que le comportement en cas de panne.

Créer le pont dans WebAdmin

Nom, nom matériel et membres

1. Ouvrez Network > Interfaces > Add interface > Add bridge.
2. Dans Name, saisissez par exemple Bridge_Inline. Ce nom d’affichage peut comporter jusqu’à 58 caractères et être modifié ultérieurement.
3. Dans Hardware name, saisissez par exemple brinline. Cette valeur est limitée à 10 caractères et ne peut contenir que des lettres, des chiffres et le caractère _. Elle ne peut plus être modifiée après l’enregistrement.
4. Pour l’exemple transparent, laissez Enable routing on this bridge pair désactivé.
5. Ajoutez Port3 avec la zone LAN et Port4 avec la zone WAN dans Member interfaces.
6. Vérifiez les paramètres VLAN, ARP, STP, MAC, MTU, MSS et EtherType.
7. Ne sélectionnez Save qu’une fois l’accès d’administration distinct opérationnel et les deux câbles clairement étiquetés.

SFOS interdit certains noms matériels réservés. Voici la liste complète fournie dans la documentation de SFOS 22 :

all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp,
imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port,
MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos,
GuestAP, spq, Halink

Pour un pont routé, il faut également renseigner une adresse IPv4 ou IPv6. Si le pont comporte des membres WAN, des champs de passerelle apparaissent aussi. Ces valeurs doivent correspondre à l’architecture de routage réelle. Elles restent vides pour le pont transparent de l’exemple.

Filtrage VLAN et EtherType

Filter VLANs limite le trafic étiqueté aux identifiants saisis dans Permitted VLAN ID or ID range. Vous pouvez indiquer des valeurs individuelles ou des plages telles que 20-35. Si le filtre est actif, mais que la liste est vide, SFOS rejette tout le trafic VLAN étiqueté. Le trafic non étiqueté continue de passer. Cette coexistence peut induire en erreur lors du dépannage.

Le filtre VLAN s’applique uniquement aux trames transférées par le pont. Il ne remplace ni les règles de pare-feu ni le contrôle du trafic routé. Sous SFOS 22, les anciens tags VLAN configurés en CLI nécessitent une vérification spécifique. La procédure Vérifier les VLAN de pont après le passage à SFOS 22 traite ce cas particulier avec les indications de version correspondantes.

Filter Ethernet frames permet de limiter les EtherTypes. Sans ce filtre, le pont autorise toutes les trames Ethernet. Si le filtre est actif sans aucun type explicitement autorisé, seuls ARP, IPv4, IPv6, 8021Q et EXTE restent admis. Les autres protocoles sont saisis sous la forme d’un identifiant hexadécimal à quatre chiffres, par exemple 809B pour AppleTalk, 8138 pour Novell, et 8863 ou 8864 pour PPPoE.

N’autorisez pas un EtherType par simple précaution. Commencez par identifier dans Packet Capture le protocole réellement manquant. Vous éviterez ainsi une liste d’exceptions difficile à comprendre, que personne ne saura ensuite attribuer avec certitude.

ARP, STP et vieillissement des entrées MAC

Permit ARP broadcast est activé par défaut. Le pont a besoin d’ARP pour apprendre les correspondances entre adresses IP et MAC et constituer sa table de transfert. Désactiver cette option ne constitue pas une protection générale contre les diffusions. Cette mesure n’est adaptée qu’à un volume anormal de diffusions ARP dûment constaté et exige des associations statiques sous Network > Neighbors (ARP–NDP).

Turn on Spanning Tree Protocol (STP) protège contre les boucles lorsqu’il existe plusieurs chemins de couche 2 entre les mêmes segments. STP peut bloquer un chemin redondant et basculer sur celui-ci en cas de défaillance du chemin actif. L’option n’est pas disponible sur les interfaces de pont tant que HA est actif. Un cluster HA doté d’un câblage redondant exige donc une architecture coordonnant les commutateurs, le raccordement des ports et la prévention des boucles.

La valeur par défaut de STP max age est de 20 secondes. SFOS utilise des BPDU pour échanger les informations de topologie entre les ponts. Ce paramètre ne doit pas être optimisé isolément sur le pare-feu : il doit être cohérent avec l’ensemble du domaine STP.

Par défaut, MAC aging supprime les adresses MAC inactives après 300 secondes. Une valeur plus faible permet de réagir plus vite aux changements d’équipement dans un réseau invité ou de test très dynamique. Dans un réseau de datacenter stable, une valeur plus élevée évite les réapprentissages inutiles. Ne modifiez ce paramètre que si l’apprentissage des adresses MAC est instable, si les équipements changent fréquemment d’emplacement ou si une exigence d’exploitation précise le justifie.

MTU et MSS

Si la MTU du pont diffère de celle de ses membres, le pont adopte la valeur la plus faible. Un pont dont la MTU est réglée sur 9000 reste donc effectivement limité à 1500 si l’un de ses membres ne prend en charge que 1500. La valeur héritée est visible dans le tableau des interfaces.

Override MSS concerne TCP. Cette valeur limite la charge utile de chaque segment TCP afin que les en-têtes supplémentaires ou l’encapsulation d’un tunnel ne dépassent pas la MTU effective. Ce réglage peut corriger un problème avéré de MTU ou de fragmentation, mais pas un VLAN incorrect, une règle manquante ou un chemin retour défaillant. L’ajustement de la MSS ne réduit pas la taille du trafic UDP. La procédure de diagnostic détaillée figure dans Diagnostiquer les problèmes de MTU et de MSS avec un VPN.

Règles de pare-feu, NAT et Web Proxy

Le pont ne contourne pas le pare-feu avec suivi d’état. Dans l’exemple, le trafic des clients nécessite une règle de LAN vers WAN. Utilisez 10.20.0.0/24, ou un objet plus restrictif, comme Source Network, puis limitez Destination et Service au strict nécessaire. Conservez la journalisation active pendant la recette.

Si vous devez encore définir l’ordre des règles, la correspondance des zones ou les fonctions de protection, consultez la procédure complète dans Configurer les règles de pare-feu sur Sophos Firewall. Pour le pont, le critère déterminant reste la zone du membre par lequel entre la trame concernée et celle du membre par lequel elle ressort.

Les paquets de réponse d’une connexion autorisée et établie depuis le réseau interne empruntent l’état existant. Une règle WAN-to-LAN étendue n’est donc pas nécessaire. En revanche, toute nouvelle connexion entrante exige une règle distincte et volontairement restrictive.

Un pont sans adresse IP présente un cas d’erreur particulier. Si le trafic correspond à une règle de pare-feu utilisant Web Proxy Filtering ou à une règle NAT, SFOS peut rejeter les paquets sans rien inscrire dans Log Viewer. Dans ce cas, l’absence de journal ne prouve pas qu’aucune règle n’est en cause.

Si la règle NAT est nécessaire, activez Override source translation for specific outbound interfaces dans cette règle précise. Définissez Outbound interface sur le pont et Translated source (SNAT) sur Original. L’adresse source est ainsi conservée pour cette sortie. Une modification globale de la NAT constituerait un mauvais test, car elle affecterait d’autres chemins de données et masquerait la cause réelle du problème.

Sur un pont transparent sans adresse IP, n’utilisez Web Proxy Filtering que si l’architecture et la version de SFOS concernée le prévoient explicitement. Pour une inspection en ligne classique, les règles basées sur DPI constituent un point de départ plus facile à analyser.

Valider le chemin des données et isoler les erreurs

Recette après l’enregistrement

Après l’enregistrement, contrôlez séparément la configuration, le trafic utile et le comportement en cas de panne :

1. Sous Network > Interfaces, comparez au plan le nom du pont, son nom matériel, ses membres, ses zones, son mode IP, la MTU héritée et l’état des liens.
2. Depuis le client de test, établissez une connexion vers un service requis et confirmez dans Log Viewer la Firewall Rule ID attendue.
3. Comparez l’entrée et la sortie dans Packet Capture. Les adresses MAC source et destination, le tag VLAN, l’EtherType et l’interface doivent correspondre à la topologie.
4. Testez un service autorisé dans les deux sens. Lancez ensuite un service volontairement interdit et vérifiez le rejet attendu.
5. Testez le DNS, la passerelle par défaut et une application métier représentative. Un simple ping ne suffit pas.
6. Vérifiez de nouveau l’accès d’administration par le port indépendant.
7. Si STP est utilisé, ne raccordez un chemin redondant que pendant une fenêtre de maintenance, puis mesurez le temps de basculement et la perte de paquets.
8. Avec HA, testez de nouveau le pont, ses membres, l’apprentissage des adresses MAC et les applications après un changement de rôle contrôlé.

Aucun trafic et aucune entrée de journal

Si ni autorisation ni rejet n’apparaît dans Log Viewer, commencez par vérifier les cas particuliers propres au pont :

• Le pont est-il dépourvu d’adresse IP ?
• Le flux correspond-il à une règle NAT ?
• La règle de pare-feu utilise-t-elle Web Proxy Filtering ?
• Le remplacement de SNAT est-il défini sur Original pour ce pont ?
• Packet Capture voit-il la trame sur le membre d’entrée, mais pas sur le membre de sortie ?

Ce n’est qu’ensuite qu’il est utile de rechercher un problème classique d’ordre des règles ou de chemin retour. Vous éviterez ainsi de répondre à un rejet non journalisé par des règles Allow toujours plus permissives.

Rejet d’un VLAN ou d’un EtherType

Sous System services > Log settings > Firewall, activez le composant Bridge ACLs. Dans Log Viewer, vous pourrez ensuite filtrer sur Log component > Bridge ACLs, puis sur les sous-types ARP broadcasts, EtherType filtering ou VLAN filtering.

Pour un problème de VLAN, contrôlez ensemble la présence ou l’absence de tag, la liste des VLAN autorisés et le profil de port du commutateur. Pour un problème d’EtherType, Packet Capture indique l’identifiant à quatre chiffres réellement présent. Le filtre et l’équipement homologue doivent décrire le même chemin de données.

Le trafic ne fonctionne que dans un sens

Un flux unidirectionnel indique le plus souvent une zone incorrecte, une règle manquante, un routage asymétrique ou une adresse MAC non apprise. Dans Packet Capture, comparez les trajets aller et retour sur les deux membres. Vérifiez ensuite Rule ID, Source NAT, Gateway et la table MAC.

Boucle ou instabilité des associations MAC

Un grand nombre de diffusions, des associations MAC changeantes et des liens instables indiquent une boucle ou une redondance mal câblée. Déconnectez le second chemin avant de modifier d’autres filtres. Examinez ensuite comme un ensemble cohérent le STP des commutateurs, le STP de SFOS, le câblage HA et les membres réels du pont.

Une architecture HA ne doit pas partir du principe que le pare-feu peut activer simultanément sa propre option STP. Si les commutateurs assurent la prévention des boucles, le test de basculement doit démontrer qu’il ne se produit ni boucle ni blocage permanent d’un chemin de production.

Pour associer précisément l’interface, la Rule ID, le statut et le motif, vous pouvez également suivre la procédure Utiliser Packet Capture sur Sophos Firewall. La procédure de recette propre au pont reste néanmoins décrite intégralement sur cette page.

Contrôles avancés dans Device Console

La configuration courante s’effectue dans WebAdmin. system bridge propose trois contrôles supplémentaires. Ces commandes ne remplacent ni une règle de pare-feu manquante ni une architecture de couche 2 non maîtrisée. Avant toute modification, consignez le nom du pont, son nom matériel, ses membres, les identifiants des ports, la table MAC, le chemin d’administration et l’état actuel dans la CLI.

Traiter le trafic inconnu non routable

bypass-firewall-policy concerne le trafic non routable traversant le pont auquel aucune Security Policy ne s’applique. SFOS distingue les catégories dynamic et static. Pour afficher leur état actuel, exécutez :

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

Les actions possibles sont allow et drop. Avec allow, le trafic concerné est explicitement transféré sans Firewall Policy. La documentation de SFOS 22 ne précise ni la valeur par défaut ni la distinction exacte entre dynamic et static. Ne modifiez donc ce réglage que pour un cas précis, avec l’accompagnement du support Sophos. Vérifiez ensuite l’état dans la CLI et dans Packet Capture, ainsi qu’un flux de test autorisé et un autre bloqué.

Ce paramètre n’est ni LAN Bypass ni une stateful Firewall Bypass Rule. Il n’active aucun chemin fail-to-wire et ne soustrait aucune connexion connue à l’inspection avec suivi d’état.

Créer des entrées MAC statiques de manière ciblée

La table de transfert du pont apprend normalement les adresses MAC de manière dynamique. static-entry associe de façon permanente une adresse MAC à un pont, une interface et un port. La syntaxe officielle de la commande est la suivante :

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

Les crochets décrivent la syntaxe et ne doivent pas être copiés. Avant d’utiliser add, vérifiez les identifiants réels avec show et leur correspondance dans WebAdmin. Une entrée incorrecte ou obsolète peut diriger les trames vers le mauvais port. Pour revenir en arrière, supprimez avec delete l’entrée précise que vous avez documentée. Testez ensuite de nouveau l’apprentissage des adresses MAC, les trajets aller et retour ainsi que l’accès d’administration.

Ne pas faire de la limite de membres un objectif de dimensionnement

Pour afficher la limite interne actuelle, exécutez :

system bridge max_bridge_members show

Device Console accepte pour max_bridge_members des valeurs comprises entre 2 et 256 et propose la commande reset :

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

Les deux limites officielles ne concordent pas et aucune explication n’est fournie. La documentation de WebAdmin indique un maximum de 64 membres, tandis que celle de Device Console mentionne des valeurs de 2 à 256. Elle n’explique pas la relation entre ces chiffres. La plage proposée par la CLI ne suffit donc pas à considérer une valeur supérieure à 64 comme une architecture de production prise en charge.

Avant toute modification, consignez l’état actuel avec show. Si la valeur par défaut était active, utilisez reset pour la restaurer. Si une limite personnalisée était configurée, rétablissez exactement cette valeur avec set limit <valeur précédente>. Exécutez ensuite de nouveau show pour confirmer l’état attendu.

Supprimer le pont en toute sécurité

Avant la suppression, documentez Object Usage, les règles, la NAT, les VLAN, DHCP, les routes, les hôtes, les zones des membres et l’accès d’administration. Commencez par créer un chemin de remplacement et testez-le avec du trafic réel. Supprimez seulement ensuite les dépendances de production, puis le pont, avant de réaffecter les membres de manière contrôlée.

Après la suppression, vérifiez de nouveau la passerelle, le DNS, l’administration, les applications de production, la Firewall Rule ID et le chemin retour. La modification n’est terminée que lorsque ces tests correspondent à l’état initial documenté.

Questions fréquentes