Créer et vérifier une Custom Gateway sur Sophos Firewall

Une Custom Gateway décrit sur Sophos Firewall un next hop situé sur une interface existante. Cet objet est particulièrement utile pour les chemins MPLS, RED, GRE et XFRM adressés, car il peut recevoir son propre Health Check et sa propre zone, puis être utilisé dans une route SD-WAN.

Réponse rapide

Une Custom Gateway se crée ici :

Routing > Gateways > Add

Pour un chemin MPLS via Port4, on saisit par exemple :

• Name: MPLS_Zurich_GW
• Gateway IP: 192.0.2.2
• Interface: Port4-192.0.2.1
• Zone: MPLS
• Health check: On
• Monitoring condition: PING vers 10.20.0.10

Il faut ensuite sélectionner la passerelle dans une route SD-WAN adaptée et la vérifier avec la règle de pare-feu, le chemin de retour, Log viewer et du trafic réel. Une icône d’état verte confirme uniquement le Health Check, pas le fonctionnement de toute la connexion.

⚠️ Une Custom Gateway n’est pas une passerelle WAN physique supplémentaire. Elle n’apparaît pas sous Network > WAN link manager et ne participe pas au Load Balancing WAN, même si la zone WAN lui est attribuée.

Distinguer Custom Gateway, route et interface

Plusieurs objets remplissent des fonctions différentes sur un chemin opérationnel :

• L’interface relie le pare-feu au réseau de transit, par exemple Port4, RED ou XFRM.
• La Gateway IP est le routeur suivant directement accessible sur ce chemin.
• La Custom Gateway regroupe Gateway IP, interface, zone et Health Check facultatif dans un objet réutilisable.
• La route SD-WAN décide quel trafic utilise cette passerelle.
• La règle de pare-feu autorise les zones, réseaux et services prévus.
• Le site distant a besoin d’un chemin de retour approprié.

Une route statique normale peut contenir directement la Gateway IP et ne nécessite pas d’objet passerelle distinct. Une Custom Gateway devient utile lorsque SFOS doit surveiller le chemin, le sélectionner dans une route SD-WAN ou le classer à l’aide d’une zone de passerelle.

Les passerelles WAN physiques sont au contraire créées automatiquement lors de la configuration d’une interface WAN et sont gérées comme Active ou Backup dans le WAN link manager. Cette séparation évite de traiter par erreur un chemin MPLS interne ou un tunnel comme une connexion Internet.

Planifier la topologie d’exemple

L’exemple continu relie un réseau client à un réseau de serveurs distant via un routeur MPLS :

• Réseau client local : 10.10.0.0/24
• Client de test : 10.10.0.10
• Interface du pare-feu : Port4 avec 192.0.2.1/30
• Routeur MPLS : 192.0.2.2
• Réseau distant : 10.20.0.0/24
• Hôte stable de supervision et de test : 10.20.0.10
• Service de test : TCP 443
• Zone personnalisée : MPLS de type LAN

192.0.2.0/24 est un réseau de documentation qui n’est pas utilisé en production. Dans l’environnement réel, il faut remplacer ensemble l’adresse IP de l’interface et la Gateway IP par le véritable réseau de transit. Le réseau distant et l’hôte de supervision doivent réellement se trouver derrière cette passerelle. La zone MPLS est créée au préalable sous Network > Zones et sécurisée selon le niveau de confiance du chemin ; les zones et interfaces sur Sophos Firewall en expliquent les bases.

Avant la modification, il faut documenter la route existante, les règles de pare-feu, le comportement NAT attendu et le chemin de retour. Une modification à distance nécessite également une sauvegarde de configuration, une fenêtre de maintenance et une voie de gestion indépendante.

Créer la Custom Gateway

Saisir les valeurs de base de la passerelle

1. Ouvrir Routing > Gateways.
2. Sous IPv4, cliquer sur Add.
3. Saisir MPLS_Zurich_GW comme Name. Le nom est libre, mais devrait identifier le site et le chemin.
4. Saisir 192.0.2.2 comme Gateway IP. Il s’agit du routeur MPLS directement accessible, et non du réseau de destination distant.
5. Sélectionner Port4-192.0.2.1 comme Interface. La Gateway IP et l’interface doivent appartenir au même chemin de transit accessible.
6. Sélectionner MPLS comme Zone.

