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.

La zone WAN est prévue pour les connexions disposant d’une passerelle par défaut. Les interfaces internes utilisent généralement un adressage statique ; les interfaces physiques proposent les méthodes IPv4 Static, DHCP et PPPoE. Les procédures de saisie ci-dessous distinguent ces méthodes. La présence de champs de passerelle dans ces procédures ne justifie pas, à elle seule, l’affectation d’une interface interne à la zone WAN : la zone, l’adressage et le routage doivent correspondre à la conception du réseau et au formulaire effectivement affiché.

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é.

IPv4 sur un port physique : Static ou DHCP

⚠️ Avant de modifier une adresse ou une méthode d’affectation, exécuter Object usage > Refresh, documenter l’adresse, le masque, la zone et la passerelle actuels, puis préparer une sauvegarde, une fenêtre de maintenance et un accès d’administration indépendant. La modification peut interrompre les chemins de gestion et de données actuels. Traiter d’abord les dépendances VLAN existantes comme indiqué ci-dessus. La procédure de récupération par console décrite plus bas ne remplace pas la configuration normale dans WebAdmin.

Static : saisir les valeurs IPv4 fixes

1. Sous Network > Interfaces, ouvrir le bon port physique via Menu > Edit interface et vérifier Hardware. Ce port physique ne peut pas être modifié ici.
2. Sélectionner IPv4 configuration, puis la méthode d’affectation Static.
3. Saisir l’adresse IPv4 prévue pour cette interface. Adapter si nécessaire le masque de sous-réseau au réseau prévu.
4. Renseigner Gateway name et Gateway IP address conformément au formulaire affiché et aux paramètres validés du réseau ou de l’opérateur. Le nom permet d’identifier clairement la passerelle ; son adresse IP est celle de l’équipement distant prévu, et non une adresse supplémentaire du pare-feu.
5. Vérifier à nouveau les valeurs et l’identifiant du port, puis enregistrer avec Save. Contrôler ensuite l’adresse IP et le masque enregistrés, le lien, l’état de la passerelle le cas échéant, ainsi que le routage, DNS, Device Access et les chemins réels de données et de gestion.

À titre purement illustratif, une connexion WAN statique peut utiliser l’adresse IPv4 192.0.2.2, le masque 255.255.255.0, Gateway name ISP-Static et Gateway IP address 192.0.2.1. Ces adresses appartiennent à un réseau réservé à la documentation et ne sont pas des paramètres d’opérateur utilisables en production. Remplacer l’adresse, le masque et la passerelle par les paramètres cohérents fournis par son propre opérateur ; choisir un nom permettant d’identifier la liaison pendant l’exploitation.

DHCP : distinguer l’obtention dynamique des champs documentés

1. Ouvrir le port physique sous Network > Interfaces > Menu > Edit interface, vérifier Hardware et la zone, puis sélectionner IPv4 configuration.
2. Sélectionner DHCP. Cette méthode obtient l’adresse de l’interface auprès d’un serveur DHCP ; elle ne configure pas de serveur DHCP pour les clients.
3. La procédure documentée de saisie des champs DHCP mentionne également la saisie d’une adresse IPv4, la modification facultative du masque de sous-réseau ainsi que Gateway name et Gateway IP address. La description n’explique toutefois pas comment ces paramètres interagissent avec l’adresse obtenue auprès du serveur DHCP. Ne pas en déduire l’existence d’une adresse de remplacement manuelle, d’un mécanisme de secours ou d’un écrasement du bail DHCP.
4. Avant d’enregistrer, vérifier les champs effectivement visibles ou modifiables dans le build installé et les comparer à la configuration DHCP ou opérateur validée. Ne pas copier de valeurs statiques d’exemple dans les champs DHCP. Si le rôle d’un champ obligatoire n’est pas clair, ne pas enregistrer la modification et demander des précisions à l’opérateur ou au support.
5. Une fois la configuration clarifiée, enregistrer avec Save et vérifier qu’une adresse appropriée est obtenue. Connecting signifie que l’obtention d’un bail est encore en cours ; si cet état persiste, examiner d’abord le lien, l’accessibilité du serveur DHCP et les exigences de l’opérateur. Contrôler ensuite l’adresse IP, le masque, la passerelle, DNS, le routage et les chemins réels de gestion et de données.

