Planifier correctement les zones et interfaces Sophos Firewall

Une zone regroupe des interfaces ayant un niveau de confiance similaire. Une interface est une connexion physique ou virtuelle, par exemple Port1, une interface VLAN, LAG, RED ou XFRM. Chaque interface rattachée appartient à une seule zone ; les ports physiques peuvent aussi rester sans affectation.

Important : Une zone n’autorise pas automatiquement le trafic. Même entre deux interfaces de la zone LAN, une règle de pare-feu LAN-to-LAN adaptée est nécessaire. L’accès au pare-feu lui-même, par exemple à WebAdmin, SSH ou DNS, est en outre contrôlé par Device Access.

Configurer directement les zones et interfaces

Créer une zone

Une zone personnalisée se crée sous Network > Zones > Add en quatre étapes :

1. Attribuer un nom explicite, par exemple Server, Management, Guest ou IoT.
2. Sélectionner LAN ou DMZ comme Type.
3. Sous Device Access, n’autoriser que les services locaux du pare-feu réellement nécessaires depuis cette zone.
4. Enregistrer la zone.

La zone doit ensuite apparaître sous Network > Zones et pouvoir être sélectionnée comme Source zone ou Destination zone dans une règle de pare-feu. Le trafic de production n’utilise la zone qu’après l’affectation d’au moins une interface.

Les zones personnalisées ne peuvent être créées qu’avec le type LAN ou DMZ. Il n’est pas possible de créer des zones WAN ou VPN supplémentaires. SFOS affecte automatiquement les interfaces VPN à la zone VPN. Le nombre maximal de zones dépend de la version : SFOS 22.0 autorise jusqu’à 100 zones, SFOS 23.0 jusqu’à 248 zones.

Configurer une interface physique

Le nombre de ports physiques disponibles dépend du modèle de l’appliance. Lors de la planification, vérifier donc d’abord les ports dont dispose l’appareil concerné ; les interfaces virtuelles ne remplacent pas les ports physiques supplémentaires nécessaires.

Une interface existante se modifie sous Network > Interfaces avec Edit interface :

1. Attribuer un Name explicite de 58 caractères maximum, par exemple Core Switch Trunk ou MPLS Provider.
2. Sélectionner la Network zone appropriée.
3. Configurer IPv4 et, si nécessaire, IPv6.
4. Pour les interfaces WAN, vérifier la passerelle ainsi que, le cas échéant, MTU et MSS.
5. Enregistrer l’interface, puis contrôler l’état du lien, l’état de la passerelle et Log Viewer.

Seules les interfaces de la zone WAN disposent d’une configuration de passerelle. Les interfaces internes utilisent généralement une adresse statique ; les connexions WAN peuvent être configurées avec une adresse statique, DHCP ou PPPoE.

Si l’interface physique porte déjà un VLAN, SFOS n’autorise pas le passage de l’affectation IPv4 de Static à DHCP ou PPPoE. Pour IPv6, le passage de Static à DHCP ou Delegated est également bloqué. Avant ce changement, relever les dépendances VLAN sous Object usage. Déplacer ensuite les interfaces VLAN concernées vers une autre interface parente ou les supprimer pendant une fenêtre de maintenance. Modifier alors le mode d’affectation, puis rétablir la configuration VLAN et tester la connectivité.

Sous Advanced settings, faire correspondre Link mode, Auto-negotiation for media type, Forward Error Correction (FEC) selon le modèle, MTU et MSS avec l’équipement distant. Pour les ports à 25, 50 et 100 Gbit/s, enregistrer d’abord Link mode, rouvrir l’interface, puis charger la configuration recommandée. Sur les XGS 2100, 2300, 3100 et 3300, tous les ports SFP+ des modules FleXi Port doivent utiliser la même vitesse. SFOS ne prend pas en charge le marquage DSCP du trafic DHCP et ARP généré par le système ; aucune stratégie ne doit compter sur un traitement prioritaire de ces paquets.

Les vitesses des ports du pare-feu et de l’équipement distant doivent correspondre. Par exemple, un port à 25 Gbit/s ne peut pas être relié à un port à 40 Gbit/s par des câbles breakout sans conversion adaptée. Les ports à 40 et 100 Gbit/s du pare-feu qui prennent en charge le breakout peuvent être divisés en deux ou quatre ports à l’aide de câbles breakout appropriés. Cette possibilité n’est pas garantie pour toutes les appliances ni pour toutes les combinaisons de câbles ; avant la planification, vérifier la prise en charge des ports, des transceivers et de l’équipement distant concernés.

