Configurer Site-to-Site RED entre deux Sophos Firewall

Un tunnel Site-to-Site RED relie directement deux Sophos Firewall sans déployer d’appliance SD-RED sur l’un des sites. Un firewall joue le rôle de Firewall RED server et accepte la connexion. L’autre agit comme Firewall RED client et établit le tunnel vers le serveur.

Ce processus actuel sous SFOS 22 ne doit pas être confondu avec un mode de fonctionnement RED tel que Standard/Unified ou Standard/Split. Ces modes concernent un SD-RED physique. Une architecture firewall à firewall utilise à la place des interfaces RED, des routes statiques et des règles de firewall adaptées sur les deux équipements.

⚠️ Avant toute modification, il faut disposer d’une sauvegarde récente des deux firewalls, d’un accès administratif indépendant et d’un chemin de reprise documenté. Dans la mesure du possible, l’adresse publique du Firewall RED server ne doit pas être traduite par NAT, car cette traduction peut perturber les connexions RED entrantes.

Le processus en huit étapes

1. Planifier les rôles, les IP RED, les réseaux des sites et une adresse de serveur joignable.
2. Activer le RED provisioning service sur les deux firewalls et autoriser le chemin de contrôle RED.
3. Créer l’interface Firewall RED server sur le site central.
4. Transmettre de manière sécurisée le fichier de provisionnement généré au site distant.
5. Créer l’interface Firewall RED client sur la filiale et importer le fichier.
6. Ajouter sur chaque côté une route statique vers le LAN distant, avec l’IP RED du pair comme gateway et sans sélectionner d’interface.
7. Autoriser le trafic utile sur les deux firewalls avec des règles étroites et journalisées ; ne pas créer de règle NAT liée.
8. Vérifier séparément le tunnel, la route, la correspondance de règle et un trafic bidirectionnel réel.

Une interface RED verte confirme uniquement que le tunnel est établi. Elle ne prouve pas que le routage, les règles de firewall et le chemin retour fonctionnent.

Planification et conception

Quand Site-to-Site RED convient

Site-to-Site RED est une méthode simple pour relier deux Sophos Firewall. Le provisionnement RED prend en charge une partie de la négociation VPN classique, tandis que les LAN distants continuent d’utiliser un routage et des règles de firewall ordinaires.

Pour une nouvelle architecture, le choix entre RED et Site-to-Site IPsec doit tout de même être volontaire. IPsec offre davantage d’options de profil, de routage, d’interopérabilité et de redondance. Site-to-Site RED est intéressant lorsque les deux extrémités sont des Sophos Firewall et qu’un tunnel simple propre à Sophos suffit.

Un SD-RED physique se configure avec Configurer et dépanner Sophos SD-RED. Les modes de fonctionnement RED ne s’appliquent pas au tunnel firewall à firewall décrit ici.

Planifier la topologie d’exemple

L’exemple suivant utilise volontairement des adresses de documentation. Elles doivent toutes être remplacées par les réseaux et adresses réels des deux sites :

• Site central, rôle Firewall RED server : adresse publique 198.51.100.10, LAN 10.10.0.0/16
• Filiale, rôle Firewall RED client : adresse publique 203.0.113.20, LAN 10.20.0.0/16
• IP RED du site central : 10.255.100.1
• IP RED de la filiale : 10.255.100.2

Les deux IP RED forment la paire d’adresses entre les firewalls. Elles ne doivent entrer en conflit ni avec un LAN de site, ni avec un autre réseau d’interface ou de VPN. Le firewall client doit pouvoir joindre de manière fiable l’adresse IP publique ou le FQDN du serveur.

Cet exemple utilise 255.255.255.252 (/30) comme RED netmask. Ce petit réseau de transit contient exactement la paire requise. Si un autre réseau libre est retenu, les deux IP RED et le masque doivent être remplacés de façon cohérente. RED ne résout pas le chevauchement des LAN : il faut régler le plan d’adressage ou de NAT avant de créer le tunnel.

Sophos décrit explicitement les interfaces RED comme des tunnels sécurisés et chiffrés. Lors de l’enregistrement du RED provisioning service, SFOS utilise les informations d’enregistrement pour générer un certificat destiné aux communications RED sécurisées. Le processus firewall à firewall documenté ne demande donc pas de choisir manuellement un PSK ou un certificat dans l’interface : le serveur génère une Provisioning file contenant les données de configuration du client. Ce fichier doit être transmis uniquement par un canal protégé. Voir RED tunnels and provisioning et RED.

Configurer le tunnel et le chemin de données

Créer le Firewall RED server

Le serveur est d’abord créé sur le firewall dont l’adresse publique est joignable de manière stable :