Si le chemin attendu n’est plus disponible après l’une de ces modifications, restaurer la méthode initiale documentée et ses valeurs via l’accès indépendant, puis tester à nouveau. PPPoE utilise quant à lui les identifiants fournis par l’opérateur ; sa procédure complète est décrite dans Configurer et vérifier une liaison WAN PPPoE.

IPv6 sur un port physique : méthode et mode de réception

Sous IPv6 configuration, les interfaces WAN proposent Static ou DHCP ; les interfaces internes proposent Static, DHCP ou Delegated. Delegated utilise un préfixe délégué par l’opérateur pour les interfaces internes. IPv6 Prefix Delegation sur Sophos Firewall explique la procédure complète avec DHCP sur le WAN, Upstream Interface et distribution interne. Il s’agit d’une tâche distincte qui ne remplace ni la configuration statique ni le choix du mode de réception ci-dessous.

Static : adresse IPv6, préfixe et champs de passerelle

1. Ouvrir le port physique sous Network > Interfaces > Menu > Edit interface et sélectionner IPv6 configuration.
2. Sélectionner Static. Les adresses IPv6 statiques sont prévues pour les interfaces WAN et internes.
3. Saisir l’adresse IPv6 prévue et adapter si nécessaire le préfixe au réseau attribué.
4. Renseigner les champs Gateway name et Gateway IP address mentionnés dans la procédure Static conformément au formulaire effectivement affiché et à la conception du réseau. Les instructions générales Static mentionnent également ces champs dans la section consacrée aux interfaces WAN et internes ; ne pas en déduire qu’une passerelle par défaut interne est obligatoire ni que ces champs sont systématiquement réservés au WAN. Clarifier les champs obligatoires ambigus ou inattendus avant toute modification en production.
5. Enregistrer avec Save, puis vérifier l’adresse IPv6 et le préfixe enregistrés, la passerelle le cas échéant, le routage IPv6, DNS et les connexions autorisées. Conserver l’accès d’administration indépendant pendant ces contrôles ; si le chemin est incorrect, restaurer les valeurs IPv6 documentées auparavant.

Les précautions prises avant la procédure IPv4 s’appliquent également à IPv6 : documenter la méthode et les valeurs précédentes, vérifier les dépendances VLAN et ne pas utiliser le chemin de gestion actuel comme unique moyen de retour arrière.

DHCPv6 : Auto, Manual et Stateless

Après la sélection de DHCP sous IPv6 configuration, Mode détermine comment le pare-feu lui-même reçoit l’adresse de son interface. Ce paramètre est distinct de la configuration d’un serveur Router Advertisement pour les clients internes :

• Auto : l’adresse de l’interface est attribuée automatiquement selon la méthode de configuration utilisée, qui peut être DHCP only ou Stateless. Ne pas en déduire une règle de sélection fixe qui n’est pas documentée ici.
• Manual > DHCP only : le pare-feu affecte à l’interface l’adresse et les autres paramètres fournis par le serveur DHCPv6.
• Manual > Stateless : le pare-feu construit l’adresse de l’interface avec Stateless Address Auto-Configuration (SLAAC), conformément aux flags Managed ou Other (M/O) annoncés dans les Router Advertisements. Accept other configuration from DHCP permet d’obtenir d’autres paramètres auprès du serveur DHCPv6. Cela ne transforme pas le mode de réception en DHCP only.

