Choisir le bon mode de fonctionnement Sophos RED

Le mode de fonctionnement d’une Sophos SD-RED n’est pas une option secondaire. Il détermine qui fournit DHCP et la passerelle sur le site distant, quel trafic emprunte le tunnel RED, si les accès internet sont inspectés de manière centralisée et ce qui continue à fonctionner en cas de panne du tunnel. Un tunnel Site-to-Site RED entre deux Sophos Firewall est une autre architecture et n’utilise pas ces quatre modes de fonctionnement.

Pour une nouvelle agence gérée centralement, Standard/Unified constitue généralement le point de départ le plus clair. Standard/Split économise la bande passante du tunnel, mais soustrait le trafic internet local au contrôle central. Transparent/Split intègre la RED dans un réseau existant. Manual/Split est une architecture particulière de câblage et de routage destinée à préserver l’autonomie internet locale, et non un simple mode rapide.

Le mode de fonctionnement doit être décidé avant de configurer DHCP, les VLAN, les règles de pare-feu et le déploiement. Le modifier ultérieurement change le chemin des données et nécessite une fenêtre de maintenance avec des tests fonctionnels contrôlés.

Ce guide concerne SFOS 22.0 et les modèles SD-RED 20 et SD-RED 60 pris en charge par cette version. Les RED 15/15w et RED 50 ne se connectent plus à partir de SFOS 20.0 MR1. Les anciennes interfaces Firewall RED entre UTM et SFOS doivent être remplacées et supprimées avant le passage à SFOS 22.0, faute de quoi la mise à niveau, la restauration et l’importation sont bloquées. Depuis SFOS 21.0 MR2 et 21.5 MR1, les hôtes système RED reçoivent automatiquement un masque /32. Sous Hosts and services > IP host, ouvrir Usage pour chaque hôte système RED et, lorsque l’ancien sous-réseau d’interface était visé, le remplacer dans les règles et routes dépendantes par l’hôte IP ou réseau approprié. Ces contrôles de migration doivent donc être intégrés au plan de changement avant toute migration matérielle ou de pare-feu.

Les explications sur les modes de fonctionnement, les modes des ports LAN et les chemins de données WLAN s’appliquent à SFOS 22.0 et 23.0. Les consignes de migration du paragraphe précédent restent liées aux versions qui y sont explicitement mentionnées. Avant tout changement de mode en production, le comportement doit être vérifié dans des conditions contrôlées sur le modèle et la version utilisés.

Les quatre modes RED en un coup d’œil

Ce résumé aide au premier choix, mais ne remplace pas l’examen du comportement en cas de panne, des VLAN et de la sécurité. En particulier, Split ne signifie pas automatiquement fail-open et Transparent ne signifie pas automatiquement que les tags VLAN sont transmis.

Standard/Unified : Tout passe par le site central

En Standard/Unified, Sophos Firewall fournit DHCP et la passerelle par défaut via l’interface RED. La SD-RED transmet l’ensemble du trafic dans le tunnel chiffré, y compris le trafic internet de l’agence.

Ce mode offre le plus haut niveau de contrôle central. Les règles de pare-feu, les stratégies web, IPS, Application Control, les rapports et la sortie internet centrale peuvent être appliqués de manière cohérente au siège. En contrepartie, le tunnel et la connexion WAN centrale sont davantage sollicités, car le trafic internet ordinaire de l’agence parcourt lui aussi deux fois la liaison entre les sites.

Si le tunnel RED tombe en panne, les clients ne perdent pas uniquement l’accès aux réseaux internes. Leur passerelle se trouvant sur Sophos Firewall de l’autre côté du tunnel, l’accès à internet est normalement interrompu lui aussi. Standard/Unified convient donc lorsque la sécurité centrale prime sur le maintien d’un accès internet local pendant une panne du tunnel.

Quand Standard/Unified convient

• Tout le trafic du site doit être inspecté et journalisé centralement.
• DHCP, le transfert DNS, les règles et l’accès à internet doivent converger vers Sophos Firewall.
• La capacité WAN centrale suffit au trafic internet supplémentaire de l’agence.
• Une panne du tunnel peut mettre volontairement le site hors ligne, ou un second lien RED testé existe.
• Des VLAN doivent être transportés via une SD-RED 60.

Standard/Split : Les réseaux centraux dans le tunnel

