Sophos Firewall Configurer les zones et les interfaces

Les zones et les interfaces font partie des principes fondamentaux les plus importants d’un Sophos Firewall. Si vous les planifiez soigneusement, vous faciliterez grandement les règles de pare-feu ultérieures, le NAT, le VPN, la protection Web et le dépannage. Si vous les assemblez trop rapidement, vous créez souvent un environnement dans lequel les règles deviennent confuses ou les services de gestion sont accessibles aux mauvais endroits.

Une Zone est un groupe de sécurité logique. Une Interface est une connexion physique ou virtuelle, par exemple Port1, un VLAN, un Bridge, un LAG, un Alias, une interface RED ou une interface XFRM pour VPN basé sur le routage. Chaque interface est affectée à exactement une zone. Les règles de pare-feu fonctionneront à l’avenir dans une large mesure avec ces zones. La structure des zones doit donc être planifiée non seulement sur le plan technique, mais également en termes de sécurité.

Quel article sur la conception de réseau convient ?

Les zones et les interfaces sont souvent le point de départ, mais pas toujours le véritable objectif de la configuration. Selon la tâche, un article plus spécifique convient mieux :

• Planifiez en gros les zones, les interfaces, les VLAN, les ponts, les LAG ou RED : Cet article.
• Configurez l’interface VLAN avec l’interface parent, DHCP, Device Access et les règles : Sophos Firewall Configurer et tester le VLAN.
• Créez et comprenez les règles de pare-feu entre les zones : Comprendre et configurer correctement les règles Sophos Firewall.
• Vérifiez le comportement du pont VLAN selon SFOS 22 : Sophos Firewall Utiliser le pont avec le marquage VLAN.
• Services de gestion sécurisés tels que WebAdmin, SSH, User Portal ou DNS : Sophos Firewall Accès sécurisé : configurez correctement Device Access.
• Classez NAT, SNAT, DNAT ou MASQ avec interfaces et zones : Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT.
• Publiez le serveur interne sur WAN ou DMZ : Serveur de publication via DNAT vers Sophos Firewall.
• Contrôlez le DNS pour les domaines internes ou les zones AD : Configurer les routes de requête DNS vers Sophos Firewall.
• Définissez les options DHCP pour les clients VoIP, PXE ou spéciaux : Configurer les options DHCP sur Sophos Firewall.
• Planifiez un VPN site à site avec interfaces tunnel : Sophos Firewall Configurer un VPN IPsec de site à site.
• Le trafic ne traverse pas la zone ou la règle attendue : Sophos Firewall La règle ne s’applique pas : vérifiez les causes.Cette séparation évite les erreurs de conception typiques. Une zone ne remplace pas une règle de pare-feu, un VLAN ne remplace pas un concept de sécurité et Device Access n’est pas la même chose qu’un trafic normal entre deux réseaux. Premièrement, il convient de préciser clairement quelles zones de sécurité existent. Les interfaces, VLAN, règles, NAT, DNS et accès de gestion sont ensuite construits en conséquence.

Pourquoi les zones sont importantes

Les zones du Sophos Firewall sont plus qu’un simple regroupement visuel. Celui-ci définit des zones de sécurité qui sont utilisées à plusieurs endroits :

• Les règles de pare-feu fonctionnent avec la Zone source et la Zone de destination.
• Device Access contrôle quels services de pare-feu locaux sont accessibles par zone.
• NAT, SD-WAN, VPN, protection Web et journaux sont plus faciles à comprendre grâce à des zones propres.
• Le dépannage devient plus clair car vous pouvez immédiatement voir de quelle zone de sécurité provient un paquet et où il est censé aller.

Un bon zonage n’empêche pas automatiquement toutes les erreurs, mais il impose des limites claires. Un réseau client, un réseau serveur, un WiFi invité et une DMZ ne doivent pas tous être simplement traités comme un « LAN » s’ils présentent des risques et des règles différents. Sinon, des règles d’autorisation étendues, des exceptions peu claires et un accès de gestion inutilement ouvert apparaîtront plus tard.

Les bonnes zones répondent toujours à cette question : Quels réseaux ont le même niveau de confiance et peuvent être traités de la même manière ? Si deux réseaux nécessitent des droits d’accès, des exigences de journalisation ou un accès de gestion différents, une zone distincte ou au moins un concept de règle très conscient est logique.

Il est important de séparer zone et objet réseau. La zone décrit par quel domaine de sécurité un paquet entre dans le firewall ou vers où il doit aller. L’objet réseau décrit la source IP concrète ou la destination concrète. Une règle n’est propre que lorsque les deux correspondent : Source zone ne doit pas seulement être un LAN approximatif tandis que Source networks and devices reste sur Any. À l’inverse, un objet réseau correct aide peu si le trafic entre par une autre zone que prévu.

Comprendre les zones standards

Sophos Firewall est livré avec plusieurs zones standards :

• LAN : Réseaux internes, clients, serveurs et réseaux de gestion.
• WAN : Liaisons montantes Internet, routeurs fournisseurs, adresses PPPoE, DHCP ou WAN statiques.
• DMZ : Serveurs accessibles au public, proxys inverses et services isolés.
• WiFi : Réseaux Wi-Fi, Sophos Access Points et segments sans fil.
• VPN : Remote Access VPN, VPN site à site et autres contextes de tunnel.

Les zones standards se trouvent sous Network > Zones. Des zones personnalisées peuvent être créées en tant que type LAN ou DMZ. Des zones WAN ou VPN supplémentaires ne peuvent pas être créées simplement librement car ces types de zones ont des fonctions spéciales dans le pare-feu.

Important : Une zone n’est pas une autorisation automatique. Selon l’orientation et le scénario, des règles de pare-feu appropriées sont également requises entre deux interfaces d’une même zone. Le trafic entre deux interfaces de zone LAN n’est pas automatiquement autorisé, mais nécessite une règle LAN à LAN appropriée.

