Aller au contenu
Avanet

Configurer et tester une route SD-WAN Sophos Firewall

Sophos Firewall

Une route SD-WAN permet de définir par quel gateway passe un flux précis sur Sophos Firewall. Elle est utile avec plusieurs accès Internet, MPLS, des VPN IPsec route-based, la VoIP ou des services cloud. La route doit être ciblée et testée avec du trafic réel, sinon elle risque d’inclure des réseaux internes ou d’utiliser la mauvaise IP publique lors du failover.

Si Sophos Fusion (anciennement Sophos Central) doit générer les tunnels basés sur les routes et les chemins entre sites pour plusieurs pare-feu administrés, il faut plutôt suivre Configurer et vérifier un groupe de connexions SD-WAN dans Sophos Fusion. Cet article explique la route SD-WAN locale, qui reste également importante pour valider les chemins distribués de manière centralisée.

Réponse courte

Une route SD-WAN se crée ici :

Routing > SD-WAN routes > IPv4 / IPv6 > Add

Quatre points doivent être définis au préalable :

  • quel trafic doit correspondre selon incoming interface, source, destination et service
  • quel primary/backup gateway ou SD-WAN profile doit être utilisé
  • si seuls ces gateways sont autorisés et quel NAT leur correspond
  • comment vérifier la route, le gateway et le chemin retour avec Log Viewer et Packet Capture

Pour les destinations IPv4 publiques, il vaut mieux éviter un Any global et utiliser si possible Internet IPv4 group ou des destinations précises. Si SD-WAN précède Static dans la route precedence, une route Any trop large peut également envoyer du trafic interne vers le gateway WAN.

La vidéo complète le guide de planification, de configuration et de validation des routes SD-WAN sur Sophos Firewall.

Utilisation et planification

Quand préférer SD-WAN à une route statique

Une route statique suffit lorsqu’un réseau de destination est toujours joignable par un next hop fixe. Les routes SD-WAN ajoutent des critères comme la source, le service, l’utilisateur ou l’application et peuvent choisir les gateways selon leur disponibilité ou leur qualité.

Cas courants :

  • envoyer certains clients ou services via WAN2 et basculer sur WAN1 en cas de panne
  • envoyer la VoIP ou les applications cloud par un chemin à faible latence et faible perte de paquets
  • utiliser MPLS, LTE/5G ou un tunnel IPsec route-based comme chemin principal ou de secours
  • lier le trafic à un fournisseur dont l’IP publique est autorisée par un système distant

Exemple de planification et prérequis

Avant de créer la route, il faut décrire un flux concret. Pour le trafic Microsoft 365, la planification peut être la suivante :

  • Incoming interface : interface LAN interne
  • Source network : Client_Net_10.20.0.0_24
  • Destination : groupe de destinations Microsoft 365 géré en interne ou Internet IPv4 group
  • Services : HTTPS et, si nécessaire, un groupe de services pour UDP 3478-3481
  • Primary gateway : WAN2
  • Backup gateway : WAN1
  • Fallback : autoriser la default route ou activer Route only through specified gateways
  • NAT : MASQ ou IP SNAT fixe correspondant au gateway choisi
  • Test : IP client, destination, gateway attendu et entrée de log attendue

Il faut aussi des règles firewall appropriées, des règles NAT pour le trafic à traduire, le logging firewall activé et un accès à Log viewer et Diagnostics > Packet capture. Les gateways WAN se trouvent sous Network > WAN link manager ; les custom gateways pour MPLS, RED ou XFRM se créent sous Routing > Gateways.

Le comportement Active/Backup général du chemin WAN par défaut est expliqué dans Configurer le basculement WAN sur Sophos Firewall ; pour les principes concernant les interfaces et les passerelles, consulter Configurer les zones et interfaces Sophos Firewall.

Avec IPsec route-based, le sens est important : Une interface XFRM sélectionnée comme Incoming interface correspond au trafic entrant depuis le tunnel. Pour le trafic LAN vers VPN, il faut plutôt choisir le gateway de l’interface XFRM comme primary gateway ou l’ajouter à un SD-WAN profile. Les bases sont décrites dans Créer une route IPsec sur Sophos Firewall.

Pour un exemple Teams plus ciblé, ajouter le groupe fictif Sales_Team sous Users or groups et Teams_VoIP sous Application objects. Remplacer ces noms par le groupe d’utilisateurs réel et les applications effectivement nécessaires. Avec l’interface LAN, Client_Net_10.20.0.0_24, les destinations et services prévus, ces critères dirigent uniquement le flux correspondant via WAN2/WAN1. Vérifier séparément une règle d’autorisation restrictive de LAN vers WAN pour cette source, ces destinations et services, les droits utilisateur souhaités et le NAT sur les deux chemins. La route SD-WAN n’accorde aucun accès ; le test doit confirmer l’utilisateur, l’application, Firewall Rule ID et NAT ID prévus.

Deux WAN avec des priorités opposées

Pour le LAN 10.20.0.0/24, certaines destinations publiques doivent emprunter de préférence WAN1, et les autres destinations IPv4 publiques WAN2. Chaque liaison sert de secours à l’autre. Cet exemple de planification complète la procédure SFOS-22 ; la documentation SFOS-23-EAP confirme le mécanisme des profils, mais ne valide pas n’importe quel build.