Avec Standard/Split, Sophos Firewall reste le serveur DHCP et la passerelle par défaut du réseau fourni par la RED. Seuls les réseaux de destination renseignés dans Split networks passent dans le tunnel. Les autres destinations, généralement internet, quittent le site par la connexion WAN locale de la RED.

Cela soulage le tunnel et la connexion internet centrale. La contrepartie est une limite de sécurité claire : Sophos masque le trafic internet local au niveau de la RED, mais le pare-feu central ne peut pas l’inspecter avec ses règles de pare-feu, web ou IPS. Du point de vue du siège, ce chemin n’est pas un trafic internet transféré normalement.

Split networks accepte des réseaux IP. Les objets hôtes FQDN ne sont pas pris en charge à cet endroit. Les trames déjà taguées avec un VLAN ne correspondent pas non plus au chemin de données de Standard/Split. Seul le réseau DHCP directement fourni par la RED obtient un accès internet local dans ce mode.

Exemple pour Split network : La filiale utilise 10.20.30.0/24, et le réseau de serveurs requis au siège utilise 10.10.40.0/24. Seul le réseau de destination central est saisi comme réseau fractionné ; il ne s’agit ni de la plage DHCP de la filiale ni d’un hôte FQDN. Ces réseaux privés sont des exemples et doivent être remplacés par vos propres réseaux sans chevauchement. Un serveur de ce réseau, une destination locale hors de la liste et une destination Internet sont ensuite testés séparément. Les ressources internes non répertoriées ne deviennent pas automatiquement accessibles via le siège : elles suivent le chemin local restant.

Standard/Split n’est pas non plus une architecture fail-open générale. En cas de panne du tunnel, la documentation Sophos indique que les clients du réseau fourni par le pare-feu perdent à la fois l’accès aux destinations centrales et à internet. Une exploitation internet locale indépendante du tunnel exige une autre architecture, planifiée et testée.

Quand Standard/Split convient

• L’agence n’a besoin que de quelques réseaux clairement définis au siège.
• La sortie internet locale est intentionnelle et peut rester hors des stratégies Sophos centrales.
• Sophos Firewall peut administrer le réseau distant par DHCP.
• Le transport de trames taguées VLAN dans le tunnel RED n’est pas requis.
• Le chemin de panne a été testé et n’est pas confondu avec Manual/Split.

Transparent/Split : RED dans le réseau existant

Transparent/Split convient aux sites distants sur lesquels le routeur, DHCP, DNS et la passerelle par défaut existent déjà et doivent rester en place. La RED fonctionne de manière transparente dans le réseau de couche 2 existant. Seuls les réseaux ou domaines split configurés sont acheminés dans le tunnel vers le siège.

Ce mode évite de modifier la passerelle des clients. Le dépannage est toutefois plus exigeant : DHCP, DNS et le chemin internet normal restent dans le réseau local, tandis que certaines destinations sont redirigées par la RED. Les tests doivent donc montrer séparément quel chemin reste local et lequel entre réellement dans le tunnel.

Pour les noms internes, Transparent/Split nécessite également un Split DNS server, c’est-à-dire un serveur DNS dans le réseau central que les clients distants peuvent interroger pour le domaine interne concerné. Un domaine fractionné n’est pas la même chose qu’un hôte FQDN sous Split network. Par exemple, pour corp.example, la résolution via le serveur DNS interne prévu doit fonctionner, et son réseau doit être accessible par le tunnel. corp.example est un nom de substitution pour votre propre domaine interne. Si l’IP du serveur est accessible mais pas le nom, vérifier d’abord la réponse DNS réelle, le résolveur utilisé et le chemin vers ce résolveur ; ne pas élargir la règle de pare-feu de manière générale.

Transparent/Split ne transporte pas les trames taguées VLAN. Un lien de secours 3G/4G n’est pas non plus disponible dans ce mode. Pour un module Wi-Fi, le serveur DHCP distant doit transmettre au point d’accès l’option DHCP 234 contenant l’adresse IP de l’interface RED sur le site du pare-feu ; il ne s’agit ni de l’adresse de l’AP, ni d’une adresse de l’agence, ni de l’adresse publique du pare-feu.

Quand Transparent/Split convient

• Le routeur existant doit continuer à fournir DHCP, DNS et la passerelle par défaut.
• Seuls certains réseaux ou domaines centraux doivent être accessibles via la RED.
• La RED peut être intégrée proprement en ligne dans le réseau existant.
• Le site ne nécessite pas de tags VLAN sur ce chemin RED.
• Le trafic local et le trafic du tunnel peuvent être contrôlés séparément avec Packet Capture et des tests vers des destinations réelles.

