Configurer zones et interfaces Sophos Firewall

Les zones et les interfaces font partie des bases les plus importantes d’une Sophos Firewall. Si elles sont bien planifiées, les règles firewall, le NAT, le VPN, Web Protection et le troubleshooting deviennent beaucoup plus simples. Si elles sont configurées trop vite, on obtient souvent un environnement où les règles deviennent confuses ou où des services d’administration sont accessibles depuis les mauvais endroits.

Une zone est un groupe logique de sécurité. Une interface est un raccordement physique ou virtuel, par exemple Port1, un VLAN, un bridge, un LAG, un alias, une interface RED ou une interface XFRM pour un VPN route-based. Chaque interface est affectée à une seule zone. Les règles firewall utilisent fortement ces zones, c’est pourquoi la structure des zones doit être pensée aussi du point de vue sécurité.

Pourquoi les zones sont importantes

Sur Sophos Firewall, les zones ne sont pas seulement un regroupement visuel. Elles définissent des domaines de sécurité et sont utilisées à plusieurs endroits:

• Les règles firewall utilisent Source zone et Destination zone.
• Device Access définit, par zone, quels services locaux de la firewall sont accessibles.
• NAT, SD-WAN, VPN, Web Protection et les logs sont plus faciles à comprendre avec des zones propres.
• Le troubleshooting est plus clair, car on voit immédiatement de quel domaine de sécurité vient un paquet et où il doit aller.

Une bonne séparation en zones ne supprime pas toutes les erreurs, mais elle impose des limites claires. Un réseau client, un réseau serveur, un WiFi invité et une DMZ ne devraient pas tous être traités comme LAN s’ils ont des risques et des règles différents. Sinon, de grandes règles Allow, des exceptions peu claires et des accès d’administration trop ouverts apparaissent souvent plus tard.

Une bonne zone répond toujours à cette question: quels réseaux ont le même niveau de confiance et doivent être traités de manière similaire? Si deux réseaux nécessitent des droits d’accès, des exigences de logs ou des accès d’administration différents, une zone dédiée ou au minimum un concept de règles très clair est utile.

Comprendre les zones standard

Sophos Firewall fournit plusieurs zones standard:

Les zones standard se trouvent sous Network > Zones. Des zones personnalisées peuvent être créées avec le type LAN ou DMZ. Des zones WAN ou VPN supplémentaires ne peuvent pas être créées librement, car ces types ont des fonctions particulières dans la firewall.

Important: une zone n’est pas une autorisation automatique. Même entre deux interfaces dans la même zone, des règles firewall adaptées sont nécessaires selon la direction et le scénario. Sophos indique explicitement que le trafic entre deux interfaces de zone LAN n’est pas automatiquement autorisé et nécessite une règle LAN-to-LAN adaptée.

Planifier les zones avant de les créer

Avant de créer les zones, il faut noter quels réseaux ont des exigences de sécurité différentes. Exemples typiques:

• LAN utilisateurs
• réseau serveurs
• réseau de management
• DMZ
• WiFi invité
• VoIP
• réseau caméras ou IoT
• réseau de production
• clients VPN
• connexions MPLS ou intersites

Une zone dédiée est utile lorsqu’un réseau nécessite ses propres règles, son propre Device Access ou un autre niveau de confiance. Plusieurs VLAN peuvent aussi se trouver dans la même zone s’ils doivent être traités de manière identique. Trop de zones ne rendent pas automatiquement une configuration plus sûre. Elles aident seulement si des règles claires existent derrière.

Pour beaucoup de petites et moyennes infrastructures, cette structure de base est un bon départ:

Tous les VLAN n’ont pas automatiquement besoin de leur propre zone. Si plusieurs VLAN clients reçoivent exactement les mêmes règles firewall, la même web policy et le même Device Access, ils peuvent rester dans une zone client commune. Mais si un VLAN peut accéder aux serveurs, un autre seulement à Internet et un troisième ne doit accéder à aucun service local de la firewall, la séparation doit être modélisée consciemment.