Définir une adresse IPv4 dans le menu de recovery interactif

Sous 1. Network Configuration > Interface Configuration, la CLI affiche adresse IPv4 et masque, adresse IPv6 et préfixe, zone, gateways et alias configurés des ports physiques. Les interfaces VLAN et WLAN n’apparaissent pas dans cette vue.

y lance une modification IPv4. SFOS affiche successivement l’adresse, le masque et la zone actuels de chaque port ; Enter sans nouvelle valeur conserve le champ. Ce chemin s’applique uniquement au Gateway mode et aux valeurs IPv4 statiques. Il ne configure ni VLAN, DHCP, PPPoE, WLAN ou WWAN, et le dialogue IPv6 diffère.

Avant toute modification, enregistrer toutes les valeurs, l’ID du port, la zone, le gateway, les alias et un accès de management indépendant. Après sauvegarde, vérifier lien, nouvelle IP et masque, gateway, Device Access, routage, DNS et chemin de management réel. En cas de perte d’accès ou de chemin de données incorrect, restaurer les valeurs initiales par console ou accès indépendant.

Corriger les valeurs de lien et MAC dans Device Console

WebAdmin reste le chemin de configuration normal. Device Console est réservé à une correction ou une récupération documentée, car une valeur de lien incorrecte peut couper immédiatement l’unique accès de gestion. Relever auparavant Port ID, équipement distant, Link mode, autonegotiation, FEC, accès administrateur indépendant et retour arrière.

La syntaxe officielle de SFOS 22 accepte 1000fd, 100fd, 100hd, 10fd, 10hd ou auto pour les valeurs cuivre indiquées :

set network interface-link Port2 linkmode auto autoneg on
set network interface-link Port2 linkmode 1000fd autoneg off

autoneg contrôle des paramètres de lien autres que la vitesse et le duplex. Les modes FEC dépendent du modèle et Sophos n’en fournit pas de liste universelle dans cette commande CLI. Pour les ports à 25, 50 ou 100 Gbit/s, utiliser la configuration recommandée pour l’appliance et le transceiver exacts, sans copier la valeur d’un autre modèle.

Une adresse MAC n’est remplacée que pour une dépendance de conception démontrée. L’adresse d’exemple est administrée localement, mais doit rester unique dans le réseau réel :

set network macaddr Port2 override 02:00:5e:10:00:02
set network macaddr Port2 default

Vérifier Port Security, liaisons DHCP, listes d’autorisation du fournisseur, HA et LAG avant l’override. default restaure l’adresse MAC par défaut existante du port. Sophos documente MTU 1500 et MSS 1460 comme valeurs par défaut ; ne les modifier qu’avec la procédure contrôlée de Vérifier MTU et MSS pour les problèmes VPN.

Pour IPv6, DAD attempts détermine le nombre de messages Neighbor Solicitation que le pare-feu envoie pendant Duplicate Address Detection. Sous Allowed RA servers, saisir les adresses MAC ou IPv6 des serveurs Router Advertisement dont cette interface peut accepter une configuration stateless. IPv6 Prefix Delegation sur Sophos Firewall explique le préfixe du fournisseur et sa distribution interne ; Configurer IPv6 Router Advertisement décrit les flags clients et les préfixes annoncés.

Pour une tâche précise, utiliser l’un des guides spécialisés suivants :

• Configurer et tester une interface VLAN
• Configurer et tester un réseau Wi-Fi géré par SFOS
• Relier des APX existants avec Wireless Mesh
• Configurer une interface LAG
• Configurer et tester un tunnel GRE
• Transporter IPv6 sur IPv4 ou IPv4 sur IPv6 avec un tunnel IP
• Transférer le multicast entre des interfaces avec une route multicast statique
• Planifier et vérifier le routage multicast dynamique avec PIM-SM
• Configurer et vérifier une liaison WAN PPPoE
• Configurer le basculement WAN avec une seconde liaison Internet
• Configurer Sophos SD-RED
• Sécuriser Device Access
• Configurer un VPN IPsec site-to-site

Planifier le modèle de zones