Manual/Split : Passerelle locale et routes statiques

Pour une SD-RED, Manual/Split décrit avant tout une architecture réseau volontairement construite manuellement. Les côtés WAN et LAN de la RED sont intégrés à l’infrastructure existante du site de façon que le routeur existant reste la passerelle par défaut. Ce routeur reçoit des routes statiques vers la RED pour les réseaux centraux.

L’avantage est l’autonomie locale : l’accès internet normal peut continuer même si le tunnel RED ou la RED elle-même tombe en panne. En contrepartie, la planification est plus complexe. Les chemins retour, les routes statiques, le comportement ARP et le câblage physique doivent être exacts. Un next hop erroné peut faire contourner le tunnel au trafic central ou l’envoyer dans une impasse lors d’une panne.

Sophos décrit à cet effet un déploiement physique manuel et une configuration RED fondée sur le schéma Standard/Unified, tandis que la passerelle existante et les routes statiques déterminent la séparation. Cette désignation ne doit donc pas être considérée comme un commutateur indépendant et auto-explicatif.

L’ordre des connexions physiques est important : Le port WAN de la RED est d’abord connecté au même switch LAN que les clients du site. Ce n’est qu’après que la RED a reçu sa configuration Standard/Unified qu’un port LAN de la RED est également connecté à ce switch. La RED n’est pas placée en ligne devant l’ensemble du LAN du site. Avant la seconde connexion, il faut clarifier la responsabilité DHCP existante, l’adresse de la RED en tant que Next Hop et l’affectation des ports du switch ; un serveur DHCP supplémentaire non coordonné ne doit pas prendre en charge la configuration des clients. Il s’agit d’une conception de routage planifiée, et non d’une recommandation de relier WAN et LAN sur n’importe quelle RED.

Exemple de plan de routage : La passerelle existante du site 10.20.30.1 reste la passerelle des clients, et l’adresse LAN prévue de la RED 10.20.30.2 sert de Next Hop pour le réseau central 10.10.40.0/24. Toutes les valeurs sont des exemples adaptables ; le Next Hop et le plan d’adressage doivent correspondre à l’interface RED effectivement provisionnée et ne doivent pas entrer en conflit avec les équipements existants. Le siège a besoin d’un chemin de retour vers 10.20.30.0/24. Avant le déploiement, la résolution ARP vers le Next Hop, une destination centrale et l’accès Internet local sont vérifiés. En cas de défaillance du tunnel ou de la RED, le chemin Internet via 10.20.30.1 doit rester disponible, tandis que la destination centrale devient indisponible comme prévu. En cas de comportement DHCP, ARP ou de routage inattendu, débrancher la dernière connexion LAN de la RED ajoutée et rétablir l’état initial documenté du câblage et des routes.

Manual/Split doit uniquement être utilisé dans une architecture documentée avec :

• une autre passerelle locale
• des routes statiques pour chaque réseau de destination central
• un chemin retour vérifié depuis le siège
• un accès de gestion indépendant
• des tests avec le tunnel actif, le tunnel déconnecté et la RED éteinte

Options de couche 2 et d’extension

Utiliser plusieurs RED dans un réseau bridge commun

Un Bridged RED setup n’est pas un cinquième mode de fonctionnement. Cette architecture regroupe au moins deux interfaces RED existantes dans un bridge sur Sophos Firewall. Les réseaux RED distants se comportent alors comme un LAN commun, tandis que les règles de pare-feu peuvent toujours limiter le trafic entre les sites RED.

Le bridge se crée sous Network > Interfaces > Add interface > Add bridge. Il faut définir un nom clair et l’interface bridge, puis sélectionner les interfaces RED requises comme Member interfaces avec leurs zones. Le plan d’adressage, la responsabilité DHCP et tous les membres du bridge doivent être coordonnés au préalable ; plusieurs serveurs DHCP non coordonnés ou des adresses IP dupliquées agiraient ensuite dans le même réseau de couche 2.

Nous recommandons cette architecture uniquement lorsque plusieurs succursales ont réellement besoin du même domaine de broadcast. Pour des sites normalement séparés, des réseaux RED routés sont plus faciles à isoler, à surveiller et à modifier indépendamment. Après l’enregistrement, vérifier DHCP, ARP, le trafic entre les sites, la règle de pare-feu responsable et un trafic volontairement bloqué. Un tunnel RED vert confirme les tunnels individuels, mais pas le bridge ni ses règles.

