Configurer et dépanner Sophos SD-RED

Avec un Sophos SD-RED, vous pouvez connecter des sites distants, des succursales ou de petits bureaux à domicile à un Sophos Firewall. Le RED établit un tunnel chiffré vers le pare-feu et fournit un réseau sur le site distant, géré de manière centralisée par le pare-feu.

L’avantage pratique : sur place, il n’est généralement pas nécessaire de configurer un VPN complexe. Le SD-RED se connecte à Internet, télécharge sa configuration via le service d’approvisionnement Sophos RED, puis établit le tunnel vers le Sophos Firewall. Cependant, le tunnel seul ne résout pas tout. Les zones, les règles de pare-feu, le DHCP, les VLAN, le routage, le DNS et le niveau de firmware doivent également être corrects.

Le mode de fonctionnement doit être choisi avant la configuration proprement dite. Il détermine DHCP, la passerelle, le chemin internet, le contrôle central et le comportement en cas de panne du tunnel. Choisir le bon mode de fonctionnement Sophos RED explique les différences et les critères de décision.

Planification et prérequis

Classification : SD-RED et RED entre firewalls

RED comporte deux cas d’usage actuels qui doivent rester distincts. Cet article traite d’un SD-RED 20 ou SD-RED 60 physique dans une filiale. SFOS 22 continue également à prendre en charge un tunnel Site-to-Site RED entre deux Sophos Firewall, l’un agissant comme Firewall RED server et l’autre comme Firewall RED client.

Le second cas ne nécessite aucun matériel RED. Configurer Site-to-Site RED entre deux Sophos Firewall explique le fichier de provisionnement, les routes statiques sans interface sélectionnée, les règles sur les deux côtés et le service RED. Les modes de fonctionnement SD-RED ne s’appliquent pas à cette architecture.

Prérequis au site principal

Avant de connecter le RED, les points suivants doivent être clairs sur le Sophos Firewall :

• Le service RED est activé sur le pare-feu.
• L’adresse IP publique ou le nom DNS/DynDNS du pare-feu est accessible.
• Les connexions RED au pare-feu sont autorisées sur le côté WAN.
• RED est autorisé sous Administration > Device access pour la zone WAN appropriée ou spécifiquement autorisé via Local Service ACL.
• L’interface RED, la zone et la configuration IP sont planifiées.
• Les règles de pare-feu du réseau RED vers les réseaux cibles sont prévues.
• Le DHCP, le relais DHCP ou l’adressage statique pour les clients derrière le RED est clarifié.
• Le RED Firmware Pattern sur le pare-feu est à jour.
• La sauvegarde et le niveau de firmware du pare-feu sont documentés avant les modifications majeures.

Pour la communication RED, les ports TCP 3400, UDP 3410 et NTP 123 sont particulièrement pertinents. Ces connexions ne doivent pas être bloquées en cours de route par des routeurs de fournisseurs, des pare-feu en amont ou des passerelles de sécurité.

Prérequis au site distant

Sur le site distant, le SD-RED a besoin d’une connexion Internet propre. Ce qui est crucial, ce n’est pas seulement la bande passante, mais surtout la stabilité, la latence, la perte de paquets et si le fournisseur autorise les connexions nécessaires.

Il faut vérifier :

• La connexion Internet est stable.
• Le port WAN du RED reçoit une adresse par DHCP ou a une configuration statique correcte.
• La passerelle par défaut est accessible.
• Le DNS fonctionne.
• Le NTP est accessible.
• Les ports TCP 3400, UDP 3410 et NTP 123 ne sont pas bloqués.
• Le routeur du fournisseur ou le pare-feu en amont ne fait pas de filtrage inattendu.
• Pour les VLAN, il est clair quel port fonctionne en mode tagué, non tagué ou hybride.

Pour les sites simples, une petite connexion suffit souvent. En pratique, cependant, la perte de paquets, les routeurs grand public instables, le CGNAT, les problèmes DNS ou les pare-feu restrictifs des fournisseurs sont plus souvent la cause que la simple bande passante.

Provisioning et mise en service

Provisionner automatiquement via le Sophos Provisioning Service

Pour le provisionnement en ligne normal, le pare-feu et le SD-RED doivent avoir accès à internet. Lors de son premier démarrage, le SD-RED doit obtenir une adresse WAN par DHCP afin de télécharger sa configuration. Une configuration WAN statique impose donc un provisionnement manuel par USB. Sur le pare-feu, le service de provisionnement RED est activé sous System services > RED, les coordonnées sont renseignées et les conditions d’utilisation de Sophos sont acceptées.

Une interface est ensuite créée sous Network > Interfaces > Add interface > Add RED. Les champs Branch name, type d’appareil, Automatically via provisioning service, adresse du pare-feu, uplink, mode de fonctionnement, réseau RED, zone et DHCP sont définis pour le site. Pour un RED utilisé pour la première fois, Unlock code reste vide. Après l’enregistrement, le pare-feu charge la configuration sur le service de provisionnement. Le SD-RED la récupère, ouvre le canal de contrôle sur TCP 3400, puis établit le tunnel de couche 2 sur UDP 3410.

Pour la zone RED dédiée, saisissez un nom tel que RED-Branch sous Network > Zones > Add, définissez Type sur LAN ou DMZ et sélectionnez sous Device access uniquement les services réellement nécessaires. Enregistrez avec Save et sélectionnez cette zone sous RED network settings sur l’interface RED. Dans Administration > Device access, en revanche, activez le service RED pour la zone depuis laquelle la RED atteint le pare-feu, normalement WAN ; validez avec Apply. La zone des clients derrière la RED et la zone d’entrée du tunnel RED ne sont pas identiques.

Lors du premier enregistrement, le service de provisionnement génère un code de déverrouillage propre à l’appareil. Il apparaît dans WebAdmin et est envoyé à l’adresse e-mail configurée sous System services > RED. Ce code doit être conservé en lieu sûr, car il est nécessaire pour déplacer le RED vers un autre pare-feu. WebAdmin l’affiche à nouveau lors de la suppression de l’interface. S’il n’est plus disponible, il faut contacter Sophos Support.

Définir consciemment les protections RED globales

Lors de l’activation initiale sous System services > RED, SFOS crée un certificat pour la communication RED à partir de Organization name, City, Country et Email. Organization name et City ne doivent donc contenir ni tréma ni caractère spécial. L’adresse e-mail doit rester accessible, car Sophos y envoie les nouveaux codes de déverrouillage.