Distinguer zone, interface et objet réseau

Ces trois éléments remplissent des fonctions différentes :

• Zone : identifie le périmètre de sécurité d’où provient le trafic ou vers lequel il se dirige.
• Interface : relie le pare-feu physiquement ou virtuellement à un réseau.
• Objet réseau : identifie l’adresse IP ou le sous-réseau précis dans une règle.

Une règle n’est précise que si la zone et l’objet réseau sont corrects. Source zone: LAN associé à Source networks: Any est souvent inutilement large. À l’inverse, un objet réseau correct ne sert à rien si le paquet entre par une zone différente de celle indiquée dans la règle.

Les zones par défaut ont des rôles fixes :

• LAN pour les réseaux internes
• WAN pour les connexions opérateur et internet
• DMZ pour les systèmes exposés ou particulièrement isolés
• WiFi pour les environnements sans fil
• VPN pour les tunnels d’accès à distance et site-to-site

La zone WiFi s’applique aux réseaux sans fil qui utilisent une zone dédiée. Avec Bridge to AP LAN et Bridge to VLAN, aucune interface WiFi dédiée n’est toutefois créée ; le chemin du trafic suit l’affectation de bridge sélectionnée.

Un réseau sans fil définit les paramètres communs aux clients WLAN : SSID, mode de sécurité et traitement du trafic client. Avec le Traffic Mode Separate zone, le pare-feu crée un tunnel VXLAN associé. Le choix du Traffic Mode détermine donc aussi la manière dont le WLAN est relié au pare-feu ; il ne s’agit pas simplement d’une désignation du réseau.

Les zones LAN personnalisées conviennent par exemple à Client, Server, Management, Guest, IoT, VoIP, Backup ou OT. Une zone DMZ personnalisée est adaptée aux serveurs publiés, reverse proxies ou autres systèmes dont l’accès au réseau interne doit être strictement limité.

Chaque VLAN n’a pas besoin de sa propre zone. Plusieurs VLAN peuvent partager une zone si leur niveau de confiance, leurs règles de pare-feu et leurs paramètres Device Access sont identiques. Si les destinations autorisées, les accès d’administration ou les fonctions de sécurité diffèrent, une zone distincte est généralement plus claire.

Il ne faut pas créer de types de zone VPN personnalisés pour les utilisateurs VPN ou les tunnels intersites. La séparation au sein de la zone VPN s’effectue avec des objets réseau, des utilisateurs et des règles de pare-feu précis.

Définir les directions d’accès avant les règles

Avant la configuration, une courte liste des directions autorisées suffit. Par exemple :

• Client vers WAN : services web, DNS, NTP et applicatifs nécessaires
• Client vers Server : uniquement les ports applicatifs définis
• Guest vers WAN : accès internet, mais aucun accès aux réseaux internes
• IoT vers Server : uniquement les destinations nécessaires, comme DNS, NTP ou une plateforme d’administration
• Management vers les zones internes : services d’administration strictement limités et journalisés
• DMZ vers LAN : bloqué par défaut, seules les connexions explicitement nécessaires sont autorisées
• VPN vers Server : uniquement les destinations et services approuvés

Pour chaque direction autorisée, documenter la destination, les services, les besoins NAT, la journalisation et le responsable. Ces éléments constituent les règles réelles. Configurer correctement les règles Sophos Firewall explique leur structure, leur ordre et le matching.

Vérifier avant une modification

Avant de créer ou de déplacer une interface, clarifier au moins les points suivants :

• zone et niveau de confiance du réseau
• adresse IP, sous-réseau et default gateway
• source DHCP et serveurs DNS
• services locaux du pare-feu nécessaires
• règles de pare-feu et NAT
• routage et SD-WAN
• client de test, accès attendu et entrée de journal attendue

Les modifications en production nécessitent également une sauvegarde récente, une procédure de retour arrière et une vérification sous Object usage.

Créer et valider un VLAN

Un VLAN constitue un domaine de broadcast isolé : les broadcasts restent à l’intérieur de ce VLAN. L’affectation de plusieurs VLAN à la même zone de sécurité ne supprime pas cette séparation de couche 2 ; la zone définit le contexte des règles de pare-feu et de Device Access.

Un VLAN se crée sous Network > Interfaces > Add interface > Add VLAN. Les paramètres essentiels sont :