Un second lien et un second pare-feu ne sont pas des modes

La configuration RED peut également contenir un second endpoint de pare-feu et, selon le modèle et le mode, un second lien. Ces options complètent le chemin choisi, mais ne le remplacent pas.

Un second endpoint de pare-feu peut servir au failover ou à l’équilibrage de charge. Un second lien peut sécuriser l’établissement du tunnel. Lorsque les deux liens sont configurés sur Static, les adresses IP de leurs serveurs DNS doivent être différentes ; des fournisseurs DNS différents ne sont pas nécessaires. La RED vérifie l’entrée de routage du premier lien pour la résolution DNS. Si cette passerelle ne répond pas, elle considère l’IP du serveur DNS comme inaccessible et ne réessaie pas cette même adresse IP via le second lien.

Pour le second point de terminaison de pare-feu, 2nd firewall IP/hostname et Use 2nd IP/hostname for sont définis ; 2nd uplink connection et 2nd uplink mode gèrent une seconde connexion WAN. Failover utilise le second chemin si le premier échoue, tandis que Load balancing répartit le trafic sur les deux. Load balancing ne remplace donc pas un chemin de secours testé. 3G/UMTS failover nécessite un dongle USB adapté et les paramètres de réseau mobile du fournisseur. Le firmware RED 2.0.018 ne prend pas en charge le D-Link DWM-222 ; une connexion mobile de secours prévue doit correspondre au firmware et au matériel réellement utilisés.

Connexion mobile de secours de la RED : associer les paramètres de l’opérateur

Si le modèle RED utilisé, le mode de fonctionnement, le firmware RED et le dongle USB prennent en charge cette connexion de secours, modifier l’interface RED concernée sous Network > Interfaces et vérifier ses paramètres 3G/UMTS failover. En Transparent/Split, ce basculement vers le réseau mobile n’est pas disponible. La correspondance suivante explique les paramètres RED de la documentation API pour SFOS 22.0 et 23.0 ; elle ne constitue ni un exemple XML exécutable ni une garantie de prise en charge actuelle des réseaux mobiles pour SD-RED 20 ou 60. Les anciens noms de modèles et les options de réseau mobile figurant dans l’exemple API ne remplacent pas une vérification de compatibilité pour la combinaison précise.

• UMTS3GFailover : activation de la connexion mobile de secours de la RED ; la documentation indique Enable et Disable, avec Disable comme valeur par défaut. Ne l’activer qu’après la vérification de compatibilité.
• Username et Password : nom d’utilisateur et mot de passe pour l’accès au réseau mobile selon les indications de l’opérateur, et non les identifiants de l’administrateur du pare-feu. Saisir uniquement les identifiants exigés par l’opérateur ; ne pas utiliser de valeurs par défaut inventées.
• Pin : code PIN de la carte SIM utilisée, si un code PIN y est configuré. Ne pas le confondre avec le code de déverrouillage de la RED et, si le code PIN est incertain, ne pas risquer de bloquer la SIM par des tentatives répétées au hasard.
• MobileNetwork : type de réseau mobile. Les valeurs documentées sont GSM et CDMA, avec GSM comme valeur par défaut ; le choix doit correspondre à la combinaison opérateur/dongle effectivement prise en charge. Ces anciennes valeurs de sélection ne prouvent pas la disponibilité actuelle des réseaux.
• APN : Access Point Name de l’opérateur pour cette carte SIM ou ce forfait précis. Il ne s’agit pas de l’adresse publique du pare-feu et il n’est pas déduit du nom du tunnel RED.
• DialString : chaîne de numérotation de l’opérateur pour la combinaison prise en charge. Ne pas reprendre systématiquement la valeur d’exemple ou par défaut documentée : il n’existe ici aucune chaîne de numérotation universelle pour tous les opérateurs et modems.

Ces valeurs concernent la RED sur le site distant : dans l’exemple API documenté, les champs de l’opérateur figurent sous UplinkSettings / FailOverSettings. Cellular WAN sur Sophos Firewall configure en revanche la propre connexion mobile du pare-feu ; les champs d’opérateur portant les mêmes noms à cet endroit ne configurent pas de connexion de secours pour la RED. Cette correspondance est une aide à la saisie, et non une recommandation d’utiliser un payload API ou un sérialiseur non vérifié.