⚠️ Les nouvelles routes et leur ordre modifient le chemin des données. Consigner d’abord les positions des routes, les états On/Off, les valeurs des profils, le NAT et la Route Precedence actuelle, puis vérifier un accès d’administration indépendant. Effectuer les tests de panne uniquement pendant une fenêtre de maintenance approuvée ; ne pas supprimer ni modifier des passerelles ou profils partagés pour simuler une panne.

  1. Sous Routing > SD-WAN profiles > Add, créer deux profils distincts avec Routing strategy: First available gateway : Ziele_WAN1_WAN2 dans l’ordre WAN1, WAN2, et Internet_WAN2_WAN1 dans l’ordre WAN2, WAN1. Les noms, le LAN et les passerelles sont des exemples adaptables. Activer Health check dans les deux profils ; laisser SLA désactivé pour cette sélection fondée uniquement sur la disponibilité. Choisir les cibles de sonde, le protocole et les compteurs selon la procédure de contrôle de santé ci-dessous, sans reprendre aveuglément les valeurs par défaut. Les cibles doivent détecter une panne au-delà de la passerelle de l’opérateur, et pas seulement sa joignabilité locale.
  2. Sous Routing > SD-WAN routes > IPv4 > Add, créer la route spécifique LAN_Ziele_WAN1 : Incoming interface correspond à l’interface LAN réelle, Source networks à l’objet pour 10.20.0.0/24, Destination networks au groupe tenu à jour des destinations publiques sélectionnées, et Services aux seuls services nécessaires. Choisir le profil Ziele_WAN1_WAN2. Pour les domaines, tenir d’abord compte des limites des hôtes et groupes FQDN ; un nom de domaine ne garantit pas une plage d’IP de destination exclusive.
  3. En dessous, créer LAN_Internet_WAN2 avec la même interface LAN et le même réseau source, Destination networks: Internet IPv4 group, les services Internet autorisés et Internet_WAN2_WAN1. La route spécifique doit se trouver au-dessus de la route Internet générale. Ne pas utiliser de route globale Any ; les destinations internes et VPN n’appartiennent pas à ce chemin Internet.
  4. Définir délibérément Route only through specified gateways pour les deux routes : l’option est activée dans cet exemple pour qu’aucun autre chemin ne prenne le relais si les deux chemins prévus tombent en panne. Vérifier séparément les autorisations du pare-feu et le MASQ/SNAT pour les deux WAN. Si le correspondant exige une IP publique fixe, l’IP de secours doit également y être autorisée.

Pour la validation, créer une nouvelle connexion vers une destination spécifique et une autre destination publique : les chemins attendus sont initialement WAN1 et WAN2, respectivement. Tester ensuite séparément les deux pannes en amont dans un environnement de test approuvé, y compris lorsque l’interface physique reste active : si WAN1 tombe en panne, les nouvelles connexions des deux catégories doivent fonctionner via WAN2 ; si seul WAN2 tombe en panne, via WAN1. Après chaque rétablissement, comparer les nouvelles connexions à la priorité prévue et observer séparément les sessions existantes. Consigner route, passerelle et SNAT/IP publique dans les journaux ou Packet Capture, puis revérifier DNS, HTTPS et l’accès d’administration interne. Cela ne garantit ni délai fixe de basculement ni reprise sans interruption des sessions existantes.

Si le chemin est inattendu, ne pas élargir les critères : comparer d’abord les correspondances de routes, leur ordre, l’état de santé et le NAT. Pour revenir en arrière, désactiver les nouvelles routes ou restaurer les valeurs de routes, profils et NAT précédemment consignées, avec leur ordre ; revérifier ensuite l’état et les deux flux de test. Sans simulation de panne isolable, cette partie de la validation reste ouverte. Les limites détaillées des sessions et du SNAT figurent ci-dessous dans la section Tester le failover et le failback en sécurité.

MPLS entre une agence et le siège

Un exemple limité relie 10.20.0.0/24 dans l’agence aux serveurs web du réseau du siège 10.30.0.0/24 : l’interface entrante est le LAN de l’agence, le primary gateway est MPLS-1, le backup est MPLS-2 et les services se limitent aux TCP 80/TCP 443 nécessaires. Le pare-feu du siège nécessite la route de retour correspondante de 10.30.0.0/24 vers 10.20.0.0/24 via ses propres gateways MPLS. Réseaux, interfaces, gateways et services sont des exemples à adapter à la topologie réelle. La règle de pare-feu distincte de l’agence autorise LAN vers la zone MPLS réelle, ici MPLS_DMZ, uniquement pour ces réseaux et services ; les règles du siège doivent aussi autoriser le flux prévu. Ce design routé conserve les adresses privées d’origine sans SNAT. Ce n’est pas une règle NAT universelle pour toutes les installations MPLS. Vérifier les deux sens et l’adresse IP source inchangée avec du trafic réel sur les deux pare-feu.

Configurer la route SD-WAN

Définir les critères de correspondance

Pour IPv6, sélectionner des hôtes IP de destination précis plutôt qu’une destination générale Any. Si une route générique Any doit rester, créer au-dessus une route pour les hôtes IP de destination précis et leur gateway prévu ; limiter également incoming interface, source et services. Avant toute modification, noter l’ordre installé avec system route_precedence show, la position et les paramètres de la route, vérifier un accès de gestion indépendant et prévoir la restauration de ces valeurs. Une route plus précise ne justifie pas une réinitialisation aveugle de la précédence globale.

  1. Ouvrir Routing > SD-WAN routes.
  2. Choisir IPv4 ou IPv6, puis cliquer sur Add.
  3. Saisir un nom explicite comme Clients_M365_WAN2.
  4. Choisir l’Incoming interface par laquelle entre le trafic à piloter.
  5. Choisir éventuellement une valeur DSCP si les paquets entrants sont marqués de manière fiable.
  6. Définir les Source networks et ajouter des Users or groups si nécessaire.
  7. Limiter autant que possible les Destination networks.
  8. Limiter les Services aux protocoles et ports requis.
  9. Sélectionner éventuellement des Application objects.
  10. Sous Link selection settings, choisir un SD-WAN profile ou des primary/backup gateways.
  11. Activer ou désactiver consciemment Route only through specified gateways.
  12. Enregistrer la route et la placer dans le bon ordre ; la première route SD-WAN correspondante gagne.
  13. Tester avec un client et une destination définis.

