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 pare-feu prend en charge jusqu’à 100 zones au total.

Configurer une interface physique

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

1. Attribuer un Name explicite, 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.

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

• Configurer et tester une interface VLAN
• Configurer une interface LAG
• 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

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 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 appliances XGS. 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

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.

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.

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.

La Sophos Known Issues List décrit également un défaut propre aux versions SFOS 22.0 GA Build 411 et MR1 Build 490 : Si le trafic traversant un bridge est traduit avec SNAT ou MASQ et que la source et la destination se trouvent derrière le même membre physique du bridge, le filtre hairpin peut rejeter les paquets de réponse sans qu’ils apparaissent dans drppkt. Cela s’applique aussi lorsqu’un seul membre du bridge est utilisé activement. Le trafic passant par des membres physiques différents ou sans SNAT/MASQ n’est pas affecté. Les versions plus récentes, comme 22.0 MR2 Build 546, ne sont pas indiquées comme affectées dans la Known Issues List actuelle.

Si seules certaines connexions via le bridge échouent, examiner ensemble la topologie et le NAT, effectuer un test temporaire sans Source Translation ou utiliser une conception routée. 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.

XFRM pour IPsec route-based

Pour une connexion IPsec route-based, SFOS crée automatiquement une interface XFRM dans la zone VPN. Cela s’applique aussi bien aux connexions Any-to-any qu’aux connexions avec Traffic Selectors :

• 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 crée l’interface XFRM et ajoute automatiquement une route statique lors de l’établissement du tunnel. Il n’est pas possible d’attribuer une adresse IP ni d’ajouter une route à cette interface XFRM.

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. MTU et MSS sont importants pour diagnostiquer les problèmes de fragmentation ; Vérifier MTU et MSS en cas de problèmes VPN décrit la procédure.

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. Configurer Sophos SD-RED explique le choix du mode, 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.

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.

Lors de la suppression d’une interface virtuelle, SFOS peut supprimer les règles de pare-feu, configurations DHCP, entrées ARP, routes, interface hosts et autres références 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 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 Zone Binding et l’état. Un port physique n’est pas supprimé ; sa configuration peut être retirée en définissant la zone sur None.
• 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 : 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