Sophos Firewall prend en charge les zones personnalisées, mais pas comme remplacement illimité de règles propres. La limite officielle est de 100 zones au maximum. En pratique, il ne faut pas chercher à atteindre cette limite. Si presque chaque VLAN reçoit sa propre zone alors que beaucoup nécessitent les mêmes règles et le même Device Access, le jeu de règles devient souvent plus difficile à maintenir, pas plus sûr.

Planifier les zones avant la création

Avant la configuration, vous devez noter quels réseaux ont des exigences de sécurité différentes. Exemples typiques :

• Réseau local sur le lieu de travail
• Réseau de serveurs
• Réseau de gestion
• DMZ
• Wi-Fi invité
• VoIP
• Caméra ou réseau IoT
• Réseau de production
• Clients VPN
• Connexions MPLS ou de localisation

Une zone distincte a du sens si un réseau a besoin de ses propres règles, de son propre Device Access ou d’un autre niveau de confiance. Cependant, plusieurs VLAN peuvent également se trouver dans la même zone s’ils doivent être traités de la même manière. Trop de zones ne rendent pas automatiquement une configuration plus sécurisée. Les zones ne sont utiles que si elles sont régies par des règles claires.

Pour de nombreux environnements de petite et moyenne taille, cette structure de base est un bon début :

• LAN ou Client : clients de poste de travail normaux.
• Server : serveurs internes, NAS, serveurs d’applications et contrôleurs de domaine.
• Management : PC d’administration, surveillance, sauvegarde, gestion des commutateurs et des pare-feu.
• Guest ou WiFi : Réseaux WiFi invité ou BYOD avec accès limité.
• DMZ : Systèmes qui doivent être accessibles depuis Internet ou depuis plusieurs réseaux.
• WAN : Connexions Internet et fournisseur.
• VPN : Remote Access VPN ou contextes VPN de site à site.

Tous les VLAN n’ont pas automatiquement besoin de leur propre zone. Si plusieurs VLAN clients ont exactement les mêmes règles de pare-feu, politique Web et Device Access, ils peuvent rester dans une zone client commune. Cependant, si un VLAN est autorisé à atteindre les serveurs, un autre est uniquement autorisé à accéder à Internet et un troisième n’est pas censé avoir accès du tout aux services de pare-feu locaux, la séparation doit être modélisée consciemment.

Un bon modèle est :

• Autre niveau de confiance : Vérifiez votre propre zone.
• Propre accès de gestion au pare-feu : vérifiez votre propre zone ou votre propre règle ACL.
• Autres fonctions de journalisation ou autres fonctions de protection : votre propre zone peut être utile.
• Seulement une plage IP différente, mais même politique de sécurité : le concept de zone commune peut suffire.

Traduire le modèle de zone en une matrice d’accès

Après la planification des zones, vous devez déterminer brièvement quelle zone est autorisée à communiquer avec quelle autre zone. Cette matrice d’accès est souvent plus utile que la création immédiate de règles dans WebAdmin car elle rend visibles les contradictions.

Un exemple simple :

• Client à WAN : Autorisé pour le Web, DNS, NTP et les applications requises.
• Client à Server : Uniquement les ports d’application définis, pas Any.
• Guest à WAN : Autorisé, principalement avec la politique Web et la journalisation.
• Guest à Server : Normalement bloqué.
• IoT à Server : Uniquement vers des services précisément définis, par exemple MQTT, DNS ou NTP.
• Management à LAN, Server, DMZ : Accès administratif, restreint et journalisé.
• DMZ à LAN : Bloqué par défaut, autorise uniquement les connexions de retour explicites.
• VPN à Server : Uniquement les cibles et services internes requis.

Il n’est pas nécessaire que la matrice soit grande. Ce qui est important, c’est que chaque direction autorisée ait un but. Si une entrée ne peut pas être expliquée, elle ne devrait pas constituer une règle générale de pare-feu.

Pour chaque ligne, vous devez également noter :

• services et ports requis
• si la correspondance d’utilisateurs ou de groupes est nécessaire
• si NAT est impliqué
• si la journalisation doit rester active en permanence
• quelles fonctionnalités de sécurité sont adaptées, par exemple IPS, Web Policy ou Application Control
• qui est techniquement responsable de l’accès

Les règles de pare-feu réelles sont ensuite créées à partir de cette matrice. Les options détaillées et les erreurs typiques pour l’ordre des règles, la source, la destination, le NAT et la journalisation sont décrites dans Comprendre et configurer correctement les règles Sophos Firewall.

Vérification de la planification avant les modifications

Avant que des zones ou des interfaces ne soient créées, déplacées ou supprimées, les dépendances doivent être clarifiées par écrit. De nombreuses erreurs ultérieures ne sont pas causées par l’adresse IP elle-même, mais par des règles de pare-feu oubliées, des règles NAT, des serveurs DHCP, Device Access ou des décisions de routage.

Pour chaque nouvelle zone ou interface, il convient de répondre au moins à ces questions :

• Niveau de confiance du réseau : La zone, les règles de pare-feu et Device Access en dépendent.
• Utilisateurs et systèmes sur le réseau : Les clients, les serveurs, les invités, l’IoT, la VoIP et la gestion ont besoin de règles différentes.
• Passerelle par défaut : Le pare-feu est souvent la passerelle pour les VLAN, mais parfois pas pour les migrations.
• Source DHCP : Sophos Firewall, serveur DHCP interne ou relais DHCP doivent être volontairement planifiés.
• Serveur DNS : DNS affecte le filtrage Web, la résolution de noms et le dépannage.
• Services de pare-feu locaux : Device Access pour DNS, Ping, HTTPS, SSH ou portails doivent correspondre.
• Règles et chemins NAT : Sans pare-feu et règles NAT appropriées, l’interface n’est disponible que techniquement.
• Flux de test : Un client de test, une cible de test et une entrée de journal attendue permettent de gagner beaucoup de temps de recherche.