Pour les SD-RED 20 et 60 actuels, TLS v1.2 (strict) and later constitue le point de départ recommandé. Cette sélection utilise uniquement les suites TLS 1.2 recommandées par Sophos. TLS v1.2 and later inclut en plus des suites que Sophos ne recommande pas et ne doit pas être choisi sans besoin de compatibilité démontré. Après une modification, tous les tunnels RED de production sont reconnectés et testés de manière contrôlée.

Automatic device deauthorization empêche un RED déconnecté depuis longtemps de rester autorisé indéfiniment. Le délai doit correspondre au processus de gestion des incidents et de remplacement : à son expiration, l’appareil n’est pas supprimé, mais l’interface RED doit être explicitement réactivée sous Network > Interfaces. La supervision et la documentation du code de déverrouillage font donc partie de cette protection.

Pour les SD-RED 20 et 60, RED unified firmware reste activé. Un nouveau RED Firmware Pattern est installé volontairement sous Backup & firmware > Pattern updates et n’est pas appliqué automatiquement. Il faut prévoir une fenêtre de maintenance, puis tester le tunnel et un client.

Pour configurer cette fonction, activez Automatic device deauthorization, indiquez le délai et sélectionnez Apply. Réactivez une RED désautorisée à l’expiration du délai sous Network > Interfaces, via le Menu à droite de l’appareil concerné. La fonction de protection concerne également un Firewall RED Client. RED unified firmware est sélectionné par défaut ; toutefois, lors d’une migration du pare-feu, le paramètre existant est conservé. Après une réinitialisation aux paramètres d’usine, l’option est de nouveau sélectionnée. Vérifiez donc la valeur réelle après une migration ou une réinitialisation, sans simplement supposer que la valeur par défaut s’applique.

Connecter le SD-RED

Procédure typique :

1. Connecter le port WAN du SD-RED au routeur ou modem du fournisseur.
2. Connecter le port LAN à un client de test, un commutateur ou un réseau local.
3. Alimenter le SD-RED.
4. Attendre que le RED démarre, vérifie la passerelle et Internet, charge la configuration et établisse le tunnel.
5. Vérifier sur le Sophos Firewall si l’interface RED est active.
6. Connecter un client de test derrière le RED et vérifier l’IP, le DNS, la passerelle et l’accès cible.

Si toutes les LED pertinentes sont vertes, le tunnel technique est établi. Ensuite, commence la vérification réelle du réseau : zone, DHCP, règles de pare-feu, retour de routage, DNS et, si nécessaire, VLAN.

Provisioning manuel avec clé USB

Normalement, un SD-RED est provisionné via le Sophos RED Provisioning Service. Le provisioning manuel par clé USB est utile lorsque l’appareil se trouve dans un réseau privé ou très restreint, nécessite une configuration WAN statique ou lorsque le chemin de provisioning automatique n’est pas fiable.

La source horaire du pare-feu et la fourniture de l’heure à la RED ne sont pas la même chose : Le guide RED manuel pour SFOS 22 et 23 décrit, sous Administration > Time, la sélection de Use custom NTP server, l’adresse IP du pare-feu lui-même dans Search/Add, puis Add et Apply, comme la configuration d’un serveur NTP pour la RED. La documentation du réglage de l’heure décrit toutefois ce champ comme une source horaire en amont pour l’horloge du pare-feu. Les rôles ne concordent donc pas sans ambiguïté ; cette procédure n’est ni un prérequis inconditionnel ni la preuve que le pare-feu fournit NTP à la RED. Sans chemin de synchronisation horaire confirmé et pris en charge pour la version installée, conserver la configuration NTP fonctionnelle sans modification. Planifier d’abord chaque modification confirmée par rapport à l’état initial documenté : un changement de serveurs NTP reconnecte toutes les connexions IPsec. Si des connexions de production sont concernées, prévoir une fenêtre de maintenance et un accès d’administration local ou alternatif.

Le déroulement est plus précis que simplement copier un fichier de provisioning sur USB :

1. Avant le provisioning manuel, clarifier le chemin de synchronisation horaire pris en charge pour la version installée et documenter les paramètres NTP fonctionnels ainsi que l’heure et l’état de synchronisation du pare-feu. Ne pas remplacer la source horaire globale par l’adresse IP du pare-feu lui-même uniquement pour cette configuration RED ; la restriction et la vérification NTP/HTTPS figurent ci-dessous.
2. Sous Network > Zones, créer pour les sites RED une zone dédiée de type LAN ou DMZ. Cette séparation évite que les règles LAN générales ne s’appliquent involontairement au site distant. Si la zone VPN est utilisée à la place, le pare-feu ne répond pas lui-même aux requêtes DNS des clients RED ; le DHCP doit alors fournir un autre serveur DNS accessible.
3. Sous System services > RED, activer le RED Provisioning Service.
4. Sous Network > Interfaces > Add interface > Add RED, créer l’interface RED.
5. Pour Device deployment, sélectionner Manually via USB stick.
6. Saisir RED ID, Unlock Code, uplink, RED network settings, zone, DHCP et VLANs adaptés au site.
7. Sous Network > Interfaces, ouvrez le Menu de l’interface RED et téléchargez le fichier de provisionnement correspondant à cette interface, généré après Save.
8. Copier le fichier dans le répertoire racine de la clé USB.
9. Éteindre le RED, insérer la clé USB et rallumer le RED.
10. Après le démarrage, vérifier interface, LED, IP client, DNS, règle firewall et accès aux cibles.

Après une modification horaire confirmée, actualiser WebAdmin et vérifier l’horloge du pare-feu sous Administration > Time, l’état de synchronisation et les connexions IPsec. Contrôler également le chemin de synchronisation horaire de la RED, le handshake TLS et l’établissement du tunnel. En cas d’échec de la synchronisation horaire ou de régression, rétablir les sources horaires et les paramètres précédents fonctionnels sous Administration > Time et répéter les mêmes vérifications ; ce retour peut également déclencher une nouvelle connexion des tunnels IPsec.

Si le côté WAN du RED utilise DHCP, un serveur DHCP doit réellement répondre sur le site distant. Si le RED ne reçoit pas d’adresse, il peut entrer dans une boucle de redémarrage. Avec une configuration WAN statique, IP, passerelle, DNS et NTP doivent être vérifiés très précisément.