• Interface : interface physique, RED, bridge ou LAG sur laquelle arrive le VLAN tagué
• Network zone : périmètre de sécurité du VLAN
• VLAN ID : doit correspondre au switch et, le cas échéant, au point d’accès
• IPv4/IPv6 configuration : généralement une adresse de passerelle statique pour un VLAN interne

Par exemple, un VLAN invité pourrait utiliser Port3, le VLAN ID 20, la zone Guest et l’adresse de passerelle 192.168.20.1/24. Sur le switch, le VLAN 20 doit être tagged sur l’uplink vers Port3 ; un port client ou le SSID invité affecte ensuite les terminaux à ce VLAN.

Le pare-feu peut afficher correctement l’interface même si le switch envoie le VLAN sur le mauvais port, sans tag ou avec un autre VLAN ID. Un VLAN n’est donc terminé qu’après avoir testé le chemin complet :

1. Vérifier sur le pare-feu le VLAN ID, l’interface parente, la zone, l’adresse IP et le masque.
2. Configurer l’uplink vers le pare-feu comme trunk avec le VLAN tagged.
3. Affecter le port d’accès ou le SSID au bon VLAN.
4. Vérifier DHCP, la passerelle et DNS avec un client de test.
5. Tester un accès interne autorisé et un accès volontairement interdit.
6. Vérifier l’accès à internet et confirmer le firewall Rule ID attendu dans Log Viewer.

Le NAT n’est normalement pas nécessaire pour le trafic interne. Si le client obtient une adresse, mais ne peut pas joindre le pare-feu comme serveur DNS ni par ping, vérifier d’abord Device Access. La procédure complète, y compris le tagging du switch et DHCP, est décrite dans Configurer et tester un VLAN sur Sophos Firewall.

Sophos n’indique pas de nombre maximal fixe de VLAN par port parent physique pour les XGS Appliances. Plusieurs uplinks ou un LAG peuvent néanmoins simplifier l’exploitation et le dépannage en cas de forte charge, de nombreux VLAN ou de configurations HA.

Choisir le bon type d’interface

Les interfaces virtuelles et les alias se créent sous Network > Interfaces via Add interface. Sélectionner le type souhaité, puis ouvrir sa configuration. Les sections suivantes aident à choisir le type ; un alias complète une interface existante, tandis que VLAN, bridge et LAG, par exemple, représentent différents types de connexions logiques.

Alias

Un alias ajoute une adresse IP à une interface existante. Il est particulièrement utile lorsqu’un opérateur fournit plusieurs adresses IP publiques dans le même sous-réseau.

Configurer et tester une adresse IP alias sur Sophos Firewall explique comment lier l’adresse supplémentaire, l’utiliser comme objet hôte dans les règles et le NAT, puis vérifier ARP et le trafic système.

Plusieurs interfaces WAN distinctes dans le même sous-réseau peuvent provoquer des problèmes ARP et rendre des passerelles injoignables. Dans ce cas, un alias sur l’interface WAN existante ou un LAG correctement conçu constitue généralement la solution la plus propre. Un alias suit l’état de son interface parente et ne peut pas être désactivé indépendamment.

Bridge

Un bridge relie plusieurs interfaces en couche 2. Il peut fonctionner avec une adresse IP pour le trafic routé ou de manière transparente sans adresse IP. Les VLAN sont généralement plus clairs pour les nouveaux réseaux segmentés ; les bridges conviennent davantage aux migrations ou aux conceptions délibérément transparentes.

La procédure complète couvrant les membres, STP, les filtres VLAN et EtherType, les règles et la validation est décrite dans Configurer une interface bridge sur Sophos Firewall.

Des restrictions importantes s’appliquent :

• Un bridge ne prend pas en charge Dynamic DNS, le client DHCP, PPPoE ou le VPN IPsec.
• Le trafic entre les membres du bridge peut toujours nécessiter des règles de pare-feu, par exemple une règle LAN-to-LAN.
• HA ne peut pas être activé tant que STP est actif sur un bridge.
• Si un filtre VLAN est activé, mais qu’aucun VLAN n’est autorisé, le pare-feu rejette toutes les trames taguées ; le trafic untagged n’est pas affecté.
• Le trafic via un bridge sans adresse IP peut être rejeté sans entrée de journal s’il correspond à une règle web proxy ou NAT.