La fonctionnalité facultative DHCP rapid commit utilise un échange de deux messages (solicit et reply) au lieu de quatre (solicit, advertise, request et reply). Ne l’activez que si Rapid Commit est également activé sur le serveur DHCPv6 et convient à la configuration approuvée. Il ne s’agit pas d’une solution générale aux problèmes de performance.

La procédure DHCPv6 mentionne Gateway name et Gateway IP address. Toutefois, lorsque Mode est défini sur Manual et Stateless, Gateway IP address ne peut pas être renseigné. Cette restriction concerne le mode Stateless et ne doit pas être étendue à Manual > DHCP only. Avant d’enregistrer, vérifier que le mode de réception et les champs de passerelle correspondent à la conception RA/DHCPv6 prévue et au formulaire affiché ; ne pas forcer une adresse IP de passerelle si le mode sélectionné ne le permet pas.

Après Save, vérifier l’adresse IPv6 effectivement attribuée, le préfixe et les autres paramètres, ainsi que le routage, DNS et un chemin de données IPv6 autorisé. Si l’adresse est incorrecte ou absente, comparer d’abord avec l’équipement distant le mode sélectionné, les flags RA reçus et l’accessibilité du serveur DHCPv6 ; ne pas changer de mode sans vérification préalable. Si le chemin de gestion est interrompu, restaurer la configuration précédente via l’accès indépendant.

Faire correspondre les paramètres de port et de lien

Sous Advanced settings, faire correspondre Link mode, Auto-negotiation for media type, Forward Error Correction (FEC) selon le modèle, ainsi que 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. Configurer les interfaces breakout et les paramètres de port présente la procédure complète avec Show recommended settings, Load recommended configuration, les deux étapes d’enregistrement et les différences d’affichage sur les autres ports, y compris ceux à 40 Gbit/s.

SFOS ne prend pas en charge le marquage DSCP du trafic DHCP et ARP qu’il génère lui-même, y compris lorsque le pare-feu fonctionne comme client, relais ou serveur DHCP. Une stratégie ne doit donc pas compter sur une priorisation basée sur DSCP pour ces paquets. Cette restriction concerne DSCP ; elle ne signifie pas que toute autre forme de priorisation est exclue.

Sous Advanced settings > Interface settings, Use default MAC address utilise l’adresse MAC par défaut de l’interface. Dans le cas d’une interface comportant des ports membres, le premier port ajouté fournit cette adresse MAC par défaut. Override default MAC address permet d’utiliser une autre adresse MAC ; une réinitialisation aux paramètres d’usine restaure l’adresse MAC par défaut. Cela ne constitue ni une invitation à effectuer une réinitialisation ni une condition préalable pour un port PPPoE physique autonome. Avant un remplacement justifié de l’adresse MAC, vérifier les dépendances et la procédure de retour arrière décrites ci-dessous.

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 :

Les exemples suivants sont des alternatives, pas une séquence de commandes. Remplacer Port2 par le port physique vérifié et choisir exactement une option correspondant à la configuration approuvée du port et de l’équipement distant ; ne pas exécuter les deux successivement. Consigner d’abord aux deux extrémités les valeurs initiales de Link mode, d’autonegotiation et, le cas échéant, de FEC, ainsi que l’état du lien, la vitesse et le duplex effectifs. Prévoir un accès indépendant et clarifier la restauration exacte via WebAdmin ou une procédure confirmée par le support pour le build installé. Si les valeurs initiales ou le chemin de récupération sont inconnus, arrêter avant la modification CLI et contacter le support.

Alternative 1 : vitesse et duplex automatiques, avec autonegotiation supplémentaire activée :

set network interface-link Port2 linkmode auto autoneg on

Alternative 2 : 1000 Mbps full-duplex, avec autonegotiation supplémentaire désactivée :

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.

