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.
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, puis autoriser le service RED uniquement depuis les zones nécessaires.
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.

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.

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. Affecter une zone choisie volontairement et enregistrer l’interface.
9. Dans le menu de la nouvelle interface RED, télécharger le fichier de provisionnement.

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.

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. Affecter la zone planifiée et enregistrer l’interface.

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.

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 les règles de firewall et le service RED

Le trafic transféré nécessite une règle adaptée sur les deux firewalls. Une règle LAN-to-LAN large est un exemple fonctionnel simple, mais en production le réseau source, le réseau de destination et les services sont limités au besoin réel. La journalisation reste activée pendant la validation.

Dans cet exemple, le firewall central a besoin d’une règle du LAN 10.10.0.0/16 vers le réseau de la filiale 10.20.0.0/16. Sur la filiale, le trafic de retour ou dans le sens inverse est représenté selon les besoins. Le NAT est généralement inutile pour une liaison de sites routée ; les deux côtés doivent voir les vraies adresses source et disposer d’un chemin retour complet. Comprendre et configurer les règles Sophos Firewall approfondit le fonctionnement des règles.

Le service RED doit également être joignable depuis les zones par lesquelles arrive la connexion RED. Sous Administration > Device access, RED peut être activé pour une zone. Lorsque les adresses source stables sont connues, une Local service ACL exception rule ciblée est préférable à une autorisation large de toute la zone WAN. Cette exception ne concerne que le canal de contrôle RED et ne remplace pas une règle de firewall pour le trafic intersite. Les détails figurent dans Device Access et Local Service ACL.

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 ou un failover contrôlé, un nouveau flux est à nouveau établi avec succès.

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

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, les règles de firewall supplémentaires sont d’abord désactivées, puis les deux routes statiques sont supprimées. L’interface RED client, puis l’interface RED serveur, peuvent ensuite être supprimées de manière contrôlée. Les autorisations temporaires de Device Access ou de Local Service ACL retrouvent leur état antérieur documenté.

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