Pour un bridge transparent, vérifier si Web Proxy Filtering ou Source Translation sont réellement nécessaires.

Sophos documente NC-177630 pour SFOS 22.0.0 GA-Respin Build 411. Le problème peut survenir lorsque le trafic routé via un bridge est traduit avec SNAT ou MASQ et que les flux entrant et sortant utilisent le même membre physique du bridge. Les paquets de réponse sont alors rejetés par le filtre hairpin sans apparaître dans drppkt. Cela s’applique aussi lorsqu’un seul membre du bridge est actif. Le trafic passant par des membres physiques différents ou sans SNAT/MASQ n’est pas affecté.

Sophos indique SFOS 22.0.1 MR1 Build 490 comme version corrigée. Sur GA-Respin Build 411, SNAT ou MASQ ne doit être supprimé pour le flux concerné que si la traduction n’est pas nécessaire et qu’un chemin retour vers l’adresse IP d’origine du client existe. Il est également possible de router le trafic via une interface physique dédiée plutôt que par le bridge. Si l’un des déclencheurs décrits est absent ou si le problème se produit sur MR1 Build 490 ou une version ultérieure, il faut rechercher une autre cause. Le cas SFOS 22 distinct concernant le trafic VLAN vers le pare-feu est décrit dans Vérifier les VLAN d’un bridge après SFOS 22.

Un bridge sur RED peut étendre un réseau de couche 2 entre plusieurs sites, mais il doit rester une exception justifiée.

Les broadcasts, ARP et le trafic unicast inconnu traversent alors la connexion WAN. Une conception routée avec des sous-réseaux propres à chaque site et des règles de pare-feu précises est plus stable, plus évolutive et plus facile à dépanner.

LAG

Un Link Aggregation Group regroupe deux à quatre interfaces physiques en un uplink logique. Des VLAN peuvent ensuite y être configurés.

Les modes de fonctionnement courants sont :

• Active-Backup : Un lien est actif et un autre prend le relais en cas de panne.
• LACP (802.3ad) : Plusieurs liens peuvent être utilisés en parallèle ; le pare-feu et le switch doivent avoir des configurations identiques.

Les membres admissibles sont des interfaces physiques non affectées avec une configuration statique. Les interfaces PPPoE, Cellular WAN et WLAN sont exclues. Avec LACP, tous les ports doivent être du même type et avoir la même vitesse.

La xmit-hash-policy répartit les connexions entre les liens. Elle n’accélère généralement pas une connexion TCP unique, car celle-ci reste sur un seul lien. LAG apporte surtout de la redondance et une bande passante agrégée supplémentaire pour plusieurs connexions parallèles.

WAN cellulaire et WWAN1

Lors de l’activation de Cellular WAN, SFOS crée l’interface WWAN1. Elle fait partie de la connexion mobile et ne doit pas être assimilée à un VLAN ou à un alias créé librement. Les restrictions HA décrites ci-dessous ainsi que l’exclusion des membres d’un LAG restent à respecter.

Dans SFOS 23.0, Network > Interfaces propose, dans le Menu de l’interface WWAN, les actions Connect et Disconnect pour connecter ou déconnecter le modem Cellular WAN. Reset redémarre le modem. Il ne faut pas supposer que ces actions décrites pour SFOS 23.0 sont accessibles par un chemin identique dans SFOS 22.0.

Avant Disconnect ou Reset, prévoir un accès d’administration indépendant et une fenêtre de maintenance si la connexion mobile transporte du trafic de production ou assure l’accès d’administration. Vérifier ensuite l’état de l’interface ainsi que les chemins de données et d’administration nécessaires. Le redémarrage du modem ne constitue pas une solution garantie à une erreur de connexion dont la cause n’a pas été déterminée.

TAP / Discover Mode

Un port physique en Discover Mode reçoit une copie du trafic répliquée par le switch. Il n’est pas en ligne et ne peut ni bloquer le trafic observé ni le contrôler avec des règles de sécurité. Ce fonctionnement est utile pour un inventaire ou une preuve de concept, mais il ne constitue pas un chemin de protection en production.

Dans la vue d’ensemble des interfaces, ce port apparaît sous la désignation Discover, physical (TAP). Cela permet de le distinguer d’une interface normale située sur le chemin du trafic de production.