Même une RED provisionnée hors ligne nécessite une heure valide comprise dans la période de validité du certificat pour le handshake TLS. Pour la synchronisation horaire directe, elle doit pouvoir résoudre les noms de 0.sophos.pool.ntp.org à 3.sophos.pool.ntp.org et les joindre via UDP 123. Si cela échoue, elle tente une synchronisation horaire avec le pare-feu via HTTPS sur TCP 4444. Si le service d’administration HTTPS n’est pas autorisé pour WAN sous Administration > Device access, ce mécanisme de repli peut échouer sans exception ciblée. Ne pas activer HTTPS globalement pour la zone WAN à cette fin : l’exception autorise également le service d’administration HTTPS et doit être strictement limitée.

Avant toute modification, documenter les paramètres Device Access et ACL existants et vérifier si une exception appropriée existe déjà. Déterminer avec Diagnostics > Packet capture l’adresse source de la connexion RED réellement observée sur le pare-feu. Derrière un routeur NAT, il s’agit normalement de l’adresse publique de sortie NAT du site distant, et non de l’adresse WAN privée de la RED. Utiliser uniquement un hôte IP clairement identifié et aussi stable que possible ; si l’adresse NAT est partagée, l’autorisation s’applique aussi aux autres appareils derrière cette adresse. Ne pas remplacer une source changeante ou inconnue par une autorisation Any.

1. Ouvrir Administration > Device access > Local service ACL exception rule > Add et attribuer un nom unique.
2. Définir Source zone sur WAN. Sous Source network or host, sélectionner l’hôte IP correspondant à l’adresse source réellement observée ; si nécessaire, créer un hôte IP approprié via Add.
3. Définir Destination host sur le port WAN prévu du pare-feu, Services sur HTTPS et Action sur Accept. Enregistrer avec Save.
4. Vérifier la restriction de source enregistrée et l’hôte de destination. Tester ensuite la synchronisation horaire de la RED, le handshake TLS et l’établissement du tunnel, et vérifier qu’aucune autre source WAN n’a été autorisée pour HTTPS.

Si une exception nouvellement créée n’est nécessaire que temporairement, la supprimer après le test ou après le rétablissement du chemin NTP direct. La supprimer également si elle est inefficace ou accorde un accès indésirable ; en cas de modification d’une exception existante, rétablir son état initial documenté. Vérifier ensuite à nouveau la restriction de source, l’accessibilité HTTPS et le tunnel RED. Documenter toute exception nécessaire en permanence, avec l’adresse source NAT, et la contrôler régulièrement.

Statut, mises à jour et migration

Comprendre le statut des LED

Les LED de statut sont souvent le point d’entrée le plus rapide pour le dépannage RED, car elles indiquent à quel point le processus de démarrage est bloqué.

Légende :

• ⚫ éteint
• 🟢 allumé vert
• 🟢 clignote vert
• 🔴 allumé rouge
• 🔴 clignote rouge

Selon l’angle de vue, la photo ou la lumière ambiante, une LED peut sembler jaunâtre ou orange. Pour le diagnostic, ce qui compte surtout, c’est quelle LED est allumée ou clignote et si elle est verte ou rouge.

Processus de démarrage normal

Si les quatre LED sont allumées en vert mais qu’aucun trafic ne fonctionne, le problème ne réside généralement plus dans l’établissement du tunnel. Les règles de pare-feu, le DHCP, les VLAN, le DNS, le NAT ou le routage sont alors plus probables.

Codes d’erreur

Basculement 3G/4G

Avec les modèles SD-RED dotés de basculement 3G/4G ou d’un module correspondant, des motifs supplémentaires peuvent apparaître.

Contrôler les mises à jour du firmware

Si les LED clignotent ensemble, la RED peut être en train d’installer un firmware. Pendant cette phase, ne pas éteindre l’appareil ni le déconnecter d’Internet. Une mise à jour peut prendre quelques minutes. L’interprétation doit correspondre au motif de LED et au modèle précis ; un clignotement simultané ne constitue pas à lui seul un diagnostic de firmware sans ambiguïté, comme le montrent également les motifs de failover.

Sur le Sophos Firewall, il faut également vérifier :

Backup & firmware > Pattern updates

Le RED Firmware Pattern doit y être à jour. Selon Sophos, le téléchargement et l’installation prennent entre cinq et dix minutes. Si un RED est bloqué dans une boucle ou ne démarre plus correctement après une mise à jour du pare-feu, un RED Firmware Pattern obsolète est une étape de vérification judicieuse. Configurer et vérifier les patterns de Sophos Firewall explique l’articulation entre les états, le téléchargement automatique et l’installation volontaire.

Un souhait opérationnel connexe est décrit dans Sophos Firewall Feature Request 2024 : lors des mises à jour de firmware RED et des points d’accès, les notes de version directement visibles manquent souvent dans le backend. Pour les environnements de production, il est donc conseillé de planifier les mises à jour consciemment et de ne pas les installer de manière non coordonnée pendant les périodes critiques d’exploitation.

Vérifier l’interface RED, la zone et les règles

Après l’établissement réussi du tunnel, le RED a besoin d’une configuration de pare-feu propre.

Points de vérification typiques :

• L’interface RED est active sous Network > Interfaces.
• L’interface est dans la bonne zone.
• Le serveur DHCP ou le relais DHCP est correctement configuré.
• Les clients reçoivent une adresse IP, une passerelle et un DNS.
• Les règles de pare-feu n’autorisent que les cibles nécessaires.
• Le retour de routage vers le réseau RED fonctionne.
• Le NAT n’est utilisé que s’il est consciemment planifié.
• La configuration VLAN correspond au mode RED et au port du commutateur.

Pour le premier test fonctionnel, une règle strictement limitée sous Rules and policies > Firewall rules suffit : définir Source zone sur la zone dédiée RED-Branch, indiquer le réseau client RED sous Source networks and devices et n’autoriser comme destination que le réseau de test interne nécessaire. L’accès à internet exige une règle distincte vers la zone WAN avec le traitement NAT prévu. Limiter ensuite les destinations et les services aux besoins de production. Le chemin souhaité est ainsi testé sans ouvrir à la succursale l’ensemble des réseaux internes.

Pour les bases des règles, voir Comprendre et configurer correctement les règles de Sophos Firewall. Si le tunnel est établi mais que le trafic ne passe pas, il faut combiner Log Viewer et Packet Capture.

L’option MAC filtering type peut appliquer au réseau RED une liste d’autorisation ou de blocage dont la limite dépend de l’appareil, mais elle ne remplace pas une règle firewall. Remote IP assignment n’est pas non plus un réglage par défaut : cette option attribue par DHCP ou de manière statique une adresse au bridge portant le tunnel RED côté WAN et n’est examinée que si les appareils derrière le RED ne répondent pas aux requêtes ARP. Aucune de ces options ne doit être activée comme correctif général de performance ou de connectivité.