Un bon modèle:

Créer une nouvelle zone

Ouvrir Network > Zones et cliquer sur Add.

1. Donner un nom court et clair, par exemple Server, Guest, Management ou MPLS.
2. Choisir LAN ou DMZ comme type.
3. Sous Device Access, définir consciemment quels services locaux de la firewall doivent être accessibles depuis cette zone.
4. Enregistrer.

LAN ou DMZ comme type de zone?

Pour les zones personnalisées, Sophos Firewall permet généralement de choisir entre LAN et DMZ. Les deux types regroupent des interfaces pour les utiliser proprement ensuite dans les règles, Device Access et les policies. La différence se situe surtout dans l’idée de sécurité derrière la zone.

LAN s’utilise pour les réseaux internes et généralement de confiance: réseaux clients, réseaux serveurs internes, management, VoIP, imprimantes ou VLAN internes. Même avec une zone LAN, le trafic entre interfaces n’est pas automatiquement autorisé. Si deux zones LAN ou deux interfaces dans une zone LAN doivent communiquer, des règles firewall adaptées sont nécessaires.

DMZ s’utilise pour les réseaux plus exposés ou clairement isolés. Exemples typiques: serveurs web publics, reverse proxies, mail gateways, jump hosts ou systèmes devant être accessibles depuis plusieurs domaines de sécurité. Une DMZ doit être planifiée pour ne recevoir vers l’intérieur que les connexions nécessaires. Si un serveur DMZ est compromis, cela ne doit pas donner un large accès au LAN interne.

Règle simple:

Les interfaces HA doivent également être placées dans une zone DMZ. Pour des réseaux admin ou clients normaux, LAN est généralement le type le plus adapté.

Pour un réseau admin interne, HTTPS peut être pertinent. Pour des réseaux clients ou invités, il faut éviter l’accès de management. Ping/ping6 est souvent utile pour le troubleshooting, mais doit être activé volontairement. DNS n’est nécessaire que si les clients de cette zone utilisent la firewall comme serveur DNS.

⚠️ Device Access n’est pas la même chose qu’une règle firewall. L’accès aux services locaux de la firewall, par exemple WebAdmin, SSH, User Portal, DNS ou Ping, est contrôlé via Administration > Device access et les exceptions ACL locales.

Configurer une interface

Les interfaces se trouvent sous Network > Interfaces. Un port physique peut par exemple être utilisé comme LAN, WAN ou DMZ. Les interfaces virtuelles comme VLAN, Bridge, LAG, RED ou XFRM sont ajoutées séparément.

Pour une interface physique, ces points sont particulièrement importants:

Seules les interfaces dans la zone WAN reçoivent une configuration de passerelle. Les interfaces internes sont généralement configurées en statique. Pour les connexions opérateur, DHCP ou PPPoE peuvent être utiles.

Des noms parlants sont importants. PortD ne dira pas grand-chose dans six mois. Server VLAN, MPLS Provider, Guest WiFi ou Core Switch Trunk aident beaucoup plus au quotidien.

Créer une interface VLAN

Une interface VLAN se crée sous Network > Interfaces > Add interface > Add VLAN. Les éléments essentiels sont Parent Interface, Zone, VLAN ID et la configuration IP.

Le Parent Interface est le port physique ou le LAG sur lequel le VLAN taggé arrive. Si le switch envoie le VLAN sur un autre port, en untagged ou avec un mauvais VLAN ID, la firewall peut afficher une interface VLAN, mais les clients ne l’atteindront pas de manière fiable.

Pour les VLAN internes, on utilise généralement une adresse IP statique sur la firewall, par exemple comme default gateway du VLAN. La zone décide ensuite quelles règles firewall, web policies et paramètres Device Access s’appliquent. Lors de la création d’un VLAN, il ne faut donc pas seulement saisir l’adresse IP, mais aussi décider si le VLAN doit être Client, Server, Management, Guest, DMZ ou une autre zone.