Sophos Firewall donne la priorité à la zone de la passerelle par rapport à celle de l’interface. Elle ne s’applique toutefois au trafic que lorsque la passerelle est sélectionnée dans une SD-WAN policy route correspondante. Avec une route statique seule, il faut donc vérifier séparément le comportement de la zone. La zone VPN ne peut pas être attribuée à une Custom Gateway.

La zone de la passerelle ne s’applique pas aux SD-WAN policy routes migrées depuis SFOS 18.0 MR1 ou une version antérieure. Dans ce cas, le seul champ de zone visible ne prouve pas qu’une règle existante est correcte. Il faut d’abord tester la route, la correspondance de zone et le trafic réel dans une fenêtre de maintenance.

Choisir un Health Check représentatif du chemin

Health check est désactivé par défaut. Pour un chemin MPLS, RED ou XFRM supervisé, on l’active et on commence par les valeurs par défaut documentées :

• Interval: 60 secondes
• Time-out: 2 secondes
• Retries: 3
• Protocol: PING
• IP address: 10.20.0.10

L’hôte de supervision se trouve volontairement derrière la passerelle. Si seule la Gateway IP directement voisine était contrôlée, le routeur pourrait répondre alors que le chemin MPLS ou le tunnel situé en aval est interrompu. Pour les Custom Gateways sur route-based VPN, RED et MPLS, Sophos indique explicitement un hôte derrière la passerelle comme cible de contrôle.

Il est également possible d’utiliser TCP avec un port précis. Cela convient si le contrôle doit couvrir non seulement l’accessibilité IP, mais aussi un service qui répond de manière stable. Toutefois, un contrôle TCP sur le port 443 déclare la passerelle indisponible lorsque le service web tombe en panne, même si le routage fonctionne encore. La cible et le protocole de contrôle doivent donc représenter le signal de failover recherché.

Avec plusieurs Monitoring Conditions :

• AND: Toutes les conditions doivent être remplies. Cette méthode est stricte, mais une seule cible indisponible peut provoquer un basculement inutile.
• OR: SFOS contrôle les conditions de haut en bas jusqu’à ce que l’une d’elles soit remplie. Cela réduit les fausses alertes, mais peut masquer une panne partielle.

Il ne faut pas raccourcir Interval, Time-out ou Retries sans mesure préalable. On commence par mesurer la latence normale et les pertes de paquets ponctuelles sur le chemin réel. Des valeurs trop agressives peuvent faire osciller l’état entre actif et inactif.

Après l’enregistrement, Routing > Gateways indique au moyen d’une icône si le Health Check considère la passerelle comme active ou inactive.

Utiliser la passerelle dans le design de routage

Créer une route SD-WAN pour le trafic d’exemple

Un objet passerelle ne transfère aucun trafic à lui seul. Pour l’exemple, on crée une route SD-WAN :

1. Ouvrir Routing > SD-WAN routes > IPv4 > Add.
2. Saisir Clients_to_Branch_MPLS comme Name.
3. Sélectionner l’interface interne comme Incoming interface.
4. Définir Source networks sur 10.10.0.0/24.
5. Définir Destination networks sur 10.20.0.0/24.
6. Sélectionner d’abord uniquement HTTPS, ou TCP 443, sous Services.
7. Sous Link selection settings, utiliser Primary and backup gateways.
8. Sélectionner MPLS_Zurich_GW comme Primary gateway.
9. N’indiquer un véritable chemin de secours que s’il est entièrement configuré et testé.
10. Définir Route only through specified gateways en connaissance de cause : lorsque l’option est activée, SFOS rejette le trafic si aucun des chemins indiqués n’est disponible ; lorsqu’elle est désactivée, une autre route SD-WAN ou la route par défaut peut prendre le relais.
11. Enregistrer la route et vérifier sa position. La première route SD-WAN correspondante l’emporte.