Configurer Discover Mode avec TAP et SPAN décrit la configuration complète avec port SPAN, commandes Device Console, Packet Capture, Security Audit Report et limites HA.

XFRM pour IPsec route-based

Pour IPsec route-based, on distingue les connexions Any-to-any des connexions avec des Traffic Selectors spécifiques. Lorsque les deux sous-réseaux sont définis sur Any, SFOS crée automatiquement une interface XFRM dans la zone VPN :

• Any-to-any : Attribuer une adresse IP à l’interface XFRM créée automatiquement sous Network > Interfaces. Les routes statiques, SD-WAN ou dynamiques déterminent ensuite le trafic du tunnel.
• Traffic Selectors : SFOS ajoute automatiquement une route statique lors de l’établissement du tunnel. Si une interface XFRM apparaît, ne lui attribuer ni adresse IP ni routes manuelles.

La documentation officielle de SFOS 22 et SFOS 23 se contredit sur la création de XFRM pour des sous-réseaux spécifiques : « Configure an XFRM interface » indique qu’aucune XFRM n’est créée, tandis que « Route-based VPN » décrit la création d’une XFRM par configuration. Ne pas supposer que l’interface est toujours présente ou toujours absente. Développer la Listening interface sous Network > Interfaces et vérifier sa visibilité réelle sur le build installé. La section Traffic Selectors de Configurer un VPN IPsec site-to-site explique les contrôles existants de visibilité et de trafic.

Dans les deux cas, le trafic VPN nécessite des règles de pare-feu adaptées. Sous Administration > Device access, l’activation d’IPsec pour la zone WAN autorise les demandes de connexion IPsec entrantes. Le ping à travers le tunnel est activé séparément pour VPN.

Une interface XFRM ne se désactive pas directement sous Network > Interfaces, mais par sa connexion sous Site-to-site VPN > IPsec. Si SSL/TLS Decryption s’applique au trafic IPsec, Sophos exige une MTU XFRM inférieure d’au moins 113 octets à celle de l’interface d’écoute. Avec une MTU de 1400 sur l’interface d’écoute, la MTU XFRM ne doit donc pas dépasser 1287. Cette limite propre au produit concerne FastPath Offload et ne constitue pas une valeur générale pour tous les tunnels. Vérifier MTU et MSS en cas de problèmes VPN décrit la procédure complète.

RED

Une interface RED relie un site distant par un tunnel chiffré. Le mode de fonctionnement détermine la part du trafic qui traverse le pare-feu central :

• Standard/Unified : Le pare-feu central gère et filtre tout le trafic du site. Si le tunnel tombe en panne, l’accès à internet peut également être interrompu.
• Standard/Split : Seuls les réseaux de destination définis utilisent le tunnel ; le trafic internet sort localement et n’est pas filtré de manière centralisée.
• Transparent/Split : Le RED fonctionne de manière transparente dans un réseau existant. Cette option est flexible, mais plus difficile à planifier et à dépanner.
• Manual/Split : La configuration réseau est davantage manuelle et peut offrir une plus grande autonomie locale.

Le service RED doit être actif sous System services > RED. La connexion nécessite généralement TCP 3400, UDP 3410 et NTP sur UDP 123. DNS, l’heure système correcte et l’accès sortant à internet doivent fonctionner.

Le comportement des VLAN dépend du modèle RED, du mode de fonctionnement, du mode des ports LAN et de la configuration WLAN. Sophos recommande Standard/Unified lorsque des VLAN sont utilisés derrière le RED ; sur un SD-RED 60, le VLAN tagging n’est possible que dans ce mode. Les réseaux WLAN avec Bridge to VLAN suivent leurs propres règles. Choisir le bon mode de fonctionnement Sophos RED explique DHCP, la passerelle, le chemin internet et le comportement en cas de panne pour les quatre modes. Configurer Sophos SD-RED explique le provisioning, l’état des LED et le dépannage.

Vérifier l’état et Device Access

État de l’interface

Sous Network > Interfaces, les valeurs d’état indiquent s’il faut examiner d’abord le lien ou la politique :

• Not configured : aucune zone affectée
• Connected : configurée et connectée
• Connecting : obtient actuellement une adresse, par exemple par DHCP
• Disconnected : l’adresse a été libérée
• Disconnecting : l’adresse est en cours de libération
• Unplugged : aucune connexion physique ; pour WiFi, il peut manquer un access point ou un wireless network
• Not available : FleXi Port configuré sans module FleXi Port installé