Lire correctement le statut des interfaces

Sous Network > Interfaces, Sophos Firewall affiche des statuts. Ils sont très utiles pour le troubleshooting, car ils montrent rapidement si une interface est simplement mal configurée ou s’il n’y a réellement aucun lien.

Si une interface affiche de manière inattendue Not configured ou Unplugged, il ne faut pas commencer par chercher dans les règles firewall. Il faut d’abord vérifier le zone binding, le lien, le SFP/transceiver, le câble, le port switch et, avec DHCP/PPPoE, l’attribution d’adresse.

Classer VLAN, Bridge, LAG, Alias et RED

Sophos Firewall prend en charge différents types d’interfaces. Pour débuter, il faut surtout savoir quand utiliser quel type.

Pour les nouvelles installations, des VLAN sur un uplink clairement défini vers le switch sont généralement plus propres qu’un grand bridge sur plusieurs ports. Un bridge peut être pratique lors de migrations ou de setups très simples, car plusieurs ports sont traités comme un segment Layer 2 commun. C’est aussi son inconvénient: les limites de sécurité, les domaines de broadcast et les sources d’erreur sont moins visibles.

Nous recommandons donc les bridges uniquement de manière ciblée, pas comme design standard. En pratique, ils ont plusieurs inconvénients:

• Plusieurs ports partagent le même segment Layer 2, ce qui peut étendre les broadcasts et incidents.
• Les règles firewall deviennent moins lisibles, car la séparation n’est plus visible via interfaces, VLAN et zones dédiés.
• Le troubleshooting devient plus difficile, car flux de paquets, MAC learning, STP et configuration switch doivent être analysés ensemble.
• Une segmentation ultérieure devient plus coûteuse si un bridge simple doit devenir des réseaux client, serveur, invité ou management séparés.
• Les designs HA, VLAN, DHCP ou Device Access deviennent vite confus si trop de fonctions passent par un bridge.

Les bridges peuvent être créés sur Sophos Firewall avec des interfaces physiques, des interfaces RED, des VLAN ou des LAG. Ils peuvent fonctionner avec ou sans adresse IP propre. C’est souvent là que commencent les malentendus:

• Sans adresse IP, le bridge fonctionne de manière transparente, mais ne peut pas être utilisé comme interface routée normale.
• Si du routing est nécessaire sur un bridge, il faut lui attribuer une adresse IP.
• Le trafic entre membres du bridge nécessite toujours des règles firewall adaptées entre les zones concernées, par exemple LAN vers LAN.
• STP peut être utile si des chemins redondants existent et qu’il faut éviter les boucles.
• Les filtres VLAN et EtherType peuvent aider à limiter le trafic Layer 2 traversant le bridge.
• Sophos indique que du trafic sur des interfaces bridge sans IP peut être rejeté s’il correspond à une règle firewall avec Web Proxy Filtering ou à une règle NAT. Ces drops ne sont pas journalisés. Avec NAT, il faut faire particulièrement attention à Source Translation ou Override Source Translation.

Ce dernier point est important: si aucun log n’apparaît alors que le trafic via un bridge ne fonctionne pas, le problème ne vient pas toujours du Log Viewer. Il peut venir du mode bridge, du NAT ou de Web Proxy Filtering.

Si des VLAN existent déjà sur le switch, la firewall devrait les reprendre consciemment comme interfaces VLAN dédiées. On obtient ainsi des zones plus claires, des règles firewall plus propres et une meilleure maintenabilité.

RED Bridge: étendre un réseau entre sites

Il est techniquement possible d’intégrer des interfaces RED dans un bridge et d’étendre ainsi un réseau Layer 2 sur plusieurs sites. Cela peut aider dans des cas spéciaux, par exemple si une application doit absolument rester dans le même sous-réseau ou si une migration doit se faire sans changement IP immédiat.