Les Application Objects nécessitent une Web Protection License active. La première connexion est routée selon l’IP de destination, le port, le protocole et l’incoming interface via une autre route SD-WAN correspondante ou, à défaut, via la default route. L’Application Object ne s’applique aux connexions suivantes qu’après la détection de l’application. Les données de classification ont une TTL de 3600 secondes à partir du début de la session. Pour les Micro Apps, seul le DPI Engine Mode prend en charge toutes les applications ; le Web Proxy Mode ne prend en charge que les Pattern Applications et les Synchronized Security Applications.

Dans un cluster HA, SFOS synchronise ce cache d’Application Routing sur le lien HA dédié en multicast 226.1.1.1 sur le port 4455. Un redémarrage du pare-feu efface les données de classification. Après un redémarrage ou un problème HA, il ne suffit donc pas de vérifier l’état du tunnel ou du gateway ; il faut à nouveau générer une première connexion applicative, puis une connexion suivante.

Créer un Application Object

Le moteur DPI peut reclassifier une application au sein d’une même connexion, par exemple lors du passage d’un site web à son chat. La nouvelle décision s’applique aux connexions suivantes ; elle ne garantit pas le reroutage de la connexion en cours. Si aucune autre session ne démarre pendant la TTL de 3600 secondes à partir du début de la session, les détails de session stockés sont supprimés.

Les Application Objects peuvent contenir des applications web, des micro apps, des Synchronized Security Applications découvertes sur les endpoints, des applications personnalisées et des catégories d’applications. Choisir le type selon la détection nécessaire et respecter les limites de licence et DPI/proxy indiquées plus haut ; une catégorie entière est plus large qu’une seule application nécessaire.

Un Application Object regroupe uniquement les applications qui doivent emprunter le même chemin SD-WAN. Ouvrir Applications > Application object, sélectionner Add, attribuer un nom et limiter les résultats avec Category, Risk, Characteristics, Technology, Classification ou la recherche par nom. Sélectionner ensuite les applications réellement nécessaires et enregistrer l’objet. Sophos actualise dynamiquement la liste des applications disponibles via les mises à jour IPS et Synchronized Application Control ; il convient donc de revoir la sélection après une modification des patterns ou des applications.

Le filtre Technology distingue browser-based, client-server, network protocol, P2P et synchronized application control. Sous Classification, les valeurs disponibles sont new, sanctioned, unsanctioned et tolerated. Ces critères facilitent la sélection, mais ne prouvent pas que la route fonctionnera ensuite. Il faut pour cela une première connexion de classification, puis une nouvelle connexion de test.

Pour Microsoft 365, un objet collectif unique est souvent trop large. Un objet tel que Teams_VoIP peut contenir uniquement les applications Teams prévues pour les communications en temps réel, tandis que OneDrive ou SharePoint emprunte un autre chemin. Sélectionner ensuite l’objet enregistré dans le champ Application objects de la route SD-WAN.

Choisir un gateway ou un SD-WAN profile

Les primary/backup gateways suffisent pour un chemin préféré et un fallback. Un SD-WAN profile sépare deux décisions : Routing strategy choisit le chemin avec First available gateway ou Load balancing, tandis que le Service Level Agreement (SLA) facultatif ajoute des mesures de qualité à cette stratégie. Best quality et Custom SLA ne sont donc pas deux stratégies de routing supplémentaires.

Configurer un SD-WAN profile sous Routing > SD-WAN profiles > Add comme suit :

  1. Saisir un nom et une description, puis choisir First available gateway ou Load balancing sous Routing strategy.
  2. Affecter de deux à huit gateways et les faire glisser dans l’ordre voulu. Gateway weights n’apparaît qu’avec le load balancing ; des poids différents peuvent représenter des capacités de liaison différentes.
  3. Pour le load balancing, choisir Round-robin ou un Session persistence type adapté. La persistance peut reposer sur l’IP source, l’IP de destination, la source et la destination ou une connexion individuelle.
  4. N’activer SLA que si la latence, le jitter ou la perte de paquets doivent influencer le choix. Best quality compare un seul critère. Custom SLA vérifie la latence, le jitter et la perte de paquets par rapport aux seuils définis.
  5. Activer Health check, choisir Ping ou TCP sous Protocol et saisir jusqu’à deux Probe targets. Avec TCP, indiquer aussi un port auquel la cible répond de manière fiable. SFOS active obligatoirement le Health Check lorsque le SLA est activé.
  6. Adapter Interval between checks, Response time-out, Deactivate gateway after, Activate gateway after et Sample size for SLA au service. Ces réglages ont des fonctions différentes : Interval between checks et Response time-out régissent les sondes ; Deactivate gateway after compte les tentatives infructueuses et Activate gateway after les réponses réussies. Sample size for SLA fixe le nombre d’échantillons utilisé pour les performances moyennes du gateway. Régler séparément la détection des pannes et la réactivation ; les cinq valeurs ne forment pas un temporisateur de failover commun.
  7. Enregistrer le profile, le sélectionner dans la route SD-WAN et vérifier le chemin avec du trafic réel.