Une sauvegarde actuelle doit également être disponible pour les modifications productives. Si les interfaces sont déjà utilisées, l’utilisation de l’objet est obligatoire avant de modifier le nom, la liaison de zone, l’adresse IP ou le type d’interface.

Créer une nouvelle zone

Ouvrez Network > Zones et cliquez sur Ajouter.

1. Attribuez un nom court et unique, par exemple Server, Guest, Management ou MPLS.
2. Sélectionnez LAN ou DMZ comme type.
3. Sous Device Access, indiquez consciemment quels services de pare-feu locaux peuvent être accessibles depuis cette zone.
4. Enregistrez.

Après l’enregistrement, la zone doit être vérifiée directement à deux endroits : sous Network > Zones pour le nom, le type et Device Access, puis dans une règle de firewall de test comme Source zone ou Destination zone sélectionnable. Si la zone existe mais qu’aucune interface ne s’y trouve, aucun trafic de production ne passera encore par elle.

LAN ou DMZ comme type de zone ?

Pour vos propres zones, vous pouvez généralement choisir entre LAN et DMZ sur le Sophos Firewall. Les deux types regroupent les interfaces afin qu’elles puissent ensuite être utilisées proprement dans les règles, Device Access et les politiques. La différence réside principalement dans l’idée de sécurité derrière la zone.

LAN est utilisé pour les réseaux internes fondamentalement fiables. Il s’agit par exemple des réseaux clients, des réseaux de serveurs internes, des réseaux de gestion, de la VoIP, des imprimantes ou des VLAN internes. Il en va de même pour une zone LAN : le trafic entre les interfaces n’est pas automatiquement autorisé. Si deux zones LAN ou deux interfaces au sein d’une zone LAN doivent communiquer entre elles, des règles de pare-feu appropriées sont requises.DMZ est utilisé pour les réseaux présentant un risque plus élevé ou une isolation claire. Des exemples typiques sont les serveurs Web accessibles au public, les proxys inverses, les passerelles de messagerie, les hôtes de saut ou les systèmes qui doivent être accessibles à partir de plusieurs zones de sécurité. Une DMZ doit être planifiée de manière à ce qu’elle ne reçoive que les connexions internes nécessaires. Si un serveur compromis se trouve dans la DMZ, cela ne devrait pas automatiquement entraîner un accès généralisé au réseau local interne.

En règle générale simple :

• LAN : réseaux internes généralement fiables et qui communiquent principalement de manière sortante ou interne.
• DMZ : réseaux exposés ou particulièrement isolés où l’accès interne doit être strictement limité.

Les interfaces HA appartiennent également à une zone DMZ. Pour les réseaux d’administrateur ou de client normaux, LAN est généralement le type le plus approprié.HTTPS peut être utile pour un réseau d’administrateur interne. Pour les réseaux clients ou invités normaux, l’accès de gestion doit être évité. Ping/ping6 est souvent utile pour le dépannage, mais doit être activé consciemment. DNS n’est nécessaire que si les clients de cette zone utilisent le pare-feu comme serveur DNS.

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

Configurer l’interface

Les interfaces peuvent être trouvées sous Network > Interfaces. Par exemple, un port physique peut être exploité comme un LAN, un WAN ou une DMZ. Des interfaces virtuelles telles que VLAN, Bridge, LAG, RED ou XFRM sont également créées.

Ces points sont particulièrement importants pour une interface physique :

• Name : nom descriptif des règles et journaux ultérieurs.
• Hardware : port physique, par exemple Port1, Port2 ou PortA.
• Network zone : Zone de sécurité dans laquelle se trouve l’interface.
• IPv4 configuration : Statique, DHCP ou PPPoE.
• IPv6 configuration : Statique, DHCP ou Délégué, selon l’environnement.
• Gateway : pertinent uniquement pour les interfaces WAN.
• MTU / MSS : important pour les problèmes PPPoE, VPN, SD-WAN et de fragmentation.

Seules les interfaces de la zone WAN reçoivent une configuration de passerelle. Les interfaces internes sont généralement adressées de manière statique. DHCP ou PPPoE peuvent être utiles pour les connexions des fournisseurs.

Si le fournisseur propose IPv6 via la délégation de préfixe, vous devez planifier les restrictions et le processus séparément. L’article pratique à ce sujet est Configurer la délégation de préfixe IPv6 sur Sophos Firewall.

Les noms significatifs sont importants. PortD ne signifie pas grand-chose en six mois. Server VLAN, MPLS Provider, Guest WiFi ou Core Switch Trunk aident beaucoup plus pendant l’exploitation.

Une interface physique existante se modifie ainsi :

1. Ouvrir Network > Interfaces.
2. Ouvrir le menu du port souhaité et choisir Edit interface.
3. Vérifier Name, Network zone, la configuration IP, la passerelle et MTU/MSS.
4. Pour les interfaces WAN, vérifier aussi le nom de la passerelle et l’IP de la passerelle.
5. Enregistrer, puis contrôler le link status, le gateway status et le Log Viewer.

Avant de modifier une interface de production, Object usage doit être ouvert. Les modifications d’interface peuvent toucher le zone binding, DNS, les passerelles, les SD-WAN routes, les hôtes basés sur une interface, les interfaces VLAN, Dynamic DNS, les règles de firewall et NAT. Lors de la suppression d’une interface virtuelle, Sophos peut également supprimer des configurations dépendantes comme des règles de firewall, DHCP ou des références de routage. C’est précisément là que surviennent les interruptions désagréables quand on n’avait que le nom du port en tête.

Avant les mises à niveau de firmware, il faut aussi veiller à ce que les noms d’interface, de matériel et de branche ne se terminent pas par un long bloc de chiffres. Une erreur d’affichage WebAdmin est documentée dans les notes de version SFOS si ces noms se terminent par dix chiffres ou plus, par exemple VLAN_1234567890. Vérifiez Sophos Firewall avant la mise à niveau vers SFOS 22 convient à la planification de la mise à niveau et aux tests spécifiques.

Créer une interface VLAN