Pièges de mise à niveau et de migration

Ne pas confondre Site-to-Site RED et SD-RED

Un tunnel RED entre firewalls reste une architecture distincte prise en charge sous SFOS 22. Il n’utilise aucun des quatre modes de fonctionnement SD-RED et n’est pas défini au moyen de DHCP ou des ports LAN d’un SD-RED. Lors d’une mise à niveau, les deux types de RED sont inventoriés, puis chacun est vérifié par le test fonctionnel qui lui correspond.

Pour une planification de mise à niveau plus large, voir Planifier correctement la mise à jour du firmware Sophos Firewall. Le processus complet entre firewalls figure dans Configurer Site-to-Site RED entre deux Sophos Firewall.

Supprimer les Firewall RED hérités et les anciens appareils RED avant SFOS 22

SFOS 22.0 et les versions ultérieures ne prennent plus en charge Firewall RED Server Legacy ni Firewall RED Client Legacy. Tant qu’une telle configuration UTM vers SFOS existe, la mise à niveau, la restauration et l’importation de configuration vers SFOS 22 sont bloquées. Cela ne concerne pas les types actuels Firewall RED server et Firewall RED client. Avant la mise à niveau, toutes les dépendances des interfaces héritées sont remplacées, les interfaces sont supprimées, puis une nouvelle sauvegarde de configuration est créée.

Les RED 15, RED 15w et RED 50 sont également en fin de vie. Leurs tunnels ne se connectent plus depuis SFOS 20.0 MR1. Après une mise à niveau ou une restauration vers SFOS 22, l’ancienne configuration reste visible, mais n’est pas appliquée et peut uniquement être supprimée. Elle ne peut pas être importée. Ces sites doivent être migrés vers SD-RED 20 ou SD-RED 60 avant la mise à niveau et testés avec leur flux de données réel.

Masque /32 corrigé pour les RED system hosts

Sophos a corrigé en /32 le masque de sous-réseau des RED system host objects générés automatiquement dans SFOS 21.0 MR2 et 21.5 MR1. Si ces objets étaient auparavant utilisés dans des règles ou d’autres configurations pour plusieurs adresses d’hôte, les règles peuvent s’appliquer différemment au trafic après la mise à jour.

Vérifiez les dépendances sous Hosts and services > IP host dès avant la mise à niveau : Ouvrez Usage pour chaque hôte système RED et remplacez l’hôte système par l’hôte IP ou Network approprié dans les règles de pare-feu, les routes et les autres configurations répertoriées. Exemple : Pour l’adresse RED 192.168.1.1/24, l’hôte système était auparavant 192.168.1.1/24 ; il est désormais 192.168.1.1/32. Une règle ou une route couvrant l’ensemble du réseau doit donc utiliser un hôte Network explicite ; l’hôte système ne couvre plus que l’IP configurée de l’interface. Après la mise à niveau, testez à nouveau les correspondances des règles et le chemin des données.

Après une mise à niveau, il faut donc vérifier :

• Les hôtes système RED sont-ils utilisés dans les règles de pare-feu ?
• Une règle attend-elle par erreur un réseau au lieu d’un seul hôte ?
• Les objets IP Host ou Network Host doivent-ils être remplacés ?
• Les correspondances de règles dans le Log Viewer sont-elles toujours correctes ?

RED et failover HA

Dans les environnements HA, les sites RED doivent être testés consciemment après un failover. Sophos indique que les tunnels RED ne se reconnectent pas toujours immédiatement au dispositif auxiliary après un failover HA. La durée dépend notamment du nombre d’interfaces et de la configuration.

Pour les sites critiques, il ne faut pas seulement vérifier le statut HA de la firewall, mais aussi :

• statut de l’interface RED après failover
• accès client derrière le RED
• correspondances des règles firewall pertinentes
• DNS et DHCP derrière le RED
• alerting monitoring en cas d’interruption de tunnel prolongée

Vérifier le débit et les performances du RED

Sophos indique un débit de tunnel maximal de 250 Mbit/s pour le SD-RED 20 et de 850 Mbit/s pour le SD-RED 60. Il s’agit de valeurs maximales de la plateforme, et non d’une garantie pour un transfert SMB individuel, un test de débit dans le navigateur ou un seul flux TCP. Les endpoints, le stockage, la fenêtre TCP, la latence réelle entre les sites, la perte de paquets, le chemin du fournisseur, la charge du pare-feu et les profils de sécurité influencent également le résultat.

Un ping de, par exemple, 8 ms vers un serveur public de test de débit ne décrit pas nécessairement la latence entre les deux sites RED. Un test sur chaque connexion Internet ne vérifie pas non plus le chemin chiffré de bout en bout à travers le tunnel RED. Pour répondre à cette question, il faut un serveur de test dans un LAN et un client de test dans le LAN de l’autre site.

Tester le tunnel RED avec iPerf3 dans les deux sens

Avant de tester le tunnel, établir une référence locale avec les mêmes endpoints câblés. Exécuter ensuite iPerf3 à travers le tunnel RED, d’abord avec un flux TCP, puis dans le sens inverse et enfin avec quatre flux parallèles :

iperf3 -c 10.10.10.50 -t 30
iperf3 -c 10.10.10.50 -t 30 -R
iperf3 -c 10.10.10.50 -t 30 -P 4

10.10.10.50 est uniquement une adresse d’exemple et doit être remplacée par l’adresse IP du serveur iPerf3 dans le LAN distant. Le test génère volontairement de la charge et doit être effectué dans une fenêtre appropriée. Tester correctement les performances de Sophos Firewall avec iPerf3 explique l’installation, la règle de pare-feu temporaire, les tests UDP et l’analyse complète des résultats.

Les trois résultats répondent à des questions différentes :

• Si la référence locale est déjà lente, vérifier d’abord les endpoints, les cartes réseau, les pilotes, les câbles, les switches et le stockage.
• Si un flux est nettement plus lent que -P 4, la latence, la fenêtre TCP ou le flux applicatif individuel constitue plus probablement la limite. Cela ne prouve pas encore une limite du RED.
• Si un et quatre flux atteignent la même limite dans les deux sens, examiner les liens physiques, le chemin du fournisseur, la perte de paquets, la configuration RED et la charge du pare-feu.
• Si un seul sens est lent, comparer les débits montants correspondants, les compteurs d’interface, les erreurs, les drops et le chemin de retour.