Les deux Probe Targets constituent ensemble un seul test de disponibilité : SFOS considère le gateway actif si au moins l’un répond. Si le premier ne répond plus, il passe au second et l’utilise tant que celui-ci répond. Le retour du premier ne déclenche pas à lui seul un basculement immédiat. Les cibles doivent donc se trouver derrière le gateway et représenter le chemin utile ; un ping réussi ne prouve pas que DNS, TLS ou l’application complète fonctionne.

Avec Best quality, le failback ne se produit que si le gateway d’origine est meilleur de 10 ms en latence ou de 5 ms en jitter ; il n’existe pas de marge équivalente pour la perte de paquets. Sous Routing > SD-WAN profiles, un profile actif signifie qu’au moins un gateway est disponible. Link status résume la configuration, Historical performance ouvre les mesures et Object usage indique quelles routes utilisent le profile. Vérifier ces utilisations avant de le modifier ou de le supprimer.

Si Route only through specified gateways est activé, le firewall rejette le trafic lorsque les chemins indiqués ne sont pas disponibles. Sans cette option, il vérifie les autres routes SD-WAN puis la default route. Si un backup gateway est supprimé, Sophos Firewall le remplace par None ; la suppression du primary gateway ou du SD-WAN profile supprime la route et la default route peut prendre le relais.

Avec Load balancing et Best quality, le trafic n’est réparti que si au moins deux gateways partagent les meilleures performances pour le critère choisi ; tous les gateways joignables ne sont donc pas admissibles. Avec Custom SLA, la répartition concerne les gateways qui respectent les seuils SLA définis. Un chemin joignable qui ne respecte pas le SLA n’est pas un gateway injoignable ; cela ne définit pas de règle universelle de fallback lorsqu’aucun gateway ne respecte le SLA.

Gateway weights décrit un rapport de requêtes : dans l’exemple documenté, 3:1 signifie trois requêtes sur quatre via le premier gateway et une via le second. Choisir les poids selon la capacité et les ressources des liens ; ils ne garantissent ni la même part d’octets, ni un débit précis, ni une agrégation des liens.

Pour Custom SLA, Maximum latency et Maximum jitter sont exprimés en millisecondes, et Maximum packet loss en points de pourcentage. Interval between checks définit l’intervalle entre les sondes et Response time-out le délai de réponse autorisé. Deactivate gateway after compte les tentatives de sondage infructueuses consécutives ; Activate gateway after, les réponses réussies consécutives. Sample size for SLA définit le nombre d’échantillons de sonde utilisés pour déterminer les performances moyennes du gateway. Choisir ces valeurs pour le service concerné, sans transformer un exemple de temporisation isolé en valeur par défaut universelle.

Round-robin répartit les requêtes dans l’ordre entre les gateways retenus. Avec trois gateways disponibles de poids égal et sans restriction SLA, l’exemple utilise le premier, le deuxième, le troisième, puis à nouveau le premier. Session persistence type maintient les sessions liées sur le même gateway selon la clé choisie, notamment pour les opérations bancaires ou les paniers d’achat. Un seul flux de test ne montre donc pas la répartition de nombreuses sessions indépendantes.

Quand aucun gateway ne respecte le Custom SLA

Le rejet pour gateways inaccessibles ne prouve pas un blocage strict lié au SLA pour les chemins encore accessibles. Sans preuve propre à la build, ne garantir ni la poursuite de Load balancing, ni l’emploi exclusif de First available gateway dans ce cas.

  1. Documenter build SFOS, profile, Routing strategy, ordre des gateways, poids, session persistence, seuils SLA, probe targets et Route only through specified gateways.
  2. Utiliser Link status, Historical performance et les logs SD-WAN pour distinguer les chemins accessibles hors SLA des chemins réellement inaccessibles.
  3. Tester uniquement avec un flux autorisé et isolé, pendant une fenêtre de maintenance et avec un accès de gestion indépendant. Ne pas modifier des profiles de production partagés pour simuler une panne, ni supprimer de gateways ou de profiles. Créer de nouvelles connexions et confirmer gateway, IP SNAT et résultat applicatif avec Log Viewer et Packet Capture ; examiner séparément les sessions existantes.
  4. Rétablir les valeurs de test modifiées à leur état initial documenté, puis répéter les contrôles d’état et le test avec trafic réel. Sans test autorisé, le choix reste non résolu ; sa clarification propre à la build nécessite configuration, mesures, horodatages et logs, ainsi que la build.

Cette procédure n’a pas été exécutée ici sur un firewall. Un résultat pour une build et un profile n’est pas une garantie générale de failover.

Aligner route precedence et NAT

L’ordre par défaut documenté est Static → SD-WAN → VPN. Ce n’est pas nécessairement l’état d’une installation existante : continuer à vérifier system route_precedence show avant toute décision et ne pas appliquer cet ordre automatiquement.

La route precedence définit l’ordre entre Static, SD-WAN et VPN. Les réseaux directement connectés et SSL VPN appartiennent à la catégorie Static. L’ordre actuel est visible sous Routing > SD-WAN routes ou dans la Device Console ; les modifications et le rollback sont expliqués dans Modifier prudemment la route precedence Sophos Firewall.