Avant toute modification, sauvegarder les paramètres de la liaison RED fonctionnelle et du basculement existant, et préserver un chemin d’administration indépendant. Conserver le mot de passe de l’opérateur, le code PIN de la SIM et les fichiers de provisionnement uniquement de manière protégée et avec un accès restreint ; ne pas les copier dans des captures d’écran, des tickets ou des exemples de configuration. En l’absence de compatibilité matérielle/firmware confirmée ou d’une valeur fournie par l’opérateur, ne pas activer la connexion de secours sur la base de suppositions, mais clarifier la situation avec l’opérateur ou Sophos Support. Après une modification approuvée, appliquer les vérifications distinctes des liaisons et des chemins décrites ci-dessous ; si la recette échoue, restaurer les paramètres RED précédents.

Les tests doivent rester distincts :

1. Le mode RED choisi doit d’abord fonctionner correctement via le lien principal.
2. Un failover contrôlé du lien est ensuite testé.
3. L’état RED, DHCP, les destinations centrales et le chemin internet sont de nouveau contrôlés.
4. Les environnements HA nécessitent un test de failover du pare-feu distinct ; le tunnel RED a besoin de temps pour se rétablir après le changement de rôle.

Un tunnel vert ne prouve à lui seul ni que le chemin internet est correct ni que les stratégies de sécurité fonctionnent.

VLAN et modes des ports LAN sur SD-RED 60

La SD-RED 60 peut transporter des VLAN dans le tunnel, mais uniquement en Standard/Unified. Chaque port LAN définit en outre la manière dont la RED traite les trames taguées et non taguées.

• Tagged: Seuls les VLAN configurés sont transférés avec leur tag. Les VLAN non configurés et les trames non taguées sont rejetés. Jusqu’à 64 VLAN ID peuvent être renseignés par port.
• Untagged, drop tagged: Les trames non taguées sont affectées au VLAN configuré ; les trames déjà taguées sont rejetées. Cela correspond à un port d’accès contrôlé.
• Disabled: Le port LAN rejette le trafic.
• Untagged: Les trames non taguées reçoivent l’ID du VLAN configuré, tandis que les trames déjà taguées sont transférées sans modification. Une seule configuration VLAN est possible par port. Il s’agit d’un port hybride et non d’un trunk librement configurable ; les VLAN autorisés doivent toujours être contrôlés sur le switch connecté et sur le pare-feu.

Les affectations ci-dessus décrivent principalement les trames arrivant sur le port LAN de la RED. Pour le sens inverse, le mode LAN Untagged décrit la sortie de l’ID VLAN configuré sans étiquette, afin de permettre la connexion d’un terminal sans prise en charge des VLAN. Un ID est prévu à cet effet sous LAN VID(s) ; avec Tagged, plusieurs ID sont saisis séparés par des virgules, par exemple 10,20. Les nombres sont des exemples pour vos propres VLAN et doivent correspondre au switch et au pare-feu.

Les descriptions des modes LAN ne sont pas univoques dans chaque sens : Le tableau du trafic décrit le rejet des trames entrantes étiquetées sur le port d’accès, tandis que le texte de Untagged, drop tagged décrit de façon contradictoire la sortie des trames VLAN correspondantes. Aucun comportement de sortie ou d’isolation garanti n’en est déduit ici. Avant toute utilisation en production, les VLAN autorisés et non autorisés ainsi que les trames non étiquetées sont testés dans les deux sens sur le modèle et la version effectivement utilisés. Au préalable, sauvegarder le mode du port, LAN VID(s) et la configuration du switch, et prévoir un chemin d’administration indépendant. En cas de transfert inattendu, retirer le port de test du réseau de production, restaurer les paramètres précédents du port et des VLAN, puis vérifier à nouveau ; ne pas improviser en autorisant les VLAN de manière générale.

Si un VLAN invité situé derrière la RED doit accéder localement à Internet, Standard/Split ne remplace pas cette conception VLAN. Une architecture possible consiste à ajouter sur le site un Sophos Firewall sur une XGS Appliance de classe desktop, qui route ce trafic via la passerelle locale et le protège à cet endroit. Il s’agit d’un chemin de routage et de sécurité distinct, qui doit être planifié avec des règles séparées, des chemins de retour et un test négatif d’accès du réseau invité au réseau interne ; le mode de fonctionnement de la RED ne fournit pas à lui seul cette séparation.