Un cas pratique typique serait d’environ 400 Mbit/s avec un flux et compris entre 700 Mbit/s et 800 Mbit/s avec -P 4. Cela indique que le chemin peut transporter une capacité agrégée nettement supérieure, même si un seul flux TCP ou SMB ne l’exploite pas entièrement. Cela ne garantit pas que chaque application atteigne le même résultat multiflux.

Pendant chaque exécution, documenter le temps d’aller-retour réel et la perte de paquets entre les sites, les retransmissions iPerf, la Firewall Rule ID, les profils de sécurité, le CPU du pare-feu et les compteurs des ports concernés. Les liens WAN et LAN doivent réellement fonctionner à 1 Gbit/s, en Full Duplex, sans augmentation des compteurs d’erreurs ou de drops. Conserver la vitesse et le duplex en auto-negotiation aux deux extrémités plutôt que de forcer le gigabit d’un seul côté.

Ne pas désactiver largement IPS ou d’autres profils de sécurité. Pour un test A/B, utiliser au maximum une règle temporaire limitée à la source de test, à la destination de test et au service iPerf3 concernés, puis la retirer immédiatement. Si le résultat ne change pas sans IPS, IPS est moins susceptible d’être la cause sur ce chemin de test précis.

Désactiver réellement 802.3az ou EEE

Pour des performances optimales, Sophos recommande de désactiver 802.3az sur les switches connectés à un SD-RED 20 ou SD-RED 60. Il s’agit de l’Energy Efficient Ethernet, ou EEE. EEE place des parties du PHY Ethernet dans l’état Lower Power Idle lorsque l’utilisation du lien est faible, ce qui économise de l’énergie. Ce mécanisme est différent de PoE et de 802.3x Flow Control.

Le réglage ne se trouve ni dans WebAdmin ni dans la CLI de Sophos Firewall, ni dans un écran SD-RED documenté. Il se modifie sur le port du switch directement connecté. Cela s’applique aux liaisons LAN utilisées par le RED et, si un switch ou un routeur administrable intervient, également à la liaison WAN physique. Sur les appareils d’autres fabricants, l’option peut s’appeler EEE, Energy Efficient Ethernet, Green Ethernet, 802.3az ou Power Saving. Il n’existe pas de CLI universelle.

Sur un Sophos Switch, utiliser la page Port settings :

1. Sélectionner le port directement connecté au SD-RED.
2. Ouvrir Edit.
3. Régler EEE status sur Off.
4. Enregistrer avec Apply.
5. Vérifier le statut du lien, la vitesse négociée, le duplex et les compteurs d’erreurs, puis répéter le même test iPerf3.

Sur un Sophos Switch actuel, le statut peut être affiché en lecture seule dans la CLI :

show eee

Pour le port d’exemple 0/1, désactiver EEE comme suit :

configure terminal
interface gigabitethernet 0/1
no eee
exit
exit
save
show eee

Remplacer 0/1 par le port réellement connecté au RED. no eee modifie la configuration du port. Si le switch n’est accessible que par ce chemin RED, il faut une fenêtre de maintenance et un accès d’administration local ou alternatif. Selon le switch et son firmware, la modification peut déclencher une renégociation du lien.

Pour revenir à l’état précédent sur un Sophos Switch, utiliser eee au lieu de no eee dans le même Interface Configuration Mode :

configure terminal
interface gigabitethernet 0/1
eee
exit
exit
save
show eee

La désactivation d’EEE ne désactive ni Ethernet ni le gigabit. En contrepartie, le PHY n’économise plus autant d’énergie pendant les périodes d’inactivité, de sorte que le port consomme un peu plus et peut générer davantage de chaleur. Aucun gain de débit précis n’est garanti. Seul le test reproductible avant et après est déterminant. Sur un switch non administrable sans option EEE, le réglage ne peut pas être modifié de manière fiable ; pour le test, il faut contourner l’appareil ou utiliser temporairement un switch administrable.

Modifier Tunnel compression et MTU uniquement de manière contrôlée

Modifier l’interface RED sous Network > Interfaces. Les réglages comprennent Tunnel compression et MTU. Sophos décrit Tunnel compression comme un moyen de compresser le trafic RED et d’augmenter le débit, en particulier sur les connexions lentes. Les données déjà compressées ou chiffrées ne peuvent presque plus être réduites, tandis que la compression ajoute du traitement. Un seul réglage ne convient donc pas à tous les sites.

Pour un test A/B, documenter d’abord l’état initial et les mesures. Modifier ensuite uniquement Tunnel compression, enregistrer et répéter exactement la même série iPerf3. Restaurer ensuite l’état initial ou documenter consciemment la variante dont l’amélioration a été démontrée. L’enregistrement peut interrompre brièvement le tunnel RED ; une fenêtre de maintenance et un accès alternatif sont donc judicieux.

MTU n’est pas un réglage général de vitesse. Il ne doit être étudié que si les petits paquets fonctionnent alors que les transferts plus importants s’interrompent, si une fragmentation est visible ou si iPerf3 montre de nombreuses retransmissions. Vérifier MTU et MSS sur Sophos Firewall lors de problèmes VPN explique le test DF sûr, les tailles de paquets et le retour à l’état précédent. En l’absence de constat MTU reproductible, conserver la valeur initiale documentée.

Dépannage

Impossible de créer ou de modifier l’interface RED

Si la création ou l’enregistrement d’une interface RED échoue déjà, vérifiez d’abord les autorisations de l’administrateur, les configurations contradictoires, l’ID RED et le Unlock Code. Le pare-feu lui-même doit pouvoir atteindre le Provisioning Server ; un test effectué uniquement sur le réseau WAN de la RED ne suffit pas à le déterminer. L’établissement de la connexion peut être vérifié dans 5. Device Management > 3. Advanced Shell sur le pare-feu :

telnet red.astaro.com 3400

Une connexion établie avec succès confirme uniquement la résolution DNS et TCP 3400 depuis ce pare-feu. Elle ne confirme ni l’enregistrement ni le Unlock Code. En cas d’échec, vérifiez le chemin sortant du pare-feu ; si le test réussit, continuez à examiner les autorisations et la configuration précise. Ne supprimez pas prématurément une interface existante.

Impossible de modifier l’adresse IP RED sous SFOS 22.0 MR2