Le routing choisit le chemin, tandis que le NAT modifie les adresses. Le trafic Internet via WAN2 peut donc nécessiter MASQ ou une IP SNAT fixe sur ce chemin. En revanche, le NAT est souvent indésirable pour les réseaux internes et les VPN. Les relations sont expliquées dans Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT.

DNAT vers un serveur derrière un tunnel IPsec route-based

Une publication DNAT publique peut pointer vers un serveur interne qui n’est pas connecté localement, mais se trouve derrière un pare-feu distant via un tunnel IPsec route-based. Dans ce cas particulier, le DNAT et la route SD-WAN doivent reconnaître le même flux entrant avant la traduction, et le chemin de retour doit repasser par le pare-feu qui publie le service.

La procédure fiable sous SFOS 22 comprend cinq éléments liés :

  1. Sous Hosts and services > IP host, créer un objet IP précis pour le serveur distant.
  2. Sous Routing > Gateways, créer un gateway avec l’adresse IP de la passerelle distante et l’interface XFRM correspondante. Une machine stable et joignable derrière ce gateway sert de cible de surveillance.
  3. Faire correspondre la règle DNAT à l’interface WAN publique et au service proposé à l’extérieur, puis sélectionner le serveur distant comme Translated destination. L’exemple Sophos utilise MASQ pour que les réponses reviennent au pare-feu qui publie le service ; le serveur ne voit alors plus l’adresse IP d’origine du client.
  4. Dans la route SD-WAN, saisir la même interface WAN publique sous Destination networks et le port externe sous Services. Avec PAT, il s’agit explicitement du port externe, et non du port de destination interne traduit. Sélectionner comme primary gateway le gateway de l’interface XFRM.
  5. Vérifier une règle de pare-feu restrictive pour la publication et tester le flux depuis un réseau externe. NAT Rule ID, Firewall Rule ID, la route SD-WAN, le gateway XFRM choisi, les chemins aller et retour ainsi que l’adresse IP source visible sur le serveur doivent correspondre au design.

MASQ n’est pas ici une option cosmétique. Dans l’exemple documenté, il résout le chemin de retour, mais retire au serveur cible l’adresse IP réelle du client. Si le site distant dispose d’un chemin de retour vérifié vers les réseaux clients d’origine et que l’adresse IP d’origine doit être conservée, il faut un design de routing planifié et testé séparément. La publication et la sécurisation générales sont expliquées dans Publier un serveur via DNAT sur Sophos Firewall.

Plusieurs serveurs distants peuvent utiliser la même route SD-WAN s’ils sont joignables par le même gateway et se distinguent clairement par l’adresse WAN ou le port TCP externe. S’ils utilisent des gateways différents, il faut créer des routes SD-WAN séparées. Si le mauvais port, objet WAN ou gateway correspond, il ne faut pas élargir la route à Any ; il faut d’abord prouver le flux avant DNAT avec Log Viewer et Packet Capture.

Tester et valider la route

Vérifier la liste des routes et l’état des gateways

Sous Routing > SD-WAN routes, la recherche accepte le nom de la route, un objet ou une valeur d’objet ; 443 trouve par exemple les routes qui utilisent le service HTTPS. Le glisser-déposer change l’ordre. Cela modifie le traitement du trafic, car SFOS évalue les routes de haut en bas et s’arrête à la première correspondance.

Sous More options, il est possible d’activer ou désactiver une route, de la modifier ou la cloner, de remettre son compteur de données à zéro ou de la supprimer. Avant une remise à zéro, noter la valeur et l’heure. Une route clonée est une route distincte : vérifier son nom, ses critères, sa position, son gateway et son NAT avant de l’enregistrer ou de l’activer, puis contrôler son état On/Off réel.

L’infobulle de l’icône dans la colonne Active affiche des états tels que In use, Available, Unavailable, In use, but SLA isn't met ou Available and SLA isn't met. Un gateway ou un profile disponible ne prouve ni que les critères de cette route ont correspondu au trafic ni que le chemin retour fonctionne.

Avec une sélection directe primary/backup, l’icône Active distingue trois états : au moins un gateway est joignable et la route est active ; la route n’est pas active et Route only through specified gateways est désactivé ; ou elle n’est pas active et l’option est activée. Dans ce dernier cas, le trafic reste rejeté si les chemins indiqués sont injoignables, au lieu d’utiliser d’autres gateways. Lire l’infobulle avec la case à cocher, sans les assimiler à un état SLA de profile.

Test standard avec du trafic réel

  1. Choisir un client de test avec une IP connue et une destination non ambiguë.
  2. Activer le logging dans la règle firewall correspondante.
  3. Démarrer une connexion réelle.
  4. Dans Log viewer, vérifier source, destination, service, rule ID, NAT ID et gateway.
  5. Contrôler le traffic count de la route SD-WAN : OUT compte les requests et IN les replies uniquement si source et destination correspondent dans le sens concerné.
  6. Sous System services > Log settings, activer le type SD-WAN et vérifier le module SD-WAN dans Log Viewer pour les événements de profile, SLA et route.
  7. En cas de doute, définir sous Diagnostics > Packet capture un filtre précis sur le client, la destination et le port.

Le Policy tester ne prend pas en compte les routes SD-WAN. Il peut vérifier les correspondances de policy, mais ne confirme ni la route SD-WAN choisie ni le gateway réel. Pour une analyse complète, voir Tester une règle Sophos Firewall avec Log Viewer, Policy Test et Packet Capture.

Pour les logs de profile et de route dans la vue pare-feu, choisir le module Firewall dans Log viewer, ouvrir la sélection étendue avec le bouton d’expansion à côté de la liste des modules, cocher les logs SD-WAN souhaités et cliquer sur Apply. Cela complète la vue du module SD-WAN distinct.