Sophos Firewall a besoin d’une interface VLAN correspondante sur l’interface RED pour chaque VLAN utilisé. VLAN ID, réseau IP, DHCP, mode du port RED et configuration du switch doivent correspondre exactement. La procédure complète est décrite dans Configurer et tester un VLAN sur Sophos Firewall.

Planifier séparément le comportement Wi-Fi

Avant de configurer un module Wi-Fi, une interface RED avec une adresse IP doit exister, et la résolution DNS doit fonctionner sur cette interface précise. Un module Wi-Fi optionnel de la SD-RED 20 ou 60 peut emprunter trois chemins de données différents :

• Separate zone: Le trafic Wi-Fi rejoint le pare-feu de manière chiffrée via VXLAN indépendamment du mode RED. Sophos Firewall doit explicitement autoriser le trafic de zone séparée pour l’interface RED ; cela n’implique pas une autorisation générale vers le WAN.
• Bridge to AP LAN: Le réseau Wi-Fi est ponté avec le LAN local du point d’accès.
• Bridge to VLAN: Le réseau Wi-Fi est affecté à un VLAN ; le comportement exact dépend du mode RED et de la configuration VLAN.

En Standard/Unified et Standard/Split, un serveur DHCP correctement configuré doit fonctionner sur l’interface RED. Dans le scénario Wi-Fi documenté de Transparent/Split, le réseau distant fournit DHCP et DNS, et l’interface RED doit obtenir son adresse IP auprès du serveur DHCP distant. Ce serveur doit fournir l’option 234 contenant l’adresse IP de l’interface RED sur le site du pare-feu. Sans cette option, 1.2.3.4 est la valeur de repli documentée : c’est un indice de diagnostic d’une option manquante, pas une adresse à configurer en production. Les paramètres Wi-Fi, le mode du port LAN et le mode RED doivent donc être validés comme une seule architecture et non comme trois listes déroulantes indépendantes.

Bridge to VLAN ne transforme pas un mode split en transport VLAN général. En Standard/Split, les clients Wi-Fi atteignent les hôtes locaux portant le même tag et, si elle existe sur l’interface RED, l’interface VLAN à l’extrémité du tunnel. Ils n’atteignent pas les réseaux split configurés, car la RED ne les route que pour les paquets non tagués. En Transparent/Split, le même VLAN s’étend localement aux ports LAN 1–4 et au port WAN ; les réseaux split restent inaccessibles par ce chemin Wi-Fi.

Avec Bridge to AP LAN, le pont local comprend les ports LAN 1–4. Les clients WLAN ne peuvent atteindre l’interface du point de terminaison du tunnel RED sur le pare-feu que si le trafic du réseau RED vers cette interface est autorisé. Avec Bridge to VLAN en Standard/Unified, les clients WLAN reçoivent l’ID VLAN configuré et peuvent atteindre les équipements du même ID VLAN sur les ports LAN, selon les autorisations correspondantes, ainsi que l’interface VLAN adaptée sur le point de terminaison du tunnel du pare-feu. Une connexion WLAN réussie ne confirme pas encore ces destinations ; elles sont vérifiées individuellement avec un client de test WLAN.

Configurer et tester le mode en toute sécurité

Prérequis et champs exacts

Activer d’abord le service sous System services > RED, puis créer ou modifier l’appliance sous Network > Interfaces > Add interface > Add RED. Les champs déterminants sont RED ID, Unlock code, Firewall IP/hostname, Device deployment, Uplink connection, RED operation mode, RED IP, Zone, Configure DHCP, RED DHCP range et, pour les modes split, Split network.

RED ID figure sur l’appareil et son emballage ; Tunnel ID doit être libre sur les deux appareils concernés. Firewall IP/hostname désigne l’adresse publique accessible ou le nom public du point de terminaison du tunnel, et non une adresse d’administration interne quelconque. Lors de l’enregistrement initial, Unlock code reste vide. Pour une RED déjà utilisée ou pour un passage à un autre pare-feu, le code existant doit être sauvegardé et utilisé. L’adresse de contact sous System services > RED doit être correcte : lors de la suppression d’une interface, le code est affiché et envoyé à cette adresse. Si le code manque, faire appel à Sophos Support et ne pas supprimer précipitamment l’interface fonctionnelle.