Pour un processus ciblé avec interface parent, marquage des commutateurs, DHCP, Device Access, règles de pare-feu et tests, Sophos Firewall Configurer et tester le VLAN convient. La section suivante classe les VLAN dans le modèle d’interface et de zone plus large.

Une interface VLAN est créée sous Network > Interfaces > Add interface > Add VLAN. L’interface parent, la zone, l’ID VLAN et la configuration IP sont particulièrement importants.

L’interface parent est le port physique ou un LAG sur lequel le VLAN arrive étiqueté. Si le commutateur envoie le VLAN sur un autre port, non balisé ou avec un ID VLAN incorrect, le pare-feu voit une interface VLAN, mais les clients ne peuvent pas l’atteindre de manière fiable.

Pour les VLAN internes, une adresse IP statique est généralement utilisée sur le pare-feu, par exemple comme passerelle par défaut pour ce VLAN. La zone décide ultérieurement quelles règles de pare-feu, politiques Web et paramètres Device Access s’appliquent. C’est exactement pourquoi vous ne devez pas simplement saisir l’adresse IP lors de la création d’un VLAN, mais également déterminer directement si le VLAN nécessite Client, Server, Management, Guest, DMZ ou une autre zone.

Un exemple pratique concret avec les profils de port de commutateur, le comportement balisé/non balisé, DHCP et la séquence de test peut être trouvé dans Configurer le VLAN sur Sophos Firewall et le commutateur UniFi.

Sur le matériel XGS, Sophos n’indique pas de nombre fixe et strict d’interfaces VLAN par interface physique. Cela ne signifie pas qu’un seul port parent soit toujours la meilleure décision opérationnelle. Pour la performance, le dépannage et la maintenabilité, les VLAN doivent être répartis de manière judicieuse sur des ports physiques ou des LAG, surtout avec de nombreux VLAN, une forte charge est-ouest ou des conceptions HA.

Déploiement propre du VLAN

Un VLAN n’est considéré comme complet que lorsque non seulement l’interface a été créée, mais que le commutateur, le DHCP, le DNS, les règles de pare-feu et la journalisation s’emboîtent également. Surtout avec les nouveaux réseaux, il est facile de chercher au mauvais endroit : la règle du pare-feu semble correcte, mais le commutateur envoie sans balise. Ou bien le client obtient une adresse IP, mais Device Access n’autorise pas l’accès DNS au pare-feu.

Pour chaque nouveau VLAN, ces points doivent être vérifiés :

• Interface pare-feu : L’ID VLAN, l’interface parent, la zone, l’adresse IP et le masque de sous-réseau correspondent à la conception.
• Port du commutateur : La liaison montante vers le pare-feu est configurée comme une jonction et le VLAN est balisé.
• Port d’accès ou SSID : Le port client ou le SSID WLAN mappe les clients au bon VLAN.
• Passerelle : L’adresse IP du pare-feu dans le VLAN est la passerelle par défaut attendue ou le routage est documenté différemment.
• DHCP : Le serveur DHCP, le relais DHCP ou le serveur DHCP externe distribue l’adresse IP, la passerelle, le DNS et le bail corrects.
• DNS : Les clients peuvent résoudre les noms internes et externes comme prévu.
• Device Access : Seuls les services de pare-feu locaux requis sont autorisés depuis la zone, par exemple DNS ou Ping.
• Règle de pare-feu : La zone source, le réseau source, la zone de destination, les services et la journalisation correspondent au flux de test.
• NAT : Actif uniquement si le trafic doit réellement être traduit. Pour un trafic interne normal, le NAT est généralement erroné.
• Test : Log Viewer affiche le pare-feu attendu Rule ID ; si nécessaire, Packet Capture confirme le flux des paquets.

En tant que test d’acceptation, il ne suffit pas qu’un client reçoive une adresse IP. Un test utile comprend plusieurs étapes : connectez le client via DHCP, pingez la passerelle, vérifiez le DNS, testez une connexion interne autorisée, vérifiez que l’accès interdit est délibérément bloqué, puis vérifiez l’accès à Internet. De cette façon, vous pouvez voir si le VLAN, la zone, Device Access, la règle de pare-feu et le NAT correspondent vraiment.

Si plusieurs VLAN sont créés en même temps, vous devez utiliser un client de test distinct ou au moins une adresse IP de test unique pour chaque VLAN. Sinon, Log Viewer et Packet Capture deviendront inutilement déroutants. Testez la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture convient à la vérification réelle du flux de paquets.

Lire correctement l’état de l’interface

Sous Network > Interfaces, le Sophos Firewall affiche des messages d’état. Ces messages d’état sont très utiles lors du dépannage, car vous pouvez rapidement voir si une interface est simplement mal configurée ou s’il n’y a vraiment aucun lien.

• Not configured: L’interface n’est affectée à aucune zone. Il ne peut donc pas être utilisé de manière significative tant qu’une zone n’a pas été délimitée.
• Connected : L’interface est configurée et connectée.
• Connecting : Une nouvelle adresse IP est en cours d’obtention, par exemple via DHCP.
• Disconnected : L’adresse IP a été libérée.
• Disconnecting : L’adresse IP est en cours de publication.
• Unplugged : Il n’y a pas de connexion physique. Pour le WiFi, cela peut également signifier qu’aucun Access Point n’est connecté ou qu’aucun réseau sans fil n’est attribué.
• Not available : Les ports FleXi ont été configurés, mais le module de port FleXi correspondant n’est plus présent.

Si une interface affiche de manière inattendue Not configured ou Unplugged, vous ne devez pas rechercher d’abord les règles de pare-feu. Vérifiez d’abord la liaison de zone, la liaison, le SFP/émetteur-récepteur, le câble, le port du commutateur et, pour DHCP/PPPoE, l’attribution d’adresse.

Classer VLAN, Bridge, LAG, Alias et RED

Sophos Firewall prend en charge différents types d’interface. Pour les débutants, le plus important est de savoir quel type a du sens.