Évaluer SD-WAN performance

L’axe x des graphiques de qualité indique le temps ; l’axe y affiche la latence et le jitter en millisecondes et la perte de paquets en points de pourcentage. Assigned weights for load balancing ouvre les poids attribués aux gateways. Mesures et poids ne constituent pas une validation de l’application.

Sous Diagnostics > SD-WAN performance, il faut sélectionner le SD-WAN profile utilisé. Il est aussi possible d’ouvrir Routing > SD-WAN profiles, de sélectionner le profile, puis de cliquer sur Historical performance sous Status. Pour chaque gateway, la vue indique le nombre total de connexions, le volume de données transféré, les poids de load balancing attribués, ainsi que la latence, le jitter et la perte de paquets pour Live, 24h, 48h, Week ou Month.

Selon Sophos, No data to display signifie qu’aucune route n’utilise encore le profile sélectionné ou qu’aucun trafic ne passe par une telle route. Ce message ne prouve donc pas un défaut de mesure. Il faut d’abord générer un flux contrôlé sur la route attendue et le confirmer avec Log Viewer ou Packet Capture.

Reset data transfer and connection count modifie les compteurs. Les valeurs et l’heure doivent être documentées avant toute remise à zéro. Même un graphique sans anomalie ne prouve pas encore que la règle de pare-feu, le NAT, l’application et le chemin de retour fonctionnent ; ces niveaux restent inclus dans le test réel.

Tester le failover et le failback en sécurité

Avant toute modification, noter la position et l’état On/Off actuels de la route, ses primary/backup gateways ou son profile, l’ordre des gateways du profile, les valeurs SLA et Health Check ainsi que la traduction NAT attendue. Le rollback consiste à rétablir exactement ces valeurs, puis à revérifier l’état, les logs et le trafic réel.

Un test de panne contrôlé s’effectue dans une fenêtre de maintenance, avec un rollback documenté et un chemin de gestion indépendant vers le firewall. Vérifier d’abord dans la Device Console les valeurs actuelles en lecture seule :

system route_precedence show
show routing reroute-connection
show routing reroute-snat-connection

Ensuite, démarrer du trafic applicatif réel, provoquer de manière contrôlée l’indisponibilité du primary gateway et vérifier le chemin, les sessions, la public source IP et le chemin retour. Ne pas supprimer le primary gateway ou le SD-WAN profile pour ce test, car cela supprime la route et ne teste que le fallback vers la default route. La modification de la route ou du profile, ainsi qu’un changement de Route Precedence, peuvent aussi rerouter des connexions existantes et ne doivent pas faire partie du même test de référence. Avec une sélection directe primary/backup, les nouvelles connexions repassent par le primary lorsqu’il revient ; les connexions existantes restent généralement sur le backup gateway.

reroute-connection est activé par défaut et concerne les connexions sans SNAT. Les connexions SNAT ne sont pas reroutées par défaut ; même avec reroute-snat-connection activé séparément, cela ne fonctionne que si les deux chemins utilisent la même source IP traduite. Avec MASQ ou des adresses Override Source Translation différentes, la connexion SNAT n’est pas reroutée et la session existante est interrompue lorsque le chemin tombe.

Modifier délibérément le rerouting

Ces réglages modifient le trafic ; ils ne sont pas des prérequis au test de référence. Les modifier uniquement dans une fenêtre de maintenance, avec un accès de gestion indépendant vérifié et un rollback documenté : enregistrer d’abord les deux états de rerouting montrés plus haut et vérifier que les deux chemins utilisent la même adresse IP source traduite pour SNAT. La Device Console propose les alternatives suivantes ; exécuter uniquement la commande nécessaire au changement prévu, et non toutes les commandes à la suite :

  • Activer sans SNAT : set routing reroute-connection enable ; désactiver : set routing reroute-connection disable.
  • Activer pour SNAT : set routing reroute-snat-connection enable ; désactiver : set routing reroute-snat-connection disable.

Vérifier ensuite avec show routing reroute-connection et show routing reroute-snat-connection, puis tester séparément les sessions, l’adresse IP source et les deux sens du trafic. Pour revenir en arrière, rétablir chaque réglage modifié dans son état enable/disable enregistré et répéter les contrôles d’état et de trafic réel. Ces commandes documentées et ce rollback n’ont pas été testés ici sur un pare-feu ; activer le rerouting SNAT ne supprime pas les restrictions MASQ/IP.

Dépanner méthodiquement

La route ne correspond pas

  • Comparer incoming interface, source network, destination et service avec le flux réel.
  • Vérifier l’ordre des routes ; la première route SD-WAN correspondante gagne.
  • Pour les Application Objects, vérifier la licence, la détection DPI et une deuxième connexion après classification.
  • Ne pas utiliser le traffic count comme seule preuve, car les requests et replies ne sont comptés que si les critères de source et destination correspondent.
  • Avec le Direct Web Proxy, une correspondance HTTP/HTTPS comme service ne suffit pas : utiliser Any ou un service pour le port configuré sous Web > General settings > Web proxy listening port. Dans ce cas particulier, source network et incoming interface ne correspondent pas pour les reply packets ; le chemin retour du proxy nécessite aussi un WAN default gateway ou une route statique appropriée.
  • Pour une route SD-WAN migrée depuis SFOS 17.5 ou une version antérieure, vérifier si sa règle de pare-feu d’origine a été supprimée. Ces routes migrées restent liées à l’ancienne règle et sont également supprimées lorsque cette règle est supprimée.
  • Pour IPv6, Dead Gateway Detection dans les routes SD-WAN ne surveille pas le trafic réseau tiers tel que SNMP. L’absence d’une mesure tierce ne constitue donc pas une preuve fiable de l’état DGD.