Immédiatement après la modification choisie, comparer les valeurs enregistrées de Link mode, d’autonegotiation et, le cas échéant, de FEC dans WebAdmin et sur l’équipement distant aux valeurs cibles approuvées. Vérifier aux deux extrémités l’état du lien, la vitesse et le duplex effectifs, ainsi que l’accès de gestion normal et les chemins réels de données nécessaires. Si un chemin est absent, instable ou dégradé, restaurer via l’accès indépendant les valeurs initiales exactes consignées du port et tous les paramètres de l’équipement distant ajustés pour la modification, y compris FEC si modifié. Utiliser le chemin de restauration clarifié au préalable et répéter les mêmes contrôles ; la configuration de chaque extrémité doit à nouveau correspondre à son propre état initial. Aucun des exemples, pas même auto avec autoneg on, ne constitue un retour arrière universel.

Une adresse MAC n’est remplacée que pour une dépendance de conception démontrée. Avant toute modification, consigner l’adresse MAC effective et le mode configuré (default ou override, y compris une éventuelle adresse personnalisée préexistante) comme état initial. Vérifier Port Security, les liaisons DHCP, les listes d’autorisation du fournisseur, HA, LAG et les associations MAC/ARP du voisin. Prévoir un accès administratif indépendant et une fenêtre de maintenance.

Les descriptions CLI de SFOS 22.0 et 23.0 indiquent que default conserve l’adresse MAC existante. Cela ne démontre pas l’interprétation selon laquelle il restaure la MAC par défaut après un override. default n’est ni une commande inverse confirmée ni un retour arrière universel. Avant l’override, vérifier comment restaurer exactement à la fois l’adresse et le mode sur le build installé. Si l’état initial ou la procédure de restauration ne peuvent pas être vérifiés, ne rien modifier et clarifier avec Sophos Support.

L’exemple suivant modifie la MAC et peut interrompre les connexions d’administration et de données. Remplacer Port2 par le port vérifié et l’adresse d’exemple, administrée localement, par l’adresse cible approuvée et unique dans le réseau. Ce n’est pas une valeur de restauration :

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

Pour la restauration vérifiée :

• Si le mode précédent était override avec une MAC personnalisée, rétablir l’adresse exacte consignée avec la branche override documentée, et non l’adresse d’exemple. La procédure doit être confirmée pour le build installé.
• Si le mode précédent était default, utiliser Use default MAC address sous Network > Interfaces > Edit interface > Advanced settings > Interface settings uniquement si cet élément de l’interface et la restauration de l’état initial consigné sont confirmés sur le build installé. Sinon, obtenir une procédure propre au build confirmée par Sophos Support ; ne pas essayer CLI default ou une réinitialisation d’usine à la place.

Après la modification et après la restauration, comparer le mode configuré et l’adresse effective aux valeurs prévues ; pour le retour arrière, les deux doivent correspondre à l’état initial consigné. Vérifier aussi l’accès administratif normal, l’apprentissage MAC/ARP du voisin et le flux de données réel concerné. En cas d’écart, arrêter la procédure via l’accès indépendant et clarifier avec le support, sans essayer d’autres valeurs MAC.

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 consécutifs que le pare-feu envoie pendant Duplicate Address Detection sur une adresse provisoire (tentative). 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 de l’opérateur 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 ou 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.