Nous ne recommandons ce design qu’avec beaucoup de réserve. Un bridge via RED prolonge le domaine Layer 2 à travers le tunnel. Les broadcasts, ARP, paquets unicast inconnus et autres effets Layer 2 passent alors sur une connexion WAN ou Internet. Cela peut réduire la performance et rendre les erreurs plus difficiles à comprendre. Si le tunnel RED est instable, le réseau étendu est directement impacté.

Dans la plupart des cas, un design routé est préférable: chaque site possède ses propres sous-réseaux, la firewall route entre les réseaux et les règles firewall définissent précisément ce qui est autorisé. C’est plus propre, plus évolutif et nettement plus simple à dépanner.

LAG: bien planifier redondance et bande passante

Une Link Aggregation Group (LAG) regroupe plusieurs ports physiques en une interface logique. C’est utile lorsqu’on a besoin de redondance vers le core switch ou de plus de bande passante entre firewall et switch. LAG ne remplace pas une bonne séparation en zones. L’interface LAG reste une interface sur laquelle on exploite par exemple des VLAN ou à laquelle on affecte une zone.

Sophos Firewall prend principalement en charge deux modes courants:

Important: LACP ne fonctionne correctement que si l’autre côté est configuré correctement. Sur le switch, les ports doivent être dans le même groupe LAG, utiliser la même vitesse et le même mode duplex, et correspondre à la configuration de la firewall. Si une LAG est créée uniquement sur la firewall mais pas sur le switch, on obtient souvent des pertes de paquets ou des problèmes asymétriques difficiles à comprendre.

Quelques limites pratiques s’appliquent:

• Une LAG sur Sophos Firewall se compose de deux à quatre interfaces physiques.
• Seules des interfaces physiques non liées avec configuration statique peuvent être membres.
• Les interfaces PPPoE, Cellular WAN et WLAN ne peuvent pas être membres d’une LAG.
• Avec LACP (802.3ad), les ports membres doivent avoir le même type et la même vitesse.
• La xmit-hash-policy détermine comment les sessions sont réparties entre les liens. Une seule session TCP ne devient généralement pas plus rapide, car elle reste le plus souvent sur un seul lien.

Pour les petits environnements, un seul trunk port propre suffit souvent. LAG devient intéressant lorsque le core switch doit être connecté de manière redondante, que beaucoup de VLAN passent par le même uplink ou que la firewall a réellement besoin de plus de débit vers le switch.

XFRM: comprendre IPsec route-based comme interface

Une interface XFRM appartient au route-based IPsec VPN. Elle ne se planifie pas comme un VLAN ou un port physique normal, mais apparaît dans le contexte d’une connexion IPsec. Sophos Firewall crée automatiquement une interface XFRM lorsque, dans une connexion IPsec, les sous-réseaux locaux et distants sont tous deux définis sur Any.

C’est une différence importante par rapport aux tunnels IPsec policy-based classiques. Avec route-based VPN, non seulement l’IPsec Policy compte, mais aussi le routing, les règles firewall et l’interface XFRM. Cela rend les connexions intersites complexes plus flexibles, mais exige une planification propre:

• L’interface XFRM se trouve dans la zone VPN.
• Sous Administration > Device access, IPsec doit être autorisé pour la zone WAN afin que la connexion puisse être établie.
• Si les sous-réseaux locaux ou distants ne sont pas Any, aucune interface XFRM n’est créée.
• MTU et MSS sont particulièrement importants pour le VPN route-based, car IPsec ajoute de l’overhead.
• Une interface XFRM ne se désactive pas directement sous Network > Interfaces, mais via la connexion IPsec associée sous Site-to-site VPN > IPsec.