Configurer Direct Web Proxy avec un fichier PAC décrit le listener, le déploiement sur les clients, la règle de protection et le test avec du trafic réel.

Des paramètres d’activation et des règles de correspondance spécifiques s’appliquent aux paquets de réponse et au trafic généré par le système. Ces cas sont expliqués dans Vérifier le routage SD-WAN Sophos Firewall pour reply packets et system traffic.

Web Admin et SSH deviennent injoignables après une nouvelle route

Un scénario documenté combine quatre réglages : SD-WAN précède Static, une nouvelle route pour un réseau source interne précis a destination Any, le routage SD-WAN du trafic généré par le système est activé et celui des reply packets l’est également. L’accès de gestion depuis le réseau interne concerné peut alors être perdu, tout en restant possible depuis d’autres sous-réseaux. Ce ne sont pas des conditions nécessaires à toute panne de gestion.

Depuis un accès alternatif vérifié au préalable, contrôler la source, la destination et la précédence de la route, ainsi que ces valeurs en lecture seule dans la Device Console :

show routing sd-wan-policy-route system-generate-traffic
show routing sd-wan-policy-route reply-packet

Vérifier d’abord que la gestion depuis un sous-réseau non concerné est réellement autorisée et joignable. Ensuite, limiter précisément la destination ou rétablir un des réglages précédemment modifiés à sa valeur d’origine documentée. Ne pas effectuer de réinitialisation globale aveugle : sauvegarder au préalable la position, les paramètres et la précédence, prévoir le rollback et revérifier ensuite Web Admin, SSH et le trafic concerné. Sans accès alternatif sûr, ne pas poursuivre la modification à distance.

Le trafic emprunte le mauvais chemin

  • Pour les destinations IPv4 publiques, remplacer Any par Internet IPv4 group ou des destinations précises.
  • Vérifier la route precedence, surtout si des réseaux internes, SSL VPN ou IPsec policy-based sont concernés.
  • Vérifier l’état des gateways et du SLA ainsi que les Health Check Targets.
  • Comparer la règle NAT et la source IP traduite avec le gateway réellement utilisé.
  • Vérifier si un primary gateway ou un SD-WAN profile a été supprimé, entraînant la suppression de la route.

L’application ou la réponse échoue après le failover

Vérifier d’abord avec Packet Capture si le paquet sort par le gateway attendu et si la réponse revient. Contrôler ensuite le NAT, les listes d’IP publiques autorisées, Session Persistence, MTU/MSS et l’état du chemin VPN ou MPLS. SIP/RTP, les portails bancaires et les API à source IP fixe doivent tout particulièrement être testés avec du trafic applicatif réel.

Si le problème est apparu immédiatement après la mise à niveau vers SFOS 22.0 GA, vérifier d’abord le build installé. SFOS 22.0 MR1 Build 490 corrige NC-173667, qui provoquait la déconnexion aléatoire d’une route SD-WAN, et NC-177603, qui limitait l’audio VoIP à un seul sens via un VPN route-based après la mise à niveau vers 22.0 GA. Si MR1 ou un build ultérieur est déjà installé, ne pas attribuer l’incident au seul niveau de firmware ; répéter le test en trafic réel décrit ci-dessus et vérifier la route, les sessions, le NAT ainsi que les deux sens du trafic.

API XML : clarifier les limites des objets avant toute automatisation

La documentation de l’API XML pour SFOS 22.0 et 23.0 décrit des objets nommés distincts. La configuration via l’interface décrite plus haut reste la procédure pratique ; elle ne permet toutefois pas de déduire un contrat XML univoque. Les remarques suivantes signalent des contradictions documentées, et non une requête testée ou un schéma corrigé. Pour automatiser ces opérations, il faut obtenir de Sophos une clarification des champs concernés pour la version utilisée ; aucune correspondance numérique n’est supposée ici et aucune requête XML exécutable n’est fournie.

HealthCheckProfile nommé : cycle de vie et compteurs de sondes

HealthCheckProfile est un objet de contrôle de disponibilité autonome, distinct de SDWANProfile et de l’option intégrée de contrôle de disponibilité du gateway. Lors de la création et de la mise à jour, le champ obligatoire Name, de type chaîne scalaire, identifie le profile de contrôle de disponibilité ; les deux tableaux de champs indiquent un maximum de 125 caractères. Le tableau de la version 22.0 interdit également les virgules et autorise explicitement les caractères UTF-8, tandis que ces deux indications sont absentes du tableau de la version 23.0. Cette absence ne prouve pas une modification de la validation des noms.

ProbeTargets est décrit comme un tableau d’objets monitorDetails, alors que l’exemple contient des éléments ProbeTarget. monitormethod indique TCP ou PING ; monitorip indique les types de données IPADDRESS, IPADDRESS6 et DOMAINNAMELOOKUP. Pour operator, les valeurs littérales sont & et |, avec | par défaut. Cela ne permet de déduire ni une autre structure XML ni une équivalence avec le comportement des deux Probe Targets décrit plus haut dans l’interface. IPFamily reste également contradictoire : les deux tableaux indiquent IPv4 et IPv6, avec IPv4 par défaut, mais aussi un maximum de 1 caractère.