• VLAN : ​​​​Standard pour les réseaux segmentés sur un port trunk.
• Bridge : Connexion transparente de plusieurs ports, souvent pour des configurations ou des migrations simples.
• LAG : Regroupement de plusieurs liens physiques pour la redondance ou la bande passante.
• Alias : adresse IP supplémentaire sur une interface existante.
• RED : Périphérique Ethernet distant pour les emplacements externes.
• XFRM : Interface VPN IPsec basée sur le routage.

Les interfaces Alias sont souvent sous-estimées. Elles sont particulièrement utiles lorsqu’un fournisseur livre plusieurs adresses IP publiques dans le même sous-réseau. Plusieurs interfaces WAN séparées dans le même sous-réseau provoquent des problèmes ARP sur Sophos Firewall et peuvent rendre les passerelles inaccessibles. Dans ce type de conception, un alias sur l’interface WAN existante ou un LAG correctement planifié est généralement le meilleur choix.

Pour les nouvelles installations, un VLAN sur une liaison montante clairement définie vers le commutateur est généralement plus propre qu’un grand pont sur plusieurs ports. Un pont peut être utile pour les migrations ou les configurations très simples, car plusieurs ports sont traités comme un segment commun de couche 2. Mais c’est justement là l’inconvénient : les limites de sécurité, les domaines de diffusion et les sources d’erreur deviennent moins clairement visibles.

Nous recommandons donc uniquement les ponts de manière spécifique et non en tant que version standard. En pratique, les ponts présentent plusieurs inconvénients :

• Plusieurs ports partagent le même segment de couche 2, ce qui permet aux diffusions et aux interférences d’avoir plus facilement un impact sur plusieurs appareils.
• Les règles de pare-feu deviennent moins claires car la séparation n’est plus clairement visible entre vos propres interfaces, VLAN et zones.
• Le dépannage devient plus difficile car le flux de paquets, l’apprentissage MAC, les problèmes STP et la configuration du commutateur doivent être pris en compte ensemble.
• La segmentation ultérieure devient plus complexe si des réseaux clients, serveurs, invités ou de gestion distincts doivent être créés à partir d’un simple pont.
• Les conceptions HA, VLAN, DHCP ou accès aux périphériques deviennent rapidement déroutantes si trop de fonctions s’exécutent sur un pont.

Des ponts peuvent être créés sur le Sophos Firewall via des interfaces physiques, des interfaces RED, des VLAN ou des LAG et exploités avec ou sans leur propre adresse IP. C’est précisément là que surgissent souvent des malentendus :

• Sans adresse IP, le pont fonctionne de manière transparente, mais ne peut pas être utilisé comme une interface routée normale.
• Si un routage est requis sur un pont, celui-ci doit se voir attribuer une adresse IP.
• Pour le trafic entre les membres du pont, des règles de pare-feu appropriées sont toujours requises entre les zones impliquées, par exemple LAN à LAN.
• STP peut être utile s’il existe des chemins redondants et si les boucles de pont doivent être évitées. Cependant, lorsque HA est actif, STP ne peut pas être activé sur les interfaces Bridge.
• Les filtres VLAN et les filtres EtherType peuvent aider à limiter le trafic de couche 2 transitant par un pont. Si un filtre VLAN est activé mais qu’aucun VLAN autorisé n’est saisi, le pare-feu rejette le trafic tagué de tous les VLAN. Le trafic non tagué n’est pas concerné.
• Le trafic sur les interfaces de pont sans adresse IP peut être supprimé s’il rencontre une règle de pare-feu avec filtrage de proxy Web ou une règle NAT. Ces baisses ne sont pas enregistrées. Avec NAT, vous devez accorder une attention particulière à la traduction source ou remplacer la traduction source.

Ce dernier point est important : si soudainement vous ne voyez plus aucun journal sur un pont, même si le trafic ne semble pas fonctionner, le problème ne vient pas toujours du Log Viewer. Cela peut être dû au mode pont, au filtrage NAT ou au proxy Web.

Si des VLAN existent déjà sur le commutateur, le pare-feu doit consciemment adopter ces VLAN comme ses propres interfaces VLAN. Cela se traduit par des zones plus claires, des règles de pare-feu plus claires et est généralement plus facile à maintenir à long terme.

SFOS 22 : Vérifiez le trafic sur les ponts, le SNAT et l’épingle à cheveux

Avec SFOS 22, il existe un cas particulier de pont supplémentaire qui est rapidement négligé dans les migrations. Le routage sur une interface de pont peut échouer si SNAT ou MASQUERADE est appliqué au trafic sur le pont et si la source et la destination sont accessibles via le même membre de pont physique. Dans ce scénario en épingle à cheveux, les paquets de réponse peuvent être supprimés sur le pont sans que la suppression soit clairement visible dans drppkt.

Il ne s’agit pas d’un problème normal de correspondance de règles. Si le Log Viewer affiche peu de choses, que la règle semble correcte et que seules certaines connexions sur un pont échouent, vous devez vérifier ensemble la topologie du NAT et du pont :

• Le SNAT ou le MASQUERADE sont-ils vraiment nécessaires sur le trafic des ponts ?
• La source et la destination passent-elles par le même membre de pont physique ?
• Y a-t-il un seul membre de pont activement utilisé ?
• Une conception routé ou une interface physique dédiée serait-elle plus propre ?
• Le trafic peut-il être testé sans traduction de la source ?

Il existe également un cas SFOS 22 distinct pour le trafic balisé VLAN vers le pare-feu lui-même. La procédure pratique se trouve dans Sophos Firewall Vérifier les VLAN du pont selon SFOS 22.

RED Bridge : étendre le réseau sur plusieurs sites

Il est techniquement possible d’inclure des interfaces RED dans un pont et ainsi d’étendre un réseau de couche 2 sur plusieurs emplacements. Cela peut être utile dans des cas particuliers, par exemple lorsqu’une application doit rester dans le même sous-réseau ou qu’une migration doit avoir lieu sans modification immédiate de l’adresse IP.