Pour les admins, XFRM est surtout pertinent lorsque du SD-WAN routing, du routing dynamique ou plusieurs réseaux via un tunnel de site doivent être contrôlés proprement. Si on a seulement besoin d’une connexion Site-to-Site très simple avec deux réseaux fixes, un tunnel policy-based classique est souvent plus facile à comprendre.

RED: les sites distants comme concept d’interface à part

Les interfaces RED ne sont pas des ports switch normaux. RED signifie Remote Ethernet Device et sert à connecter un site distant à la Sophos Firewall via un tunnel chiffré. Cela peut se faire avec du matériel SD-RED dédié ou avec des connexions RED firewall-to-firewall.

Avant la planification, il faut déterminer le mode requis:

Pour beaucoup d’entreprises, Standard/Unified est la variante la plus propre si le site doit être entièrement protégé par la firewall centrale. L’inconvénient est clair: si le tunnel RED tombe, le site peut aussi perdre l’accès Internet contrôlé centralement selon le design. Standard/Split réduit cette dépendance, mais signifie aussi que le trafic Internet local n’est plus entièrement filtré et journalisé par la Sophos Firewall centrale.

Avec RED, il faut vérifier tôt ces points:

• Le service RED doit être activé sous System services > RED.
• La connexion nécessite généralement TCP 3400, UDP 3410 et NTP 123.
• Les appareils SD-RED ont besoin d’une heure correcte, sinon le TLS handshake et l’établissement du tunnel peuvent échouer.
• Lors de la première mise en service, DHCP sur l’uplink est généralement plus simple, car l’appareil doit atteindre le provisioning.
• Les VLAN ne sont pas pertinents de la même façon dans tous les modes RED. Standard/Split et Transparent/Split ne sont pas conçus pour des frames VLAN taggées. Si des VLAN sont nécessaires derrière une SD-RED, il faut choisir le mode avec soin.
• Si un appareil RED se trouve derrière un routeur opérateur, les connexions sortantes et DNS/NTP doivent fonctionner.

RED est très pratique pour les petits sites, mais ne doit pas être traité comme un simple câble LAN. La décision essentielle est de savoir si le site doit être protégé centralement, rester autonome localement ou être seulement partiellement relié par le tunnel. Cette décision influence DHCP, DNS, VLAN, routing, règles firewall, logs et troubleshooting.

Restreindre proprement Device Access

Sous Administration > Device access, on voit quels services locaux de la firewall sont accessibles depuis quelles zones. Cela inclut notamment:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

En production, moins il y a de services locaux accessibles depuis une zone, mieux c’est. HTTPS et SSH en particulier ne devraient être autorisés que depuis des réseaux de management de confiance ou via une Local service ACL exception rule.

Si SSH est nécessaire, ce guide aide: Établir une connexion SSH à la Sophos Firewall.

Garder les dépendances en tête

Les changements d’interfaces sont rarement isolés. Sophos indique qu’ils peuvent affecter des configurations dépendantes, par exemple:

• Zone Binding
• DNS
• gateways
• SD-WAN routes
• hosts basés sur interface
• interfaces VLAN
• Dynamic DNS
• règles firewall
• règles NAT

Avant de grands changements, il faut donc vérifier sous Object usage où une interface, une zone ou un objet host est déjà utilisé. Sophos Firewall affiche l’utilisation des objets et renvoie directement vers de nombreuses configurations dépendantes.

Il faut être particulièrement prudent lors de la désactivation ou suppression:

• Si une interface est désactivée, sa configuration reste en place et son statut reste visible.
• Les tunnels Site-to-site IPsec où la firewall est l’initiatrice sont immédiatement déconnectés.
• Les tunnels Site-to-site IPsec en mode responder et les connexions Remote Access se déconnectent au plus tard par inactivité ou Dead Peer Detection.
• Les interfaces Alias et XFRM ne se désactivent pas directement comme des interfaces normales. Les Alias suivent l’interface physique, les XFRM se désactivent via Site-to-site VPN > IPsec.
• Si une interface virtuelle est supprimée, des règles firewall, configurations DHCP, entrées ARP, routes, hosts d’interface et autres références dépendantes peuvent aussi être supprimés.