Avec Not configured ou Unplugged, les règles de pare-feu ne sont pas le premier élément à examiner. Vérifier d’abord Zone Binding, le câble, le SFP, la vitesse du port, le port du switch ainsi que DHCP ou PPPoE.

Services locaux du pare-feu

Sous Administration > Device access, définir pour chaque zone si les services locaux tels que HTTPS, SSH, User Portal, VPN Portal, DNS, Ping/Ping6, Captive Portal, RADIUS SSO ou Wireless Protection sont accessibles.

Ces autorisations s’appliquent au pare-feu lui-même. Le trafic de transit entre les réseaux est contrôlé par des règles de pare-feu. HTTPS et SSH ne doivent être autorisés que depuis un réseau d’administration ou par une Local service ACL exception rule ciblée. DNS est nécessaire lorsque les clients utilisent le pare-feu comme serveur DNS.

⚠️ Si les clients sont autorisés à utiliser le web proxy du pare-feu, SFOS traite les requêtes HTTP et HTTPS comme des requêtes proxy internes. WebAdmin, Captive Portal, VPN Portal ou User Portal peuvent alors être accessibles même si le service correspondant est désactivé pour la zone cliente. Dans cette conception, l’accès au proxy et les portails locaux doivent être vérifiés séparément.

Gérer les dépendances et les modifications en toute sécurité

Vérifier Object Usage avant une modification ou une suppression

Zone Binding, DNS, les passerelles, SD-WAN, les interface hosts, les VLAN, Dynamic DNS, DHCP, les règles de pare-feu, NAT et VPN peuvent tous dépendre de la même interface. Object usage affiche ces références.

Le compteur affiché n’est actualisé automatiquement qu’une fois par jour. Avant de modifier ou de supprimer une interface, sélectionner Refresh et documenter les dépendances importantes. Toutes les références ne sont pas modifiables dans la fenêtre contextuelle. Les passerelles WAN doivent être modifiées sur leur page de configuration, tandis que les configurations CLI doivent être modifiées dans la CLI.

Pour les références modifiables dans les règles ou stratégies, le compteur permet d’accéder à la configuration concernée :

1. Dans la colonne Usage, cliquer sur le nombre d’utilisations de l’objet concerné. La fenêtre contextuelle indique quelles configurations utilisent cet objet.
2. Développer la catégorie correspondante à l’aide de l’icône plus pour afficher ses règles ou stratégies.
3. Cliquer sur la règle ou stratégie concernée pour la modifier. Y supprimer la référence à l’objet ou la remplacer par l’objet de remplacement prévu.

Après la vérification des dépendances, l’activation ou la désactivation s’effectue sous Network > Interfaces, dans le Menu de l’interface concernée, avec on ou off respectivement. Avant off, s’assurer de disposer d’un accès d’administration indépendant et d’une procédure de retour arrière ; l’action peut interrompre le chemin de données actuellement utilisé. Les alias et les interfaces XFRM ne peuvent pas être désactivés indépendamment ici.

La désactivation d’une interface conserve sa configuration. Les tunnels IPsec dont le pare-feu est l’initiateur sont immédiatement déconnectés. Les tunnels responder et les connexions d’accès à distance se terminent au plus tard après leur délai d’inactivité ou par Dead Peer Detection.

Une interface virtuelle se supprime sous Network > Interfaces via Menu > Delete interface. N’exécuter cette action qu’après avoir sélectionné Refresh sous Object usage, documenté la vérification des dépendances et préparé une sauvegarde ainsi qu’une procédure de retour arrière ; elle ne supprime pas uniquement l’entrée visible de l’interface.

Lors de la suppression d’une interface virtuelle, SFOS supprime toutes les règles de pare-feu qui l’utilisent, même si la règle contient d’autres interfaces. Il supprime également les Zone Bindings, serveurs ou relais DHCP, entrées ARP, Protected Servers, Interface Hosts et leurs références dans des groupes, ainsi que les routes unicast et multicast qui en dépendent. Les interfaces Alias suivent leur interface parente ; les interfaces XFRM sont gérées par la connexion IPsec.

Modifications HA et à distance

Les interfaces dédiées au lien HA doivent appartenir à une zone DMZ. Les autres interfaces surveillées ou utilisées pour l’administration peuvent appartenir à d’autres zones.