Les réseaux et le service sont des valeurs propres à l’environnement. Une route large avec Any comme source, destination et service peut capturer bien plus de trafic que prévu. La correspondance reste donc étroite pour le premier test et n’est élargie délibérément qu’après une validation réussie.

Ajouter la règle de pare-feu et le chemin de retour

Pour le flux transféré, on crée une règle journalisée de la zone source du réseau client vers la zone de passerelle MPLS. La source, la destination et le service correspondent à la route SD-WAN :

• Source zone: LAN
• Source network: 10.10.0.0/24
• Destination zone: MPLS
• Destination network: 10.20.0.0/24
• Services: HTTPS
• Log firewall traffic: activé

La zone de la passerelle ne remplace pas une règle de pare-feu. Inversement, une règle seule n’impose pas le chemin MPLS. Les deux doivent correspondre à la route SD-WAN. Créer et vérifier en toute sécurité les règles Sophos Firewall explique la structure générale des règles.

Le routeur derrière le réseau distant a besoin d’un chemin de retour vers 10.10.0.0/24. Dans une interconnexion de sites normale, l’adresse IP d’origine du client est généralement conservée. Une règle MASQ large la masquerait et pourrait sembler réparer le retour tout en dégradant le design de routage.

Distinguer XFRM, GRE et les autres chemins de tunnel

Avec un IPsec route-based en Any-to-Any, l’interface XFRM reçoit une adresse IP de transfert. Une Custom Gateway utilise alors l’adresse IP XFRM du pair comme Gateway IP, le XFRM local comme Interface et un hôte stable du réseau distant comme Monitoring Target. La configuration complète du tunnel reste décrite dans Configurer un VPN IPsec site-to-site.

L’IPsec route-based avec des traffic selectors précis fonctionne différemment : SFOS crée automatiquement la route, et le XFRM ne reçoit ni adresse IP propre ni route manuelle. Il ne faut pas appliquer à cette variante une procédure de passerelle Any-to-Any sans vérification.

Un chemin GRE ne commence pas non plus par l’objet de passerelle. Il faut d’abord valider les endpoints externes, les adresses IP du tunnel et le fonctionnement de GRE en suivant Configurer et tester un tunnel GRE sur Sophos Firewall. Si le design du fournisseur exige ensuite une sélection SD-WAN, la Custom Gateway utilise l’adresse IP de tunnel du pair comme Gateway IP. La zone, le Health Check et le match de règle doivent correspondre au design concret ; la zone VPN reste indisponible pour les Custom Gateways.

Valider la passerelle et le trafic

Vérifier l’état et l’utilisation

1. Sous Routing > Gateways, MPLS_Zurich_GW doit apparaître actif.
2. Actualiser Object usage et vérifier que la route SD-WAN attendue utilise la passerelle.
3. Recontrôler les critères de correspondance, la position et la passerelle dans la route SD-WAN.
4. Dans Log viewer, contrôler le module SD-WAN pour les événements de passerelle, de Health Check et de route.
5. Pour un diagnostic plus approfondi, utiliser dgd.log comme journal de Dead Gateway Detection ; les services et fichiers journaux de Sophos Firewall en expliquent le contexte.

L’état actif de la passerelle prouve uniquement que l’hôte de supervision répond selon la condition choisie. Object Usage prouve uniquement la référence de configuration. Seul le test réel suivant confirme le chemin des données.

Tester un flux de trafic réel

1. Depuis le client de test 10.10.0.10, lancer une nouvelle connexion HTTPS vers 10.20.0.10.

2. Dans Log viewer, vérifier la source, la destination, le service, la Firewall Rule ID, une éventuelle NAT Rule ID et la passerelle utilisée.

3. Contrôler le Traffic Count de la route SD-WAN.

4. Sous Diagnostics > Packet capture, utiliser un filtre BPF précis :

   host 10.20.0.10 and tcp port 443
   

5. Vérifier que les requêtes sortent par Port4 et que les réponses reviennent par le même chemin prévu.

6. Sur le système cible, vérifier l’adresse IP source réelle et le chemin de retour.