En déploiement automatique, la RED doit démarrer au moins une fois dans un réseau disposant de DHCP et d’un accès internet afin de télécharger sa configuration. Un uplink statique impose un déploiement manuel par clé USB. Le chemin doit autoriser TCP 3400, UDP 3410 et NTP 123 : la configuration et le canal de contrôle passent par TCP 3400, puis le tunnel de données Layer 2 par UDP 3410. Sans adresse WAN fournie par DHCP lors du déploiement automatique, l’équipement redémarre en boucle.

Lors du provisionnement automatique, le service de provisionnement enregistre l’adresse du pare-feu, les paramètres WAN et de réseau mobile, le mode de fonctionnement et l’Unlock Code. La RED résout red.astaro.com et télécharge sa configuration depuis le service de provisionnement. Une RED fonctionnelle n’interroge pas ce service en permanence ; si sa configuration ne fonctionne pas, elle y recherche des instructions mises à jour. L’accessibilité du service de provisionnement et celle du point de terminaison du tunnel du pare-feu proprement dit font donc l’objet de vérifications distinctes. Pour le provisionnement USB, sous Network > Interfaces, ouvrir le Menu de la bonne interface RED, sélectionner Download provisioning file et copier le fichier actuel dans le répertoire racine de la clé USB. La vérification détaillée du démarrage et des délais figure dans la procédure de configuration liée.

Nous recommandons une zone dédiée de type LAN ou DMZ plutôt que la zone LAN générale. Si la modification de RED IP place l’interface RED dans un sous-réseau qui ne contient plus la plage RED DHCP range existante, SFOS désactive le serveur DHCP RED. Cette dépendance doit figurer dans le plan de changement.

Après une modification de RED IP, adapter le serveur DHCP existant sous Network > DHCP ou créer un nouveau serveur pour le nouveau réseau. Vérifier non seulement la plage dynamique, mais aussi Dynamic IP lease, Static IP MAC mapping, la passerelle, DNS et les autres options. Un test client avec un bail renouvelé doit afficher les nouvelles valeurs effectives avant la remise en service de la filiale.

Adapter routage, règles de pare-feu et NAT au mode

Créer les règles sous Rules and policies > Firewall rules entre la zone RED et les seules zones de destination nécessaires. Any pour les réseaux et services ne convient qu’à un test fonctionnel limité dans le temps ; en production, limiter sources, destinations et services aux besoins réels. En Standard/Unified, une règle RED vers LAN ne remplace pas une règle RED vers WAN ; le chemin internet central nécessite également une règle SNAT adaptée.

En Standard/Split, la RED masque elle-même le trafic internet local avec son adresse publique. Ce chemin n’apparaît pas sur le pare-feu central et n’y requiert donc pas de règle WAN SNAT. Le trafic central dans le tunnel nécessite en revanche des routes aller-retour correctes et des règles correspondantes ; les règles NAT existantes ne doivent pas modifier involontairement ses réseaux source ou destination. En Manual/Split, tester ensemble les routes statiques de la passerelle de l’agence et le chemin retour au siège.

Ne pas utiliser les options supplémentaires pour corriger le mode

MAC filtering type distingue Allow list et Block list ; le nombre maximal d’adresses MAC dépend du modèle de l’appareil. Les filtres MAC ne remplacent pas les règles de pare-feu et ne corrigent pas un routage incorrect. Sous PoE settings, un ou les deux ports PoE peuvent être activés sur SD-RED 60 ; PoE concerne l’alimentation électrique, pas le mode du tunnel.

Remote IP assignment, sous Advanced settings, attribue une adresse via DHCP ou Static au pont avec le tunnel RED côté WAN. Cette option est uniquement prévue lorsque les équipements derrière la RED ne répondent pas aux requêtes ARP. Avant toute modification, documenter les observations ARP et la valeur précédente, puis répéter exactement le même test de destination et restaurer la valeur précédente en l’absence d’amélioration.

Tunnel compression et MTU ne modifient pas non plus la sélection des réseaux fractionnés. La compression peut aider avec des données adaptées et des connexions lentes ; MTU désigne la taille maximale des paquets en octets. Ne pas adopter une valeur générale sans observations justificatives. Les tests contrôlés avant et après, les chemins de retour et la recommandation de désactiver 802.3az sur les switches directement connectés figurent dans Configurer et dépanner Sophos SD-RED.

Changer de mode avec un retour arrière préservant l’état