Les deux lignes de compteurs semblent inversées par rapport à leurs noms : ProbesResponseFailure décrit littéralement des réponses consécutives nécessaires à l’activation de l’objet, avec une valeur par défaut de 1 ; ProbeResponseSuccess décrit des sondes consécutives sans réponse avant sa désactivation, avec une valeur par défaut de 3. Les deux tableaux indiquent pour chacun une plage de 1 à 10. Cette attribution documentaire n’est pas corrigée implicitement et ne confirme pas le comportement à l’exécution. En particulier, les explications fiables de l’interface concernant Deactivate gateway after et Activate gateway after ne sont pas automatiquement transposées à ces balises API.

L’opération de suppression distincte cible elle aussi le profile de contrôle de disponibilité par Name, et non une route ou un SD-WAN profile. Avant une suppression envisagée, vérifier les SD-WAN profiles qui le référencent et documenter leur association actuelle au contrôle de disponibilité. Les sources n’établissent ni un déroulement en cascade sûr ni le comportement lors de la suppression d’un objet de contrôle de disponibilité encore référencé. Cette opération ne doit pas être assimilée à la suppression d’un SD-WAN profile décrite plus haut ; une telle suppression n’est pas non plus un test de panne.

HealthCheckProfileStatus : état administratif de l’objet de contrôle de disponibilité

HealthCheckProfileStatus active ou désactive administrativement le profile de contrôle de disponibilité nommé. Le sélecteur est le champ obligatoire Name, de type chaîne scalaire ; le nom de substitution HealthCheckProfileStatusName dans l’exemple ne change pas l’identité de ce champ. Dans les deux versions, l’exemple indique ON/OFF pour Status, alors que la ligne du champ obligatoire indique INTEGER sans correspondance numérique. Cela n’établit aucune forme numérique pour l’activation ou la désactivation. Cette opération administrative ne correspond ni à la disponibilité mesurée du gateway, ni à l’état actif d’un SD-WAN profile, ni à l’activation ou à la désactivation d’une route. Un message de réussite documenté ne prouve pas à lui seul qu’un changement d’état a effectivement eu lieu ; il faudrait vérifier l’état administratif de cet objet nommé précis, séparément des indicateurs de disponibilité.

SDWANPolicyRouteStatus : vérifier la bonne route et le bon état

SDWANPolicyRouteStatus utilise SDWANPolicyRouteName comme sélecteur obligatoire de type chaîne scalaire, et non le Name d’un profile de contrôle de disponibilité. Les exemples des deux versions montrent à nouveau ON/OFF pour Status, tandis que la ligne du champ obligatoire indique INTEGER sans fournir de correspondance numérique. Le code de résultat documenté 200 ne constitue pas une confirmation indépendante que la route souhaitée a changé d’état administratif. Il faudrait pour cela vérifier l’état On/Off réel de cette route. L’infobulle Active, la joignabilité du gateway et la décision de rejet ou de fallback régie par Route only through specified gateways répondent à d’autres questions et ne résolvent pas les contradictions du contrat XML relatif à l’état.

SDWANProfile : famille, stratégie et référence distincte au contrôle de disponibilité

Dans SDWANProfile, Name désigne le SD-WAN profile lui-même, avec un maximum de 60 caractères. En revanche, le champ obligatoire HealthCheckProfileName, de type chaîne scalaire, est la référence au profile de contrôle de disponibilité distinct, avec un maximum de 85 caractères. Il ne s’agit ni de la même identité ni de la même longueur de nom documentée que son champ Name, limité à 125 caractères. Les limites des objets et des compteurs de HealthCheckProfile s’appliquent donc également à la préparation de cette référence ; les paramètres intégrés de contrôle de disponibilité ne remplacent pas la référence nommée obligatoire.

Les deux exemples de profiles et les descriptions de champs indiquent IPv4/IPv6 pour IPFamily, mais la ligne de validation n’autorise que IPv4 et indique également un maximum de 1 caractère. Les routes IPv6 dans l’interface ne prouvent donc pas que ce contrat XML de profile prend en charge IPv6. Pour SLAStrategy, l’exemple et la description indiquent BestQuality, tandis que la liste des valeurs autorisées indique BestQualityv ; CustomSLA figure dans les deux. Pour LBMethod, l’exemple indique WRR/SrcSticky/DestSticky/SrcDestSticky/ConnectionSticky, alors que le tableau indique INTEGER dans une plage de 0 à 5, sans correspondance avec ces valeurs textuelles. Pour IsLatency, la valeur par défaut 1 s’oppose aux valeurs littérales autorisées OFF et ON. Aucune de ces différences n’est résolue par une correction typographique supposée, une forme numérique ou une correspondance booléenne déduite. Les stratégies et les procédures de vérification dans l’interface décrites plus haut restent utilisables, mais ne prouvent pas qu’une requête de profile est exécutable.

Exploitation et documentation

Pour chaque route SD-WAN en production, documenter son objectif, incoming interface, source/destination, services, gateway ou profile, fallback, comportement NAT attendu, client de test, destination de test, owner et date de révision. Après toute modification d’un fournisseur, VPN, interface ou service cloud, vérifier de nouveau la correspondance, les logs et le failover.

Une route n’est validée que lorsque :

  • les critères de correspondance n’incluent que le trafic prévu
  • la règle firewall, le NAT et la route precedence correspondent à la conception
  • Log Viewer et Packet Capture confirment le chemin attendu
  • le failover, le failback et la public source IP réagissent comme documenté
  • un responsable et la prochaine date de révision sont enregistrés