Sous SFOS 22.0 MR2 Build 546, la modification de l’adresse IP d’une interface RED existante peut afficher le message Failed to update RED interface. Le piège est que WebAdmin peut déjà afficher la nouvelle IP alors que le pare-feu continue d’utiliser l’ancienne adresse en interne. L’IP visible ne suffit donc pas à confirmer que la modification a bien été appliquée.

Le workaround documenté par Sophos modifie également le nom de la succursale et enregistre à nouveau l’interface :

1. Documenter l’IP RED actuelle, le masque réseau, le Branch Name et toute plage DHCP RED existante.
2. Sous Network > Interfaces, ouvrir l’interface RED concernée et saisir l’adresse IP souhaitée.
3. Si Failed to update RED interface apparaît, ouvrir à nouveau l’interface.
4. Modifier effectivement le Branch Name, par exemple de Branch-Zurich à Branch-Zurich-01, puis enregistrer à nouveau avec Save.
5. Dans 5. Device Management > 3. Advanced Shell, utiliser la commande en lecture seule ifconfig pour vérifier si la nouvelle adresse est active sur l’interface RED :

ifconfig

Le nom de l’interface dépend de la configuration et peut être identifié sous Network > Interfaces. Le redémarrage du pare-feu ou d’un service, ainsi que la suppression de l’interface RED, ne font pas partie de ce workaround.

Si la nouvelle IP RED se trouve dans un réseau différent de l’ancienne plage DHCP RED, SFOS désactive le serveur DHCP RED. Il s’agit d’un comportement normal du produit, indépendant du message d’erreur. Sous Network > DHCP, il faut alors adapter le serveur existant au nouveau réseau ou créer un nouveau serveur DHCP. La plage de baux, les associations MAC statiques, la passerelle et le DNS doivent correspondre au nouvel adressage.

Enfin, renouveler le bail DHCP sur un client derrière le RED et vérifier l’adresse IP, la passerelle, le DNS, l’état du tunnel et l’accès prévu. Dans Log Viewer, le trafic doit à nouveau correspondre à la règle de pare-feu attendue. Si l’IP du backend reste inchangée après un nouvel enregistrement, aucun correctif de production publié n’est actuellement documenté pour NC-184971. Il ne faut pas supprimer des règles ou des interfaces dépendantes sur la base d’un soupçon ; il faut sauvegarder la configuration et faire appel au support Sophos.

Le RED ne reçoit pas d’adresse IP

Si le RED reste bloqué à l’étape du routeur ou si le code d’erreur indique DHCP ou passerelle, la cause se trouve généralement au site distant.

Vérifier :

• Le routeur du fournisseur attribue-t-il une adresse IP par DHCP ?
• Le câble réseau est-il correctement branché sur le port WAN ?
• La passerelle par défaut est-elle accessible ?
• Une adresse IP statique a-t-elle été entièrement saisie ?
• L’adresse IP, le masque de sous-réseau, la passerelle et le DNS sont-ils corrects ?
• Un appareil en amont bloque-t-il le trafic ?

Si le DHCP ne fonctionne pas sur le site distant, le RED peut entrer dans une boucle de redémarrage.

Le RED n’atteint pas Internet

Si le routeur ou la passerelle est accessible mais que la LED Internet ne devient pas verte en permanence, le problème se situe généralement derrière le routeur local.

Vérifier :

• La connexion Internet fonctionne-t-elle avec un client normal ?
• Le DNS fonctionne-t-il ?
• Le NTP est-il accessible ?
• Les ports TCP 3400, UDP 3410 ou NTP 123 sont-ils bloqués ?
• Y a-t-il un proxy ou un pare-feu entre le RED et Internet ?
• La connexion du fournisseur est-elle suffisamment stable ?
• Le service de provisionnement est-il accessible en HTTPS sur TCP 443 ?

Pour l’approvisionnement RED, le RED doit atteindre le Sophos Provisioning Service. Sophos documente *.astaro.com via TCP 3400 et UDP 3410 ; les autres destinations du fabricant et les limites de validation figurent dans Vérifier les services et ports sortants de Sophos Firewall.

Un client situé sur le même réseau que le port WAN du RED peut exécuter telnet red.astaro.com 3400 pour vérifier la résolution DNS et l’établissement d’une connexion TCP. Une connexion réussie confirme uniquement l’accessibilité de TCP 3400 ; elle ne valide ni UDP 3410, ni le provisionnement, ni l’authentification, ni le tunnel RED.

Si la connexion TCP réussit, mais que l’enregistrement échoue toujours, Sophos cite également une charge réseau élevée comme cause possible. Après avoir vérifié l’accès à Internet, DNS et HTTPS sortant sur TCP 443, l’enregistrement peut être retenté ultérieurement. La réussite du test TCP ne prouve ni une charge réseau élevée ni un enregistrement réussi ; si les erreurs persistent, continuez à examiner les autres causes.

Le RED n’atteint pas le Sophos Firewall

Si Internet est accessible mais que le tunnel ne s’établit pas, vérifiez le côté pare-feu.

Vérifier :

• Le service RED est-il activé sur le Sophos Firewall ?
• Le RED est-il correctement configuré ?
• L’ID RED et le code de déverrouillage sont-ils corrects ?
• L’IP publique ou le FQDN du pare-feu est-il accessible ?
• Administration > Device access est-il autorisé pour RED dans la zone WAN appropriée ?
• Une Local Service ACL autorise-t-elle l’accès depuis le site distant ?
• Les ports TCP 3400 et UDP 3410 arrivent-ils sur le pare-feu ?
• L’heure du RED est-elle compatible avec le TLS handshake lors d’un provisionnement manuel ?
• Un RED hors ligne peut-il joindre le NTP ou l’exception Local Service ACL prévue ?

Dans l’Advanced Shell, vous pouvez vérifier si le trafic RED arrive :

tcpdump -ni any port 3400 or port 3410

Si rien n’arrive, le problème se situe généralement avant le pare-feu : routeur du fournisseur, NAT, pare-feu en amont, IP publique incorrecte, FQDN ou blocage de port.

Le RED redémarre sans cesse

Une boucle de redémarrage peut avoir plusieurs causes :

• alimentation instable
• adaptateur secteur défectueux
• pas d’adresse IP par DHCP
• configuration IP statique incorrecte
• ports bloqués
• RED Firmware Pattern obsolète
• code de déverrouillage incorrect
• configuration RED endommagée ou incorrecte