Le Policy tester ne tient pas compte des routes SD-WAN. Il peut vérifier la correspondance d’une règle de pare-feu, mais pas la passerelle réellement utilisée. Tester une règle Sophos Firewall avec Log Viewer et Packet Capture couvre cette validation combinée.

Un test de failover n’est réalisé qu’avec un chemin de secours validé séparément, dans une fenêtre de maintenance et avec une voie de gestion indépendante. La passerelle de production référencée ne doit pas être supprimée pour simuler le test. Après la panne contrôlée du chemin, il faut vérifier à nouveau une nouvelle connexion, l’état de la passerelle, l’adresse IP source publique ou privée, le retour et le failback. Une transition sans interruption n’est pas présumée.

Délimiter systématiquement les erreurs

La passerelle reste inactive

• La Gateway IP et l’interface doivent décrire le même chemin de transit directement accessible.
• L’hôte de supervision doit réellement se trouver derrière la passerelle et répondre de manière fiable.
• Avec PING, vérifier que l’ICMP est autorisé sur tout le chemin.
• Avec TCP, vérifier le bon port et un service réellement actif.
• Utiliser Packet Capture pour vérifier que la sonde et la réponse empruntent l’interface attendue.
• Ne modifier Interval, Time-out et Retries qu’après avoir contrôlé le chemin.

La passerelle est active, mais le trafic applicatif ne fonctionne pas

• La route SD-WAN peut être absente, placée trop bas ou correspondre à d’autres valeurs de source, destination ou service.
• La Source zone et la zone de passerelle de la règle de pare-feu doivent correspondre au flux réel.
• Vérifier séparément Route Precedence, NAT et le chemin de retour.
• L’hôte de supervision peut être accessible alors qu’un autre hôte ou service cible est en panne.
• Une passerelle XFRM active ne prouve pas automatiquement que la SA IPsec, la règle de pare-feu et la route distante sont correctes.

La zone de la passerelle semble ignorée

• Vérifier que la passerelle est réellement sélectionnée dans la SD-WAN policy route correspondante.
• Avec une route statique seule, vérifier la zone de l’interface et la règle de pare-feu qui correspond réellement.
• La zone de passerelle ne s’applique pas à une route SD-WAN migrée depuis SFOS 18.0 MR1 ou une version antérieure. Il ne faut pas masquer le chemin avec une règle large, mais moderniser de façon contrôlée la route et le modèle de zones.
• La zone VPN n’est pas disponible pour une Custom Gateway. Une interface XFRM reste néanmoins une interface VPN et nécessite un design délibéré de règles et de routage.

L’état oscille inutilement entre actif et inactif

• Vérifier la disponibilité réelle de la Probe Target et ses éventuelles limites de débit.
• Mesurer la latence normale et les pertes de paquets avant de modifier les valeurs.
• Avec AND, une seule cible peut rendre toute la passerelle inactive.
• Avec OR, une cible de secours accessible peut masquer une panne partielle.
• Ne pas utiliser des intervalles ou Time-outs plus courts comme solution générale de stabilité.

Revenir en arrière en toute sécurité et exploiter la passerelle

Avant le rollback, il faut documenter Object Usage, la route d’origine et les règles de pare-feu d’origine. Ensuite :

1. Désactiver la nouvelle route SD-WAN ou restaurer le chemin précédent.
2. Vérifier avec une nouvelle connexion client que le chemin d’origine fonctionne à nouveau.
3. Supprimer les règles de pare-feu ou NAT créées uniquement pour le test dès qu’aucune dépendance ne subsiste.
4. Actualiser Object Usage.
5. Supprimer la Custom Gateway uniquement lorsqu’aucune route ni aucun profil ne l’utilise plus.

En exploitation, il faut documenter le responsable, la Gateway IP, l’interface, la zone, les Probe Targets, le protocole, Interval, Time-out, Retries, les routes qui utilisent la passerelle et le dernier test de failover. Après toute modification de MPLS, RED, XFRM, des zones, de SD-WAN ou de l’hôte de supervision, l’état et le trafic réel sont testés à nouveau.

FAQ