Nous ne recommandons cette conception qu’avec beaucoup de prudence. Un pont sur RED étend le domaine de couche 2 sur le tunnel. Cela entraîne l’exécution de diffusions, d’ARP, de paquets de monodiffusion inconnus et d’autres effets de couche 2 sur une connexion WAN ou Internet. Cela peut dégrader les performances et rendre les erreurs plus difficiles à comprendre. Si le tunnel RED est instable, cela affectera également directement le réseau étendu.

Dans la plupart des cas, une conception routée est préférable : chaque emplacement possède ses propres sous-réseaux, les routes du pare-feu entre les réseaux et les règles du pare-feu définissent spécifiquement ce qui est autorisé. C’est plus propre, plus évolutif et beaucoup plus pratique lors du dépannage.

LAG : Planifiez correctement la redondance et la bande passante

Un Groupe d’agrégation de liens (LAG) combine plusieurs ports physiques dans une interface logique. Cela est logique si vous avez besoin d’une redondance sur le commutateur principal ou si vous souhaitez fournir plus de bande passante entre le pare-feu et le commutateur. Mais le GAL ne remplace pas le zonage propre. Au final, l’interface LAG n’est encore qu’une interface sur laquelle vous pouvez, par exemple, exploiter des VLAN ou attribuer une zone.

Sophos Firewall prend principalement en charge deux modes de fonctionnement typiques :

• Active-Backup : Un lien est actif, un autre prend le relais en cas de panne. C’est simple et bon pour la redondance.
• LACP (802.3ad) : Plusieurs liens peuvent être utilisés en parallèle. Cela nécessite LACP des deux côtés, c’est-à-dire sur le pare-feu et le commutateur.

C’est important : LACP ne fonctionne correctement que si l’autre côté est correctement configuré. Sur le commutateur, les ports doivent appartenir au même groupe LAG, utiliser la même vitesse et le même mode duplex et correspondre à la configuration du pare-feu. Si vous créez uniquement un LAG sur le pare-feu mais ne configurez pas le commutateur de manière appropriée, des pertes de paquets difficiles à comprendre ou des problèmes de connexion asymétrique surviennent souvent.

Certaines limitations pratiques s’appliquent aux LAG :

• Un LAG sur le Sophos Firewall est constitué de deux à quatre interfaces physiques.
• Seules les interfaces physiques non liées avec une configuration statique peuvent être membres.
• Les interfaces PPPoE, Cellular WAN et WLAN ne peuvent pas être utilisées en tant que membres du LAG.
• Pour LACP (802.3ad), les ports membres doivent avoir le même type et la même vitesse.
• Le xmit-hash-policy détermine la manière dont les sessions sont réparties sur les liens. Une seule session TCP ne devient normalement pas soudainement plus rapide car elle reste généralement sur un lien.

Pour les petits environnements, un seul port de jonction propre est souvent suffisant. LAG est particulièrement intéressant si le commutateur principal doit être connecté de manière redondante, si de nombreux VLAN fonctionnent sur la même liaison montante ou si le pare-feu a vraiment besoin de plus de débit vers le commutateur.

XFRM : Comprendre IPsec basé sur les routes en tant qu’interfaceUne interface XFRM appartient à la rubrique VPN IPsec basé sur une route. Il n’est pas prévu comme un VLAN ou un port physique normal, mais est créé dans le contexte d’une connexion IPsec. Le Sophos Firewall crée automatiquement une interface XFRM lorsque les sous-réseaux locaux et distants sont définis sur Any sur une connexion IPsec.

Il s’agit d’une différence importante par rapport aux tunnels IPsec classiques basés sur des politiques. Avec un VPN basé sur le routage, non seulement la politique IPsec, mais également le routage, les règles de pare-feu et l’interface XFRM décident où va le trafic. Cela rend les connexions de sites plus complexes plus flexibles, mais nécessite une planification minutieuse :

• L’interface XFRM est dans la zone VPN.
• Sous Administration > Device access, il faut autoriser IPsec 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 les VPN basés sur les routes, car IPsec crée une surcharge supplémentaire. La procédure de l’examen pratique se trouve dans Sophos Firewall Vérifiez MTU et MSS pour les problèmes VPN.
• Une interface XFRM n’est pas désactivée directement sous Network > Interfaces, mais plutôt via la connexion IPsec associée sous Site-to-site VPN > IPsec.

XFRM est particulièrement pertinent pour les administrateurs lorsque le routage SD-WAN, le routage dynamique ou plusieurs réseaux doivent être correctement contrôlés via un tunnel de localisation. Si tout ce dont vous avez besoin est une connexion très simple de site à site avec deux réseaux fixes, un tunnel classique basé sur des règles est souvent plus facile à comprendre.

RED : emplacements externes comme concept d’interface distinct

Les interfaces RED ne sont pas un port de commutateur normal. RED signifie Remote Ethernet Device et est utilisé pour connecter un emplacement externe au Sophos Firewall via un tunnel crypté. Cela peut être implémenté avec du matériel SD-RED dédié ou avec des connexions RED pare-feu à pare-feu.

Avant la planification, il convient de déterminer clairement quel mode de fonctionnement est requis :

• Standard/Unified : Le pare-feu gère le réseau distant. Le trafic passe par le pare-feu central. Très facile à contrôler, mais dépendant du tunnel.
• Standard/Split : Seuls les réseaux cibles définis traversent le tunnel, le trafic Internet sort localement à l’emplacement. Moins de bande passante au sein du siège, mais moins de contrôle central.
• Transparent/Split : RED se bloque de manière transparente dans un réseau existant. Idéal pour les cas particuliers, mais plus difficile à comprendre et ne convient pas à toutes les conceptions.
• Manual/Split : Plus de configuration réseau manuelle. Le site peut continuer à fonctionner localement en cas de panne du tunnel.