Vérifier d’abord l’alimentation, les câbles et le DHCP, puis le RED Firmware Pattern, l’accessibilité des ports et la configuration. N’envisager un Factory Reset que si ces contrôles n’ont révélé aucune cause. Au préalable, sauvegarder le RED ID, l’Unlock Code et la configuration de l’interface. Si ces informations manquent, la réautorisation peut nécessiter l’intervention de Sophos Support.

Le tunnel est vert, mais aucun trafic ne passe

Ce cas est particulièrement fréquent. Le RED est connecté, mais les clients n’atteignent aucun système interne ou Internet.

Causes possibles :

• Règle de pare-feu manquante ou trop basse.
• L’interface RED est dans la mauvaise zone.
• Le DHCP distribue une passerelle ou des serveurs DNS incorrects.
• Le retour de routage vers le réseau RED manque.
• Le NAT traduit le trafic de manière inattendue.
• Le marquage VLAN ne correspond pas.
• Une fonctionnalité de sécurité bloque le trafic.

Ordre de vérification :

1. Vérifiez l’IP, la passerelle et le DNS du client.
2. Filtrez le Log Viewer sur l’IP source du client RED.
3. Vérifiez la correspondance de la règle de pare-feu.
4. Effectuez une capture de paquets sur l’interface RED et l’interface cible.
5. Vérifiez le chemin de retour depuis le système ou le réseau cible.
6. Contrôlez le NAT et le routage.

En cas de correspondances de règles peu claires, voir Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.

Si la panne survient directement après une réinitialisation suivie d’un nouveau provisionnement, NC-181808 est également pertinent. Selon les notes de version, SFOS 22.0 MR3 Build 576 du 16 octobre 2026 corrige un blocage du trafic provoqué par des entrées RED_DEVICE_DROP résiduelles. Cela n’explique pas tous les cas de tunnel vert sans trafic utile. Conserver l’heure de réinitialisation et de provisionnement, le build SFOS ainsi que les logs RED et de paquets correspondant au test, puis les examiner avec Sophos Support si les indices concordent. Ne pas supprimer soi-même des entrées internes ni répéter les réinitialisations ; après une correction contrôlée, retester le même trajet aller-retour.

Des LED vertes n’excluent pas un blocage du chemin de données UDP. Dans ce cas, vérifiez spécifiquement le trafic du tunnel dans 5. Device Management > 3. Advanced Shell :

tcpdump -ni any port 3410

Pendant un test client contrôlé, utilisez également Diagnostics > Packet capture et déterminez si le fournisseur ou un appareil en amont bloque UDP 3410. Un paquet visible dans un sens ne confirme pas encore le bon fonctionnement du trajet aller-retour ; l’absence de paquets ne permet pas, à elle seule, d’identifier le point de blocage.

Le trafic VLAN ne fonctionne pas

Avec le SD-RED 60, les scénarios VLAN sont possibles, mais le mode de port, l’ID VLAN et le mode RED doivent correspondre.

L’aide au dépannage Sophos pour SFOS 22 et 23 limite explicitement le trafic VLAN à standard/unified. De plus, les VLAN doivent également être créés sur l’appareil RED et les modes des ports LAN de la RED doivent être définis de manière appropriée. Ne vérifiez donc pas l’affectation des VLAN uniquement sur le pare-feu ou le commutateur. Ne déduisez pas les possibilités VLAN des autres modes de fonctionnement d’un test untagged réussi ; vérifiez le mode de fonctionnement précis et la conception des ports à l’aide des modes de fonctionnement RED.

Vérifier :

• Les ID VLAN sont corrects sur le pare-feu, le RED et le commutateur.
• Le port RED est configuré comme Access, Hybrid ou Tagged Trunk de manière appropriée.
• Le port du commutateur sur le site distant est correctement tagué ou non tagué.
• Le DHCP et le DNS sont planifiés pour chaque VLAN.
• Les règles de pare-feu existent pour les réseaux VLAN respectifs.
• Le mode RED choisi prend en charge le scénario VLAN souhaité.

Pour le dépannage, un réseau de test non tagué simple est utile. Si cela fonctionne, la cause réside généralement dans l’ID VLAN, le marquage, le mode de port ou la configuration du commutateur.

Les points d’accès RED restent inactifs

Si les points d’accès RED ou les fonctions Wi-Fi restent inactifs dans les scénarios VLAN, l’option DHCP 234 peut être pertinente. Cela concerne surtout les cas où la communication RED ou des points d’accès passe par des interfaces VLAN. Sophos cite SD-RED 20 et SD-RED 60 pour ce scénario de point d’accès.

N’activez cette option que si le scénario s’applique et si l’adresse IP de l’interface du pare-feu à joindre est connue. Choisir le bon mode de fonctionnement Sophos RED explique l’association complète entre zone Wi-Fi, VLAN et option DHCP 234. L’option 234 n’est pas le premier contrôle en cas de problème général de connexion RED.

Pour cette erreur VLAN particulière, Sophos décrit également une récupération différée : Après 30 tentatives, la RED peut obtenir une IP LAN du serveur DHCP et apparaître de nouveau comme Active. Cela ne prouve pas que le chemin VLAN souhaité fonctionne. Par conséquent, ne vous contentez pas d’attendre Active, mais vérifiez l’IP sur l’interface VLAN et l’option 234 enregistrée.

Solution sous SFOS 23 : Les étapes suivantes concernent les points d’accès RED configurés dans un VLAN qui apparaissent comme Inactive après un redémarrage et dont le VLAN ne dispose pas de l’option DHCP 234 :

1. Ouvrez Network > DHCP et modifiez le serveur DHCP configuré pour le VLAN du point d’accès RED.
2. Sous DHCP options, rechercher d’abord le code 234 et documenter la valeur actuelle ou l’absence de l’option. Ne pas écraser aveuglément une option existante fonctionnelle et ne pas créer de seconde option concurrente. Si une valeur existe, clarifier d’abord l’affectation du VLAN et de l’interface ; les étapes d’ajout suivantes ne s’appliquent que si l’option est absente.
3. Sous DHCP options, réglez Options sur Custom et saisissez 234 dans Code.
4. Dans Value, saisissez l’adresse IP configurée pour l’interface du point d’accès RED connectée à ce VLAN. Cette valeur dépend de la configuration des interfaces dans votre environnement ; il ne s’agit ni de l’IP attribuée à l’appareil ou à un client, ni d’une adresse publique quelconque du pare-feu.
5. Enregistrez les modifications.