1. Sous System services > RED, activer le RED provisioning service.
2. Ouvrir Network > Interfaces.
3. Sélectionner Add interface > Add RED.
4. Sous Branch name, saisir par exemple RED-HQ-Branch.
5. Définir Type sur Firewall RED server.
6. Laisser Tunnel ID sur Automatic.
7. Saisir 10.255.100.1 comme RED IP.
8. Saisir 255.255.255.252 comme RED netmask.
9. Affecter une zone choisie volontairement, ici la zone personnalisée RED-S2S.
10. Laisser d’abord Tunnel compression et MTU inchangés, puis enregistrer.
11. Sous Network > Interfaces, choisir Download provisioning file dans le menu de la nouvelle interface RED.

Le fichier de provisionnement appartient à ce tunnel et doit être traité comme un artefact de configuration sensible. Il est transmis à la filiale par un canal protégé et, après l’importation, ne reste pas dans un dossier de téléchargement ou de partage accessible à tous.

La zone influencera ensuite les correspondances de règles et de Device Access. LAN est possible, mais une zone dédiée crée généralement une frontière de sécurité plus claire lorsqu’il existe plusieurs sites. Configurer les zones et les interfaces sur Sophos Firewall explique les relations générales.

Automatic évite de réutiliser par erreur une Tunnel ID. Si une exigence impose une valeur manuelle, Sophos précise qu’elle ne doit être utilisée sur aucun des deux équipements. Dans le processus client documenté, aucune seconde Tunnel ID n’est saisie ; le fichier de provisionnement du serveur fournit l’association. Tunnel compression peut améliorer le débit sur une liaison lente, mais consomme des ressources ; elle ne se modifie qu’après une mesure avant/après reproductible. Une MTU réduite ne se teste qu’en présence d’un problème démontré de fragmentation ou de Path MTU.

Créer le Firewall RED client

Sur le site distant, le client est créé avec le fichier généré par le serveur :

1. Ici aussi, sous System services > RED, activer le RED provisioning service.
2. Créer une nouvelle interface sous Network > Interfaces > Add interface > Add RED.
3. Utiliser un Branch name tel que RED-Branch-HQ.
4. Définir Type sur Firewall RED client.
5. Sous Firewall IP/hostname, saisir l’adresse publique ou le FQDN du serveur.
6. Sous Provisioning file, sélectionner le fichier du firewall serveur.
7. Saisir 10.255.100.2 comme RED IP.
8. Saisir également 255.255.255.252 comme RED netmask.
9. Affecter la zone RED-S2S, laisser d’abord Tunnel compression et MTU inchangés, puis enregistrer.

Si le client ne peut joindre le serveur qu’au moyen d’une adresse traduite ou changeante, le DNS, le NAT en amont et le chemin retour doivent être testés avec une attention particulière. Sophos recommande de rendre le serveur directement joignable sans NAT dans la mesure du possible.

La procédure Sophos actuelle pour Site-to-Site RED confirme les rôles, le fichier de provisionnement et la recommandation de ne pas traduire le serveur par NAT. Le client initie la connexion sortante ; la filiale n’a donc pas besoin d’une publication entrante équivalente.

Ajouter des routes statiques sans interface

Une fois établi, le tunnel ne connaît pas automatiquement les réseaux LAN situés derrière les firewalls. Une route unicast IPv4 est créée sur chaque côté :

• Site central : destination 10.20.0.0/16, gateway 10.255.100.2
• Filiale : destination 10.10.0.0/16, gateway 10.255.100.1

La particularité RED essentielle est qu’aucune interface n’est sélectionnée pour ces deux routes. Le firewall envoie des requêtes ARP afin de déterminer l’interface RED joignable pour l’adresse du pair. Sélectionner ensuite une interface peut perturber ce mécanisme et ne constitue pas une amélioration.

La route est créée sous Routing > Static routes > IPv4 unicast route > Add. La distance administrative et la métrique sont choisies délibérément en fonction du reste de l’architecture de routage. Configurer et tester une route statique sur Sophos Firewall explique la logique générale des champs et la validation avec Route Lookup.

Limiter le service RED et les règles de firewall

Le service RED local doit d’abord accepter la connexion. Sous Administration > Device access, activer RED uniquement pour la zone d’arrivée réelle. Si les adresses source publiques sont stables, créer plutôt sous Local service ACL exception rule > Add une règle Accept étroite avec Source zone, Source Network / Host, l’interface WAN comme Destination host et Services: RED. Une règle de firewall ordinaire ne contrôle pas les services locaux. Voir l’aide Sophos Device access et Device Access et Local Service ACL.

Le trafic transféré exige ensuite des règles sous Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule. Pour un flux initié par le site central : central Source zones LAN, source 10.10.0.0/16, Destination zones RED-S2S, destination 10.20.0.0/16 ; filiale Source zones RED-S2S, source 10.10.0.0/16, Destination zones LAN, destination 10.20.0.0/16. Dans les deux règles, limiter Services au besoin réel.