Pour de nombreuses entreprises, Standard/Unified est l’option la plus propre si l’emplacement doit être entièrement protégé via le pare-feu central. L’inconvénient est clair : si le tunnel RED tombe en panne, le site perd également l’accès Internet contrôlé de manière centralisée, selon la conception. Standard/Split réduit cette dépendance, mais signifie également que le trafic Internet local n’est plus complètement filtré et enregistré via le Sophos Firewall central.

Avec RED, vous devriez vérifier ces points dès le début :

• Le service RED doit être activé à System services > RED.
• TCP 3400, UDP 3410 et NTP 123 sont généralement requis pour la connexion.
• Les appareils SD-RED ont besoin d’une heure correcte, sinon la prise de contact TLS et l’établissement du tunnel pourraient échouer.
• Lors de la première mise en service, le DHCP sur la liaison montante est généralement plus simple car l’appareil doit réaliser le provisionnement.
• Les VLAN ne sont pas également utiles dans tous les modes RED. Standard/Split et Transparent/Split ne sont pas destinés aux trames balisées VLAN. Si des VLAN sont nécessaires derrière un SD-RED, vous devez choisir le mode de fonctionnement avec une attention particulière.
• Si un appareil RED se trouve derrière un routeur fournisseur, les connexions sortantes et DNS/NTP doivent fonctionner.

RED est très pratique pour les petits sites, mais vous ne devez pas le traiter comme un câble LAN normal. Le facteur décisif est de savoir si le site doit être protégé de manière centralisée, localement autonome ou seulement partiellement relié via le tunnel. Cette décision affecte DHCP, DNS, VLAN, le routage, les règles de pare-feu, la journalisation et le dépannage.

Restreindre proprement Device Access

Sous Administration > Device access, vous pouvez voir quels services de pare-feu locaux sont accessibles à partir de quelles zones. Ceux-ci incluent, entre autres :

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

Pour les environnements productifs, moins il y a de services locaux accessibles depuis une zone, mieux c’est. En particulier, HTTPS et SSH ne doivent être autorisés qu’à partir de réseaux de gestion dignes de confiance ou via une règle d’exception ACL de service local.

Si SSH est nécessaire, ce guide vous aidera : Établissez une connexion SSH au Sophos Firewall.

Pour les zones personnalisées, Device Access peut aussi être visible directement lors de la création ou de la modification de la zone. Techniquement, il s’agit toujours de services locaux du firewall, pas du trafic transit normal. Si les clients utilisent le firewall comme serveur DNS, DNS doit être autorisé pour cette zone. Si des administrateurs doivent accéder à WebAdmin, cela ne doit pas être activé largement pour toute la zone client, mais via un réseau de gestion ou une exception Local Service ACL.

Gardez les dépendances à l’esprit

Les modifications apportées aux interfaces sont rarement isolées. Zone binding, DNS, passerelles, SD-WAN routes, hôtes basés sur une interface, interfaces VLAN, Dynamic DNS, règles de firewall et règles NAT peuvent dépendre de la même interface. Avant des modifications importantes, il faut vérifier sous Object usage où une interface, une zone ou un objet hôte est déjà utilisé. Sophos Firewall affiche l’utilisation des objets et renvoie directement vers de nombreuses configurations dépendantes.

Vous devez être particulièrement prudent lors de la désactivation ou de la suppression :

• Si une interface est désactivée, la configuration est conservée et l’état est toujours visible.
• Les tunnels IPsec de site à site dont le pare-feu est l’initiateur sont immédiatement déconnectés.
• Les tunnels IPsec de site à site en tant que répondeurs et les connexions d’accès à distance sont déconnectés au plus tard en raison d’une inactivité ou d’une détection de homologue mort.
• Les interfaces Alias ​​​​et XFRM ne peuvent pas être désactivées directement comme les interfaces normales. Les interfaces alias suivent l’interface physique, les interfaces XFRM sont désactivées via Site-to-site VPN > IPsec.
• Lorsqu’une interface virtuelle est supprimée, les règles de pare-feu dépendantes, les configurations DHCP, les entrées ARP, les routes, les hôtes d’interface et autres références peuvent être supprimés avec elle.

Par conséquent, avant de supprimer, vous devez toujours vérifier si l’interface est utilisée dans les règles de pare-feu, les règles NAT, DHCP, le routage, le SD-WAN, le DNS dynamique ou les objets hôtes. Une suppression imprudente peut supprimer bien plus que l’interface elle-même.

Implémenter les modifications en toute sécurité

Les changements d’interface doivent être progressifs. Les emplacements distants, les clusters haute disponibilité, les interfaces WAN, les liaisons VLAN, les interfaces XFRM et les réseaux de gestion sont particulièrement critiques. Une petite modification de la liaison de zone peut suffire pour que les règles de pare-feu, les routes Device Access ou SD-WAN ne fonctionnent plus comme prévu.

Processus éprouvé :

1. Documentez la configuration actuelle de l’interface et de la zone.
2. Vérifier les dépendances via Object usage et noter directement les résultats les plus importants.
3. Créez une sauvegarde.
4. Définissez la fenêtre de maintenance ou le délai de repli.
5. Ajoutez d’abord une nouvelle zone ou une nouvelle interface, ne supprimez pas immédiatement l’ancienne configuration.
6. Préparez le client de test ou le trafic de test.
7. Après la modification, vérifiez l’état du lien, l’adresse IP, la passerelle, le DHCP et le DNS.
8. Validez la règle de pare-feu, la règle NAT et Device Access avec Log Viewer ou Packet Capture.
9. Supprimez les anciennes règles, interfaces ou objets uniquement une fois que le nouveau chemin est stable.

Une sauvegarde n’est qu’une partie du chemin du retour. Avant les changements critiques d’interface ou de zone, il convient également de documenter quelles anciennes adresses IP, zones, ID VLAN, passerelle, route, route SD-WAN, règle de pare-feu et règle NAT doivent être restaurées en cas d’abandon. Sophos Firewall Créer ou restaurer une sauvegarde convient au processus de sauvegarde et de restauration proprement dit.

