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.

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 modèle de firmware RED 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.

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.

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

1. Sur la firewall, vérifier sous Administration > Time si la firewall convient comme serveur NTP pour le scénario RED. Lors d’un setup manuel, le RED doit obtenir une heure valide afin que le TLS handshake avec la firewall fonctionne.
2. Sous Network > Zones, créer une zone dédiée pour les sites RED ou utiliser une zone existante comme VPN ou WiFi. La zone LAN devrait être évitée pour RED afin que les règles LAN ne s’appliquent pas involontairement au site distant.
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. Télécharger le fichier de provisioning généré sur l’interface RED.
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.

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.

Les RED offline ont malgré tout besoin d’une heure valide. Soit le RED peut atteindre les serveurs NTP Sophos, soit une Local service ACL exception rule ciblée est prévue afin que le RED puisse parler depuis la zone WAN vers la firewall. La source doit être uniquement l’IP RED connue, la destination est le port WAN de la firewall, le service dans ce scénario est HTTPS, l’action Accept. Cette exception ne remplace pas une ouverture large de RED via WAN.

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, le RED est en train d’installer un firmware. À ce stade, il ne faut pas éteindre l’appareil ni le déconnecter d’Internet. Une mise à jour peut prendre quelques minutes.

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

Backup & firmware > Pattern updates

Le modèle de firmware RED doit y être à jour. Si un RED est bloqué dans une boucle ou ne démarre plus correctement après une mise à jour du pare-feu, un modèle de firmware RED 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 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.

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.

Hôtes système RED après SFOS 21.5 MR1

Depuis SFOS 21.5 MR1, les objets hôtes système RED reçoivent le masque de sous-réseau /32 correct. Si ces objets générés automatiquement ont été utilisés auparavant dans des règles ou d’autres configurations pour plus d’une IP hôte, le trafic peut correspondre différemment après la mise à jour.

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 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 ?

Pour l’approvisionnement RED, le RED doit atteindre le service d’approvisionnement Sophos. Dans de nombreux environnements, red.astaro.com sur TCP 3400 est pertinent.

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 ?

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
• modèle de firmware RED obsolète
• code de déverrouillage incorrect
• configuration RED endommagée ou incorrecte

Vérifiez d’abord l’alimentation, les câbles et le DHCP. Ensuite, contrôlez le modèle de firmware RED, l’accessibilité des ports et la configuration. Si le RED est recréé ou réinitialisé, l’ID RED et le code de déverrouillage doivent être documentés au préalable.

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.

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.

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.

Cette option ne doit être définie que si le scénario concret est adapté et qu’il est clair quelle IP d’interface de pare-feu les appareils doivent atteindre. Pour les problèmes généraux de connexion RED, l’option DHCP 234 n’est pas le premier pas.

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.

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 modèle de firmware RED
• Advanced Shell avec tcpdump

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 modèle de firmware est à jour.

En exploitation :

• Vérifiez régulièrement le modèle de firmware RED.
• 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 impacts /32 sur les hôtes système RED après 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