Le mode HA active-active nécessite des interfaces configurées statiquement. Cellular WAN est désactivé avec HA. Le mode active-passive peut utiliser des interfaces WAN à adressage dynamique, mais les connexions telles que PPPoE ne conservent pas nécessairement leur session lors d’un failover.

Avant une modification en production :

1. Documenter la configuration et les dépendances.
2. Préparer une fenêtre de maintenance, un moment de retour arrière, une sauvegarde et une procédure de retour précise.
3. Tester un accès d’administration indépendant, par exemple Sophos Fusion (anciennement Sophos Central), une seconde connexion WAN, un réseau d’administration séparé ou une personne sur place.
4. Préparer un client de test ou un trafic de test identifiable, puis ajouter et tester la nouvelle zone ou le nouveau chemin.
5. Vérifier le lien, l’adresse IP, la passerelle, DHCP, DNS, les règles de pare-feu, NAT et Device Access.
6. Supprimer les anciens objets uniquement lorsque le nouveau chemin est stable.

Pour un trunk VLAN, le retour arrière doit inclure l’ancien VLAN ID, le native VLAN et le profil de port du switch. Pour les modifications WAN, les paramètres de l’opérateur et les routes SD-WAN sont importants ; pour XFRM, ajouter le tunnel, le routage et les règles de pare-feu dans les deux directions.

Rechercher les erreurs systématiquement

Le symptôme indique généralement par où commencer :

• L’interface est unbound ou disabled : Le port physique lui-même ne peut pas être supprimé. Pour retirer uniquement sa configuration, ouvrir le port sous Network > Interfaces, définir Network zone sur None et enregistrer. SFOS affiche ensuite l’interface comme Unbound, son état comme Disabled et son adresse IP comme N/A. Vérifier auparavant Object Usage et le chemin de secours administratif.
• Le VLAN ne fonctionne pas : Comparer le VLAN ID, l’interface parente, le trunk, les paramètres tagged/untagged et le native VLAN.
• Le pare-feu n’est pas accessible par ping, HTTPS ou DNS : Vérifier Device Access et Local Service ACL, et non une règle de pare-feu standard en premier lieu.
• Le trafic interne est bloqué : Vérifier source zone, destination zone, les objets réseau, le routage, les services et l’ordre des règles.
• La passerelle WAN reste inactive : Vérifier le lien, l’adresse IP, la passerelle, les identifiants PPPoE et WAN Link Manager.
• Plusieurs ports WAN se trouvent dans le même sous-réseau : Éviter les problèmes ARP et envisager un alias ou un LAG.
• Le SFP ou la vitesse du port ne correspondent pas : Vérifier systématiquement SFP et SFP+ et comparer le transceiver, le câble, la configuration breakout et la vitesse des deux côtés.
• Le VPN ou PPPoE est instable : Vérifier MTU et MSS.

Pour le diagnostic proprement dit, suivre cet ordre :

1. Network > Interfaces : lien, adresse IP, zone et passerelle
2. Network > Zones : type de zone et Device Access
3. Hosts and services : objets réseau et de service
4. Firewall rules : direction, ordre, services et journalisation
5. NAT rules : original et translation
6. Log viewer : Rule ID ou motif du drop
7. Diagnostics > Tools > Packet capture : arrivée et transfert du paquet

Si la règle semble correcte, mais ne fait pas de match, consulter La règle de pare-feu ne correspond pas. Utiliser Packet Capture dans WebAdmin explique comment suivre le flux de paquets.

Liste de contrôle opérationnelle

• zones planifiées et documentées selon le niveau de confiance
• zone, interface et objet réseau correctement distingués
• VLAN ID, interface parente, trunk et passerelle vérifiés
• Device Access limité, en particulier pour HTTPS, SSH, DNS, ping et les portails
• règles de pare-feu créées avec des zones, réseaux, services et une journalisation précis
• alias envisagé pour les adresses IP opérateur supplémentaires dans le même sous-réseau
• DHCP, DNS, NTP, le routage et, le cas échéant, NAT testés
• Object Usage actualisé et vérifié avant les modifications
• accès d’administration indépendant et procédure de retour arrière préparés
• état du lien, Log Viewer et Packet Capture vérifiés après la modification

FAQ