Avant une suppression, il faut donc toujours vérifier si l’interface est utilisée dans des règles firewall, règles NAT, DHCP, routing, SD-WAN, Dynamic DNS ou objets host. Une suppression imprudente peut enlever plus que l’interface elle-même.

Erreurs fréquentes

Interface unbound ou disabled: vérifier si une zone est assignée. Une interface physique ne peut pas être supprimée, mais sa configuration peut être retirée en mettant la zone sur None.

Le VLAN ne fonctionne pas: vérifier VLAN ID, port switch, configuration tagged/untagged, native VLAN et parent interface correct.

Les clients n’atteignent pas la firewall en Ping ou HTTPS: ne pas vérifier d’abord les règles firewall normales. Vérifier Administration > Device access et les exceptions ACL locales.

Le trafic entre deux réseaux internes ne fonctionne pas: vérifier Source zone, Destination zone, objets réseau, routing et position de la règle firewall.

La passerelle WAN ne devient pas active: vérifier configuration IP, gateway IP, link status, identifiants PPPoE, DNS et éventuellement WAN link manager.

Plusieurs interfaces WAN dans le même sous-réseau: si plusieurs interfaces WAN utilisent des adresses IP du même sous-réseau, des problèmes ARP peuvent survenir et les gateways peuvent devenir injoignables. Si un opérateur fournit plusieurs IP publiques dans le même sous-réseau, des alias ou LAG sont généralement plus propres que plusieurs interfaces WAN séparées dans le même réseau.

SFP, vitesse de port ou breakout incorrect: la vitesse de port sur switch, routeur, transceiver et firewall doit correspondre. Un port 25 Gbit/s ne peut pas être relié directement à un port 40 Gbit/s sans technologie adaptée. Sur les modèles avec ports 40G ou 100G, des câbles breakout peuvent être nécessaires pour diviser un port en plusieurs ports plus petits.

Problèmes MTU avec VPN ou PPPoE: vérifier MTU et MSS. Avec du trafic VPN, une MTU trop élevée peut entraîner des pertes de paquets qui ressemblent à des problèmes de connexion aléatoires.

Troubleshooting

Pour la recherche d’erreurs, cet ordre est pratique:

1. Network > Interfaces: vérifier link status, adresse IP, zone et gateway.
2. Network > Zones: vérifier Device Access et type de zone.
3. Hosts and services: vérifier que les objets host et service sont corrects.
4. Rules and policies > Firewall rules: vérifier Source zone, Destination zone, services et ordre.
5. Rules and policies > NAT rules: si NAT est concerné, comparer soigneusement Original et Translated.
6. Log viewer: vérifier quelle règle ou quel drop s’applique.
7. Diagnostics > Tools > Packet capture: vérifier si les paquets arrivent et vers où ils sont transmis.

Lorsque zones et interfaces sont propres, l’étape suivante devient beaucoup plus simple: Comprendre et configurer correctement les règles Sophos Firewall. Si le trafic ne fonctionne pas malgré une zone apparemment correcte, la checklist La règle firewall ne s’applique pas: vérifier ordre, matching et logs aide. Pour une analyse plus poussée, on peut aussi utiliser Packet Capture dans WebAdmin et, pour les translations ou redirections de ports, consulter Comprendre NAT sur Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Informations complémentaires

• Sophos Firewall - Add a zone
• Sophos Firewall - Interfaces
• Sophos Firewall - Bridge interfaces
• Sophos Firewall - Link aggregation groups
• Sophos Firewall - Add a link aggregation group
• Sophos Firewall - XFRM interfaces
• Sophos Firewall - RED interfaces
• Sophos Firewall - Add a RED interface