Vérifiez ensuite l’option enregistrée dans le serveur DHCP, y compris le code et l’IP de l’interface. Le point d’accès RED devrait recevoir une adresse IP sur son interface VLAN après un court délai. Vérifiez cette attribution, puis contrôlez à nouveau l’état du point d’accès RED. S’il reste Inactive, vérifiez d’abord la correspondance entre le serveur DHCP, le VLAN et l’IP de l’interface.

Solution sous SFOS 22 : Pour la même erreur VLAN, le guide Sophos propre à la version utilise la Device Console au lieu de la saisie dans WebAdmin décrite ci-dessus. Dans la CLI, sélectionner 4. Device Console et, avant toute modification, consulter sans les modifier les liaisons du bon serveur DHCP de VLAN :

system dhcp dhcp-options binding show dhcpname <dhcp server name>

Remplacer <dhcp server name> par le nom du serveur DHCP dans le VLAN du point d’accès RED. Documenter la liaison existante pour l’option 234, avec sa valeur, ou son absence. Ne pas écraser aveuglément une liaison fonctionnelle et ne pas ajouter de liaison concurrente. Si une valeur existe, clarifier d’abord l’affectation du VLAN et de l’interface. Avant de créer une liaison, clarifier également la procédure d’administration documentée pour modifier ou supprimer des liaisons d’options DHCP pour la version installée. Si cette procédure de retour arrière n’est pas claire, ne rien modifier et faire appel à Sophos Support. Ajouter la liaison de manière ciblée uniquement si l’option est absente :

system dhcp dhcp-options binding add dhcpname <dhcp server name> optionname dhcp_magic_ip(234) value <interface ip address>

Remplacer <dhcp server name> comme ci-dessus et <interface ip address> par l’adresse IP configurée de l’interface du point d’accès RED connectée au VLAN. Ne pas utiliser l’adresse IP du client. Après la modification, exécuter à nouveau la même commande de consultation system dhcp dhcp-options binding show dhcpname <dhcp server name> et vérifier la liaison enregistrée ainsi que sa valeur. Vérifier ensuite l’adresse IP sur l’interface VLAN et l’état. Ne pas appliquer en parallèle sans contrôle la liaison CLI de SFOS 22 et la procédure WebAdmin de SFOS 23 ; choisir la variante adaptée à la version installée et vérifier l’option enregistrée.

Retour arrière pour les deux variantes : Si la solution reste inefficace ou si l’attribution d’adresses VLAN ou l’état se dégrade, rétablir l’état initial documenté. Sous SFOS 23, dans le même serveur DHCP sous Network > DHCP > DHCP options, remettre la valeur précédente ou supprimer uniquement l’option 234 nouvellement ajoutée, puis enregistrer. Sous SFOS 22, utiliser la procédure d’administration des liaisons d’options DHCP préalablement clarifiée et documentée pour la version installée : rétablir la liaison consignée ou supprimer uniquement la liaison nouvellement créée. Ne supprimer aucune autre option ni aucun serveur DHCP ; ne pas essayer de syntaxe de suppression non confirmée. Vérifier ensuite à nouveau les options ou liaisons enregistrées, l’adresse IP sur l’interface VLAN et l’état du point d’accès RED.

L’approvisionnement hors ligne est écrasé

Si un RED a d’abord été approvisionné en ligne puis approvisionné hors ligne via USB, une ancienne configuration en ligne peut rester sur le serveur d’approvisionnement Sophos. Si le RED n’atteint pas le pare-feu, il peut se réapprovisionner en ligne et écraser la configuration USB.

Dans ce cas, le RED doit être réapprovisionné hors ligne. De plus, l’ancienne configuration en ligne doit être supprimée via le support Sophos.

Diagnostic et contrôle opérationnel

Points de diagnostic sur le Sophos Firewall

Pour les problèmes RED, ces points sont utiles :

• Network > Interfaces pour l’interface RED et le statut
• Administration > Device access pour les autorisations de service RED
• Rules and policies > Firewall rules pour le trafic du réseau RED
• Diagnostics > Packet capture pour la vérification du chemin
• Log viewer avec les événements RED, pare-feu et système
• Backup & firmware > Pattern updates pour le RED Firmware Pattern
• Advanced Shell avec tcpdump

Une connexion réussie peut également être confirmée dans les journaux propres à l’appareil. /log/red.log affiche un message tel que New connection from ... with ID <RED ID>. /log/red-<RED ID>.log contient ensuite connected OK, pushing config et, après une reconnexion, is now re-connected. Ces lignes confirment la connexion et le transfert de la configuration, mais pas le fonctionnement du trafic de production. Le journal complet propre à l’appareil peut contenir des données de provisionnement et de configuration et doit être nettoyé avant tout partage.

Pour les fichiers journaux et l’attribution des services, voir Dépannage Sophos Firewall : Services et journaux.

Si, en revanche, le pare-feu lui-même démarre en mode failsafe avec Failed to start Red server service, il ne s’agit pas d’une panne ordinaire d’un tunnel RED. Le runbook failsafe explique la distinction entre les builds et la conservation des preuves avant la récupération.

Liste de contrôle opérationnelle

Avant le déploiement :

• ID RED et code de déverrouillage documentés.
• Adresse publique du pare-feu ou FQDN vérifié.
• TCP 3400, UDP 3410 et NTP 123 vérifiés.
• Service RED et accès aux appareils planifiés sur le pare-feu.
• Zone, DHCP, routage et règles de pare-feu définis.
• Mode VLAN testé au besoin à l’avance.

Après la connexion :

• Les LED indiquent un établissement de tunnel réussi.
• L’interface RED est active.
• Le client reçoit une IP, une passerelle et un DNS.
• Le Log Viewer montre la règle de pare-feu attendue.
• Les systèmes cibles internes et le chemin Internet fonctionnent comme prévu.
• Le Firmware Pattern est à jour.

En exploitation :

• Vérifiez régulièrement le RED Firmware Pattern.
• Testez les connexions de site après les mises à niveau du pare-feu.
• Testez les tunnels RED entre firewalls séparément des sites SD-RED physiques.
• Vérifiez les effets du masque /32 corrigé sur les RED system hosts après une mise à niveau vers SFOS 21.0 MR2 ou SFOS 21.5 MR1.
• Comparez le débit RED avec une référence locale, un et quatre flux iPerf3, ainsi que les deux sens.
• Maintenez 802.3az ou EEE désactivé sur les ports de switch directement connectés et vérifiez-le à nouveau après un remplacement de switch.
• Ne modifiez Tunnel compression et MTU qu’avec un test avant/après documenté.
• Intégrez les sites RED dans la surveillance, la sauvegarde et la planification d’urgence.

FAQ