• La zone de gestion ou Device Access est ajustée : L’accès administrateur alternatif est testé avant que l’ancienne accessibilité ne soit supprimée.
• L’interface ou la passerelle WAN est modifiée : L’ancien chemin du fournisseur, les valeurs PPPoE/DHCP/statiques et la route SD-WAN sont documentés.
• Le tronc VLAN est en cours de conversion : L’ancien ID VLAN, le VLAN natif, le profil du port de commutateur et l’interface du pare-feu sont traçables.
• Bridge, LAG ou RED est modifié : L’état du lien, les ports impliqués et l’accès à l’emplacement peuvent être vérifiés indépendamment.
• L’interface XFRM ou VPN est modifiée : Les règles de tunnel, de routage et de pare-feu sont validées avant de supprimer l’ancien chemin.

Une attention particulière doit être accordée au comportement balisé/non balisé lors des migrations VLAN. Si le commutateur et le pare-feu utilisent des ID de VLAN, des VLAN natifs ou des profils de liaison différents, soit le pare-feu ne voit aucun trafic, soit le trafic se retrouve dans la mauvaise zone.

Pour les emplacements distants, il doit toujours y avoir un chemin d’accès en dehors de l’interface que vous venez de modifier. Il peut s’agir de Sophos Central, d’un deuxième accès WAN, d’un administrateur local sur site ou d’un réseau de gestion distinct.

Pierres d’achoppement typiques

L’interface n’est pas liée ou désactivée : Vérifiez d’abord si une zone est attribuée. Une interface physique ne peut pas être supprimée, mais sa configuration peut être supprimée en définissant la zone sur None.

Le VLAN ne fonctionne pas : Vérifiez l’ID du VLAN, le port du commutateur, la configuration balisée/non balisée, le VLAN natif et l’interface parent.

Les clients ne peuvent pas atteindre le pare-feu via ping ou HTTPS : Ne vérifiez pas d’abord les règles normales du pare-feu. Administration > Device access et les exceptions ACL locales sont cruciales.

Le trafic entre deux réseaux internes ne fonctionne pas : Vérifiez la zone source, la zone de destination, les objets réseau, le routage et la position de la règle de pare-feu.

La passerelle WAN ne devient pas active : Vérifiez la configuration IP, l’IP de la passerelle, l’état de la liaison, les informations d’identification PPPoE, le DNS et si nécessaire le gestionnaire de liaison WAN.

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 passerelles peuvent devenir inaccessibles. Si un fournisseur fournit plusieurs adresses IP publiques sur le même sous-réseau, les interfaces alias ou LAG sont généralement plus propres que plusieurs interfaces WAN distinctes sur le même réseau.

SFP, la vitesse du port ou le breakout ne correspondent pas : La vitesse du port sur le commutateur, le routeur, l’émetteur-récepteur et le pare-feu doit correspondre. Un port 25 Gbit/s ne peut pas être connecté directement à un port 40 Gbit/s sans une technologie appropriée. Pour les modèles dotés de ports 40G ou 100G, les câbles épanouis peuvent être utiles si un port doit être divisé en plusieurs ports plus petits.

Problèmes MTU avec VPN ou PPPoE : Vérifiez MTU et MSS. Pour le trafic VPN, une valeur MTU trop élevée peut entraîner une perte de paquets, ce qui dans la vie de tous les jours ressemble à des problèmes de connexion aléatoires. Sophos Firewall Vérifiez MTU et MSS pour les problèmes VPN se prête à une limitation systématique.

Dépannage

Cette commande est pratique pour le dépannage :

1. Network > Interfaces : Vérifiez l’état du lien, l’adresse IP, la zone et la passerelle.
2. Network > Zones : Vérifiez Device Access et le type de zone.
3. Hôtes et services : vérifiez si les objets hôte et service sont corrects.
4. Rules and policies > Firewall rules : Vérifiez la zone source, la zone de destination, les services et la commande.
5. Rules and policies > NAT rules : Si NAT est impliqué, comparez soigneusement l’original et la traduction.
6. Visionneuse de journaux : vérifiez quelle règle ou suppression s’applique.
7. Diagnostics > Tools > Packet capture : Vérifiez si les paquets arrivent et où ils sont transférés.

Si les zones et les interfaces sont correctement disposées, l’étape suivante devient beaucoup plus simple : Comprendre et configurer correctement les règles Sophos Firewall. Si la circulation ne fonctionne pas malgré la zone apparemment correcte, la liste de contrôle La règle de pare-feu ne fonctionne pas : vérifiez la commande, la correspondance et les journaux vous aidera. Pour une analyse plus approfondie, vous pouvez également utiliser Utilisez Packet Capture dans WebAdmin et pour les traductions ou la redirection de port l’article Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT.

Liste de contrôle opérationnel

• Modèle de zone documenté : Client, serveur, gestion, invité, DMZ, WAN et VPN délibérément séparés ou délibérément combinés.
• Nouveaux VLAN documentés avec l’ID de VLAN, l’interface parent, le profil de port de commutateur et l’IP de la passerelle.
• Zone et objet hôte IP concret documentés pour chaque réseau important.
• Device Access vérifié par zone, notamment pour HTTPS, SSH, DNS, Ping, User Portal et VPN Portal.
• Règles de pare-feu créées avec la zone source, la zone de destination, les services et la journalisation.
• Alias vérifié à la place d’une interface WAN supplémentaire lorsque plusieurs IP publiques sont utilisées dans le même sous-réseau fournisseur.
• Règles NAT vérifiées si l’accès Internet, DNAT, SNAT ou VPN est impliqué.
• DHCP, DNS et NTP testés pour les nouveaux réseaux.
• Object usage vérifiée avant les modifications des interfaces existantes.
• État du lien, Log Viewer et Packet Capture ont vérifié les modifications.
• Accès à la gestion assuré via un chemin indépendant.
• Sauvegarde disponible avant les changements majeurs.

FAQ