Pour des connexions initiées par la filiale, ajouter la paire avec réseaux et zones inversés. Activer Log firewall traffic, vérifier la position des règles et laisser Create linked NAT rule désactivé. Cette liaison routée doit conserver les vraies adresses source et un retour complet ; ne pas écraser une exception NAT volontaire sans l’examiner. Comprendre et configurer les règles Sophos Firewall approfondit le fonctionnement des règles.

Validation, troubleshooting et rollback

Valider le tunnel de manière contrôlée

La validation commence par un seul flux de test dont l’heure exacte est consignée. Il faut d’abord vérifier que les deux interfaces RED sont actives et que Route Lookup affiche le chemin attendu pour une adresse du LAN distant. Le flux doit ensuite correspondre à la Rule ID prévue sur les deux firewalls.

Une capture de paquets sur Sophos Firewall montre si le paquet entre dans l’interface RED côté source, arrive sur le pair et est transféré vers le LAN de destination. Le chemin retour est testé séparément. Un ping seul ne suffit pas lorsque l’application de production utilise TCP ou UDP sur d’autres ports.

La réussite signifie donc que tous les points suivants sont simultanément vérifiés :

• Les interfaces RED sont actives des deux côtés.
• Route Lookup affiche le chemin prévu dans les deux sens.
• La règle de firewall attendue correspond sur les deux firewalls.
• Un flux applicatif réel fonctionne dans les deux sens.
• Les adresses source et de destination apparaissent sans NAT involontaire.
• Après un redémarrage contrôlé, un nouveau flux est à nouveau établi ; un cluster HA nécessite aussi un test de failover distinct.

Pour HA, Sophos documente explicitement un délai de reconnexion des tunnels RED à l’Auxiliary Firewall après un failover. Il varie selon le nombre d’interfaces et d’autres réglages et concerne aussi Site-to-Site RED. Il ne faut donc pas promettre une reprise immédiate : consigner l’heure du failover, l’état de l’interface et le délai de reconnexion, puis retester le flux. Voir Add a RED interface.

Isoler les erreurs de manière systématique

Le client n’établit pas le tunnel : vérifier le RED provisioning service, l’adresse du serveur, le DNS, la joignabilité, Device Access et le fichier de provisionnement correspondant au tunnel. Ne pas associer sans contrôle un nouveau fichier à une ancienne configuration client.

Le fichier de provisionnement est refusé : vérifier qu’il provient de l’interface serveur actuelle et n’a pas été modifié pendant le transfert. Conserver l’état initial avant de télécharger au besoin un nouveau fichier et de recréer proprement le client pendant une fenêtre de maintenance.

Le tunnel est actif, mais le LAN distant est injoignable : vérifier sur les deux côtés le réseau de destination et l’IP RED du pair dans la route statique. Aucune interface ne doit être sélectionnée pour cette route RED particulière. Vérifier ensuite la correspondance de règle et la route de retour.

Un seul sens fonctionne : il manque généralement une règle ou une route adaptée sur un firewall, ou bien un réseau de site est déjà atteint par un chemin plus spécifique ou de priorité supérieure. Route Lookup, la capture de paquets et le trafic retour réel doivent concorder.

La connexion est instable : corréler la latence, la perte de paquets, la joignabilité publique du serveur, le NAT devant le serveur et les changements du chemin WAN. Sauvegarder les logs locaux du nœud pour l’heure exacte du test. Trouver et analyser les logs de service Sophos Firewall explique les fichiers de log et les procédures de support.

Les petites connexions fonctionnent, mais les gros transferts se bloquent : rechercher dans Packet Capture la fragmentation et les messages ICMP de Path MTU. Ne tester ensuite la MTU que progressivement et à l’identique sur les deux interfaces. Ne jamais modifier simultanément compression et MTU.

Aucune règle Any étendue, autorisation WAN générale, redémarrage de service ou modification aléatoire des IP RED et des routes ne remplace cette corrélation. Si l’erreur reste inexpliquée malgré une architecture correcte, la sauvegarde, le build SFOS, l’horodatage, l’état des interfaces, les routes, les Rule IDs, la capture de paquets et les logs pertinents sont rassemblés pour Sophos Support.

Effectuer un rollback sûr

Si le pilote échoue ou si l’architecture est abandonnée, désactiver d’abord les règles supplémentaires et supprimer les deux routes statiques, puis l’interface client et enfin l’interface serveur. Restaurer les autorisations Device Access/Local Service ACL ainsi que les valeurs MTU ou compression ; ne supprimer les nouveaux objets hôte/réseau que s’ils ne sont utilisés ailleurs.

Un chemin de gestion existant qui utilise précisément ce tunnel n’est pas supprimé avant qu’un autre accès ait été testé avec succès. Après le rollback, le routage normal, les règles précédentes et la joignabilité des deux firewalls sont à nouveau vérifiés.

FAQ