Avant l’opération, consigner la configuration RED complète, RED IP, la zone, la plage et les options DHCP, les réseaux split, les routes statiques, les règles de pare-feu et NAT, les interfaces VLAN, les modes des ports LAN et un accès d’administration indépendant. Sauvegarder aussi la dernière configuration fonctionnelle du routeur et des ports de switch concernés. Modifier une seule couche à la fois : mode et réseau RED, puis DHCP, routage et règles, enfin VLAN ou Wi-Fi.

Si la recette échoue, ne pas multiplier les changements. Rétablir RED operation mode, RED IP, la zone, DHCP et les réseaux split, puis les anciennes routes et règles, et renouveler le bail d’un client de test. Le retour arrière n’est terminé que lorsque passerelle, DNS, destination centrale, chemin internet et Rule ID correspondent de nouveau à l’état initial. Manual/Split exige aussi de rétablir le câblage d’origine.

La procédure pratique incluant provisioning, LED, règles, performances et dépannage est décrite dans Configurer et dépanner Sophos SD-RED. Le mode nécessite en plus la validation du chemin réel :

1. Un client reçoit l’adresse IP attendue, les serveurs DNS et la bonne passerelle.
2. Un réseau de destination défini au siège est accessible.
3. Log Viewer ou Packet Capture affiche la Firewall Rule ID attendue et le chemin RED.
4. Un test internet montre la sortie publique attendue, centrale ou locale.
5. Une application autorisée et une application bloquée confirment où la stratégie de sécurité s’applique réellement.
6. Les VLAN et les réseaux Wi-Fi sont testés individuellement et pas uniquement par un ping général.
7. Une panne planifiée du tunnel ou du lien confirme le comportement documenté.

Si le tunnel est vert mais que le chemin reste incertain, Utiliser correctement Packet Capture sur Sophos Firewall peut aider. Sur les sites de production, il ne faut pas modifier simultanément le mode, DHCP, les VLAN et les règles de pare-feu. Sinon, il devient presque impossible d’attribuer une panne à une couche précise.

Dépanner selon le chemin des données

• La RED redémarre en boucle ou n’établit pas le tunnel : vérifier d’abord DHCP sur le WAN, DNS et l’accès internet du site, puis TCP 3400, UDP 3410 et la synchronisation NTP 123. En déploiement manuel hors ligne, une heure incorrecte peut empêcher le handshake TLS.
• Le tunnel est vert, mais aucun trafic ne passe : rechercher la Firewall Rule ID attendue dans Log Viewer, puis contrôler routes et règles NAT pour le couple source/destination précis. Dans Advanced Shell, la capture en lecture seule documentée par Sophos tcpdump -ni any port 3410 montre si le trafic RED atteint le pare-feu. Elle ne prouve ni l’autorisation par une règle ni le bon chemin des données ; poursuivre avec Packet Capture filtré sur le client et la destination.
• Seules les destinations split échouent : vérifier que le réseau de destination complet figure dans Split network. Les hôtes FQDN n’y sont pas pris en charge. En Transparent/Split, tester séparément DNS local ou split DNS.
• Seul le trafic VLAN échoue : contrôler d’abord le mode. La SD-RED 60 ne transporte les VLAN dans le tunnel qu’en Standard/Unified. Comparer ensuite VLAN ID, interface VLAN sur l’interface RED, mode du port LAN, tagging du switch, DHCP et règle spécifique au VLAN.
• Un failover HA vient d’avoir lieu : SFOS documente un délai de reconnexion variable selon le nombre d’interfaces et d’autres paramètres. Attendre le rétablissement du tunnel, puis reprendre tous les tests de chemin sans modifier simultanément les paramètres RED.

Idées reçues fréquentes

Split ne garantit pas internet pendant une panne du tunnel

Standard/Split utilise une sortie internet locale, mais les clients dépendent toujours du réseau RED fourni par le pare-feu. Sophos documente là aussi la perte de l’accès à internet en cas de panne du tunnel. Manual/Split est l’architecture distincte prévue pour une passerelle locale existante.

Transparent ne signifie pas un passthrough de couche 2 arbitraire

Transparent/Split intègre la RED à un réseau existant, mais ne transporte pas les trames taguées VLAN par ce chemin. DHCP, DNS et les options Wi-Fi doivent toujours être planifiés consciemment.

Un tunnel vert ne prouve pas que le mode est correct

L’état du tunnel confirme la connexion au pare-feu. Seuls les tests DHCP, routage, internet, règles et panne montrent si le mode sélectionné correspond à l’architecture prévue.