LAG et le basculement WAN remplissent des fonctions différentes : un LAG regroupe des liens physiques en une connexion logique. Les liaisons Internet indépendantes sont, en revanche, utilisées via leurs passerelles WAN sous Network > WAN link manager. Plusieurs passerelles actives permettent de répartir la charge entre les liaisons disponibles ; une passerelle de secours peut prendre le relais lorsqu’une panne est détectée. Cela ne garantit ni la continuité sans interruption des sessions existantes ni davantage de bande passante pour une connexion unique. Configurer le basculement WAN avec une seconde liaison Internet explique la procédure et les contrôles permettant de vérifier son fonctionnement.

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 et n’est disponible que pour les modèles 5G de Quectel et Sierra Wireless, pas pour les autres modèles ni pour les dongles USB. 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, s’assurer de disposer d’un accès d’administration indépendant et d’une fenêtre de maintenance si la connexion mobile transporte du trafic de production ou assure l’accès d’administration. Un redémarrage matériel nécessitant l’arrêt du pare-feu interrompt tout le trafic du pare-feu ; prévoir également un accès d’administration indépendant et une fenêtre de maintenance pour cette opération. Pour effectuer un redémarrage matériel d’un modèle non pris en charge, arrêter d’abord le pare-feu, débrancher puis rebrancher le modem et redémarrer le pare-feu ; ne modifier aucun matériel WWAN physique lorsque le pare-feu est en fonctionnement. Vérifier ensuite l’état de l’interface ainsi que les chemins réels 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 vers une adresse locale du pare-feu depuis la zone VPN est autorisé séparément via Ping/Ping6 sous Administration > Device access. Le ping entre hôtes à travers le tunnel VPN est, en revanche, du trafic de transit et nécessite des routes et des règles de pare-feu adaptées ; l’autorisation Device Access ne permet pas ce trafic.

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 dépendants, les serveurs ou relais DHCP, les entrées ARP statiques et proxy ARP, les Protected Servers et les règles de pare-feu qui reposent sur eux, les Interface Hosts et leurs références dans des groupes, ainsi que les routes unicast et multicast. Les interfaces Alias suivent leur interface parente ; les interfaces XFRM sont gérées via la connexion IPsec.

Une simple modification peut également affecter Zone Binding, DNS, les passerelles, les routes et profils SD-WAN, les Interface Hosts, les VLAN et Dynamic DNS. Après une modification ou une suppression, les connexions peuvent temporairement ne plus répondre ou être interrompues. Après chaque changement, vérifier donc les chemins réels de données et de gestion, et pas uniquement l’entrée d’interface enregistrée.

Supprimer délibérément la configuration d’un port physique

Un port physique reste présent sur l’appliance ; seule sa configuration peut être supprimée. off et Network zone None ne sont pas équivalents : off conserve la configuration, tandis que None supprime la configuration IP. Cette action sert à libérer délibérément un port qui n’est plus nécessaire, et non de première étape de réparation en cas de Unplugged ou de passerelle inaccessible.

⚠️ Avant la suppression, exécuter Object usage > Refresh, documenter et migrer les dépendances, puis tester la sauvegarde et l’accès administrateur indépendant. Consigner les adresses IP, les masques ou préfixes, la zone, les passerelles et les alias pour le retour arrière. Ne pas réinitialiser le port via l’unique chemin d’accès de gestion.

1. Sous Network > Interfaces, ouvrir le port physique concerné.
2. Définir Network zone sur None. La configuration IP disparaît déjà dans le formulaire ; vérifier à nouveau l’identifiant du port avant l’étape suivante.
3. Enregistrer avec Save.
4. La vue d’ensemble doit afficher Unbound, l’état Disabled et l’adresse IP N/A. Vérifier ensuite via l’accès indépendant que les autres chemins de données et de gestion nécessaires fonctionnent toujours.

Si le mauvais port a été réinitialisé, restaurer sa zone et sa configuration IP précédentes via l’accès indépendant ou la console. Restaurer les configurations dépendantes supprimées à partir de l’inventaire préalable ou de la sauvegarde ; la réattribution d’une zone ne remplace pas cette restauration. Enfin, tester à nouveau la liaison, la passerelle, DHCP, DNS, le routage, les règles et Device Access.

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 : Vérifier d’abord si le port a été délibérément laissé sans zone ou si l’interface a été désactivée. Si le port était auparavant en production, comparer la zone et la configuration IP attendues à la configuration documentée et les restaurer via un accès indépendant. None n’est pas une réparation, mais supprime la configuration IP ; la procédure délibérée est expliquée ci-dessus sous Supprimer délibérément la configuration d’un port physique.
• 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