Sophos Firewall : vérifier le routage SD-WAN des Reply Packets et du System Traffic

Les SD-WAN Routes de Sophos Firewall ne concernent pas uniquement le trafic classique des clients vers Internet. Selon l’environnement, les Reply Packets et le trafic généré par le système peuvent également être concernés. C’est précisément dans ces situations que surviennent des problèmes de routage difficiles à identifier : la règle semble correcte et le Gateway est actif, mais les réponses empruntent le mauvais chemin ou le pare-feu lui-même n’atteint pas un service par la liaison prévue.

Ce guide explique les deux options CLI reply-packet et system-generate-traffic, quand les vérifier et comment tester les modifications en toute sécurité. Pour créer une route SD-WAN classique, commencez par Configurer et tester une route SD-WAN sur Sophos Firewall. Pour comprendre l’ordre général entre les routes statiques, les SD-WAN Policy Routes et les routes VPN, consultez également Modifier la Route Precedence de Sophos Firewall en toute sécurité.

⚠️ Ces paramètres peuvent avoir un effet immédiat sur le routage en production. Avant toute modification, documentez l’état actuel, prévoyez une fenêtre de maintenance et définissez une procédure de retour claire. Les SD-WAN Routes étendues utilisant Any, une Route Precedence qui place SD-WAN avant Static Routes et l’activation du routage SD-WAN pour System Traffic ou Reply Packets sont particulièrement critiques.

Principes et limites

Rôle des deux options

Avec les SD-WAN Routes, il faut distinguer le trafic transféré normal, les paquets de réponse et le trafic généré par le pare-feu lui-même. Les deux options ne déterminent pas si une SD-WAN Route particulière est correctement configurée. Elles étendent les types de trafic susceptibles d’être pris en compte par le SD-WAN Policy Routing.

Les deux options remplissent des fonctions différentes :

• reply-packet : concerne les paquets de réponse associés à un trafic existant. Elle permet d’influencer le chemin retour via SD-WAN dans certains scénarios hors WAN.
• system-generate-traffic : concerne le trafic généré par le pare-feu lui-même. Elle permet d’acheminer les connexions propres au pare-feu via des SD-WAN Routes définies.

N’activez pas ces deux options sans analyse sous prétexte que « le SD-WAN ne fonctionne pas ». Il faut d’abord déterminer si le problème concerne réellement des Reply Packets ou du trafic généré par le système. Pour les connexions normales, la cause est souvent une Firewall Rule, le NAT, la Route Precedence, l’état du Gateway ou une SD-WAN Route trop large.

Reply Packets

Les Reply Packets sont les paquets de réponse associés à un trafic existant. Sur les interfaces WAN, Sophos Firewall impose généralement un routage symétrique pour ces réponses : elles doivent repartir par la même interface WAN que celle sur laquelle la connexion initiale est arrivée.

L’option reply-packet est surtout pertinente lorsque les paquets de réponse doivent être pris en compte par le SD-WAN Policy Routing dans certains scénarios. Le routage asymétrique sur des interfaces autres que WAN, par exemple entre LAN et DMZ, constitue un cas typique.

Une restriction importante s’applique : si le trafic initial passe par la Default Route ou le WAN Link Load Balancing, les SD-WAN Routes ne s’appliquent pas à ces Reply Packets. Le pare-feu continue alors d’utiliser le chemin retour correspondant à l’interface de la connexion initiale.

Questions à se poser :

• S’agit-il réellement d’un trafic de réponse et non d’une nouvelle connexion ?
• Le trafic passe-t-il par WAN, LAN, DMZ, XFRM ou une autre zone ?
• Existe-t-il une SD-WAN Route destinée à influencer volontairement le chemin retour ?
• La route est-elle trop large, par exemple avec Destination Any ?
• La Route Precedence fait-elle passer cette route avant une route statique ou VPN ?

Trafic généré par le système

Le trafic généré par le système est le trafic produit par Sophos Firewall lui-même. Il comprend par exemple les requêtes DNS, les téléchargements de signatures et les requêtes d’authentification. Pour des services tels que DHCP, SNMP ou Syslog, la classification dépend du rôle et du sens du trafic : tout trafic destiné à un service du pare-feu n’est pas nécessairement une connexion sortante générée par le système. Par défaut, le pare-feu envoie son propre trafic via les Gateways WAN sous Network > WAN link manager.

Pour ce trafic, Incoming interface et Source networks ne sont pas connus et ne constituent donc pas des sélecteurs adaptés. Une SD-WAN Route destinée au trafic du pare-feu doit donc être limitée précisément au moyen de Destination networks et Services ; les autres critères restent larges. Une route avec Destination Any peut sinon détourner de manière inattendue le trafic système et de gestion vers le mauvais chemin.

Une Firewall Rule normale n’est pas nécessaire. Dans Current activities > Live connections, le trafic généré par le système porte donc la Firewall Rule ID 0. La Local service ACL sous Administration > Device access reste distincte : elle contrôle l’accès aux services locaux du pare-feu, et non le choix du chemin SD-WAN sortant. Si une Source IP particulière est requise, une règle SNAT normale ne suffit pas non plus : les règles NAT traduisent le trafic transféré, tandis que le trafic du pare-feu peut nécessiter sys-traffic-nat dans la Device Console, selon le scénario.

Deux limites pratiques supplémentaires s’appliquent :

• Si tous les Gateways configurés sous Network > WAN link manager sont uniquement définis comme Backup, le pare-feu n’y achemine pas le trafic généré par le système. Au moins un Gateway doit être Active.
• Le trafic RED généré par le système sur UDP 3410 est un trafic de couche 2. Les SD-WAN Routes ne s’y appliquent pas.

Atteindre un serveur d’authentification via IPsec route-based

Un cas particulier important concerne un serveur AD ou LDAP du siège que le pare-feu d’une succursale doit lui-même atteindre via un tunnel IPsec route-based. Une règle LAN vers VPN normale ne dirige pas cette requête, car le trafic est généré par le pare-feu. Avec un tunnel any-to-any et des interfaces XFRM adressées, les chemins aller et retour doivent donc être planifiés explicitement.

L’exemple suivant utilise 10.10.1.1 comme adresse source visible du pare-feu de la succursale, 10.10.2.15 comme serveur AD et TCP 636 pour LDAPS. Ces valeurs ne sont pas des paramètres par défaut du produit. Elles doivent être remplacées par une adresse de succursale autorisée dans le tunnel et routée en retour au siège, le serveur réel et le service d’authentification réellement configuré.

1. Sur le pare-feu de la succursale, créer une SD-WAN Route ciblée avec Source networks défini sur Any, l’hôte AD comme Destination networks et le service d’authentification requis. TCP 636 ne convient que si le serveur utilise réellement LDAPS. La Primary Gateway est l’adresse XFRM distante via l’interface XFRM locale.
2. Activer Route only through specified gateways uniquement si la requête doit volontairement être rejetée lorsque le tunnel est indisponible. Vérifier le commutateur du trafic généré par le système comme décrit plus haut et l’activer de manière contrôlée pour ce processus.
3. Dans la Device Console, utiliser d’abord show advanced-firewall pour consigner les entrées sys-traffic-nat existantes et leur ordre. Traduire ensuite l’adresse source propre au pare-feu vers l’adresse prévue pour la succursale. Cette adresse doit correspondre aux règles du tunnel et du chemin retour :

set advanced-firewall sys-traffic-nat add destination 10.10.2.15 snatip 10.10.1.1

4. Sur le pare-feu du siège, créer une SD-WAN Route de retour de l’hôte AD vers l’adresse traduite de la succursale via l’adresse XFRM distante. La source, la destination et le service restent aussi ciblés que du côté de la succursale.
5. Au siège, créer des règles journalisées de VPN vers le réseau du serveur et du réseau du serveur vers VPN, avec les hôtes et services précis. Les exemples larges utilisant Any dans les instructions du produit ne conviennent pas comme état permanent.
6. Ping/Ping6 sous Administration > Device access pour la zone VPN n’est nécessaire que si la cible de la sonde est une adresse locale du pare-feu ou une adresse XFRM. Pour tester un hôte situé derrière le tunnel, il faut plutôt disposer du tunnel et de la route appropriés ainsi que, si nécessaire, d’une Firewall Rule. Après le test, rétablir toute autorisation temporaire de Device Access dans son état antérieur.

Pour la validation, déclencher un véritable test de connexion au serveur et une connexion utilisateur. Sur le pare-feu de la succursale, le trafic généré par le système apparaît sous Current activities > Live connections avec la Firewall Rule ID 0 ; au siège, les règles journalisées attendues doivent correspondre. Packet Capture doit montrer la requête et la réponse sur les interfaces XFRM prévues. Un ping réussi ne confirme à lui seul ni LDAPS, ni l’authentification, ni le chemin de retour.

Pour le rollback, vérifier d’abord si les deux SD-WAN Routes, les règles, les objets Gateway et toute autorisation Ping/Ping6 temporaire ont d’autres dépendances. Supprimer l’entrée NAT avec exactement les mêmes sélecteurs ; si les sélecteurs netmask, interface ou les deux ont également été utilisés lors de sa création, les inclure aussi dans la commande de suppression :

set advanced-firewall sys-traffic-nat delete destination 10.10.2.15 snatip 10.10.1.1

Vérifier ensuite avec show advanced-firewall que seule l’entrée prévue a disparu. Supprimer uniquement les routes, règles et objets créés pour cette procédure, rétablir les valeurs antérieures documentées des deux options SD-WAN globales et de la Route Precedence, puis tester de nouveau le chemin de données d’origine.

Préparation

Quand vérifier ces paramètres

Ces deux options sont surtout pertinentes dans les architectures de routage complexes. Dans un environnement simple avec une seule liaison WAN, elles constituent rarement le premier levier à actionner.

Situations justifiant une vérification :

• Le trafic propre au pare-feu n’emprunte pas le chemin WAN ou VPN attendu.
• Syslog, Central, DNS, NTP ou le monitoring doit passer par une liaison précise.
• Un Route-based IPsec VPN avec des interfaces XFRM est utilisé avec des SD-WAN Routes.
• La VoIP ou un autre trafic sensible ne fonctionne que dans un sens via SD-WAN/VPN.
• Packet Capture montre que les réponses passent par une autre interface que prévu.
• Après une mise à niveau, le comportement du SD-WAN, d’IPsec ou du NAT a changé.
• Une SD-WAN Route étendue affecte soudainement les réseaux internes ou l’accès d’administration.

Pour les scénarios IPsec, consultez également Dépanner un VPN IPsec sur Sophos Firewall. Pour analyser une connexion particulière, Tester une règle Sophos Firewall avec Log Viewer et Packet Capture constitue souvent un meilleur point de départ.

Afficher l’état actuel

Les commandes s’exécutent dans la Device Console, et non dans l’Advanced Shell. Si l’accès à la console n’est pas encore configuré, consultez Se connecter à Sophos Firewall par SSH.

Vérifier l’état des Reply Packets :

show routing sd-wan-policy-route reply-packet

Vérifier l’état du trafic généré par le système :

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

Dans WebAdmin, l’info-bulle relative au routage sous Routing > SD-WAN routes indique également si le routage SD-WAN est actif pour le trafic généré par le système et les Reply Packets.

Documentez aussi la Route Precedence actuelle :

system route_precedence show

Avant chaque modification, consignez la sortie actuelle. Un rollback ultérieur ne peut être effectué proprement que si l’état précédent est connu.

Sous Routing > SD-WAN routes, il faut également savoir comment chaque route concernée réagit à une panne de Gateway. Avec Route only through specified gateways, le pare-feu rejette le trafic si les Gateways indiqués sont indisponibles. Sans cette option, il examine les SD-WAN Routes suivantes, puis WAN Link Load Balancing. Si le Primary Gateway sélectionné ou le SD-WAN Profile est supprimé, SFOS supprime également la route ; si seul le Backup Gateway est supprimé, la route reste en place avec None comme Backup.

Modifier la configuration

Activer ou désactiver les options

Activer le routage SD-WAN pour les Reply Packets :

set routing sd-wan-policy-route reply-packet enable

Activer le routage SD-WAN pour le trafic généré par le système :

set routing sd-wan-policy-route system-generate-traffic enable

Exécutez ensuite à nouveau les commandes d’état et consignez leur sortie.

Pour désactiver précisément ces fonctions, utilisez les commandes inverses :

set routing sd-wan-policy-route reply-packet disable
set routing sd-wan-policy-route system-generate-traffic disable

⚠️ N’effectuez pas plusieurs modifications de routage simultanément. Si vous changez en même temps la Route Precedence, la SD-WAN Route, la règle NAT et ces options CLI, il devient presque impossible d’attribuer clairement un dysfonctionnement à sa cause.

Procédure de modification sécurisée

Une procédure pragmatique réduit le risque :

1. Définissez précisément le trafic concerné : Source, Destination, Service, Zone et Gateway attendu.
2. Documentez les SD-WAN Routes, les Gateways et la Route Precedence existants.
3. Vérifiez si Destination Any est réellement nécessaire.
4. Consignez l’état actuel de reply-packet et system-generate-traffic.
5. Ne modifiez qu’une seule option.
6. Effectuez un test avec un exemple de trafic clairement défini.
7. Vérifiez Log Viewer, Packet Capture et les compteurs OUT/IN de la SD-WAN Route.
8. Documentez le résultat avant toute autre modification.

Si l’accès d’administration peut être affecté, prévoyez une deuxième méthode d’accès : console locale, autre chemin interne ou accès depuis un réseau d’administration non concerné.

Validation après la modification

Après l’activation, un Gateway affiché en vert ne suffit pas. Il faut vérifier que le trafic visé emprunte réellement le chemin attendu.

Live Connections, Log Viewer et compteurs SD-WAN

Avant le test, vérifier sous System services > Log settings si la journalisation SD-WAN est active. Les entrées apparaissent dans le module SD-WAN de Log viewer ; pour le trafic transféré, Log firewall traffic doit également être activé sur la Firewall Rule concernée. Consigner l’état antérieur de la journalisation et le rétablir après le test si elle n’a été activée que temporairement.

Le trafic généré par le système n’est pas contrôlé par une Firewall Rule. Sous Current activities > Live connections, il est identifiable grâce à la Firewall Rule ID 0 et aux interfaces Inbound et Outbound. La Local service ACL reste un mécanisme distinct qui contrôle l’accès aux services locaux du pare-feu.

Points à vérifier :

• S’agit-il de trafic transféré avec une Firewall Rule ID ou de trafic système avec l’ID 0 ?
• Quelle NAT Rule ID est utilisée pour le trafic transféré ?
• Quel Gateway ou quelle interface apparaît dans le journal ?
• Observe-t-on des Drops, des violations de Policy ou des décisions inattendues d’une Security Feature ?
• La SD-WAN Route affiche-t-elle uniquement OUT pour les Requests, ou également IN pour les Replies ? Les compteurs ne s’incrémentent que si les critères Source et Destination correspondent à la direction concernée.

Packet Capture

Diagnostics > Packet capture permet d’observer le flux réel des paquets. Pour un problème de routage, utilisez un filtre précis : Source IP, Destination IP, Port et Protocol.

Comparez les points suivants :

• Le paquet arrive-t-il sur l’interface attendue ?
• Quitte-t-il le pare-feu par l’interface attendue ?
• La réponse revient-elle ?
• Le NAT est-il appliqué ?
• Le chemin retour des Reply Packets est-il plausible ?
• Pour les requêtes émises par le pare-feu, Status indique-t-il Generated et, le cas échéant, Consumed pour les réponses remises au pare-feu ?
• Les valeurs Gateway ID, NAT ID ainsi que les interfaces Inbound et Outbound correspondent-elles au chemin prévu ?

Pour l’utilisation et l’interprétation de cet outil, consultez Utiliser Packet Capture dans WebAdmin de Sophos Firewall.

Vérifier le service système concerné

La correspondance avec une route ne prouve pas à elle seule que le service fonctionne. Avant le test, consigner l’adresse IP de destination, le port, la Source IP attendue et l’interface Outbound prévue. Déclencher ensuite précisément la fonction à tester, par exemple une requête d’authentification ou une recherche DNS depuis le pare-feu, puis vérifier à la fois Packet Capture et le trafic ou l’événement correspondant sur le système distant. Utiliser comme test négatif une destination ou un service qui ne correspond pas aux critères de la route ; ce trafic ne doit pas emprunter la route précisément définie.

Si le trafic généré par le système n’apparaît pas, vérifiez si la route impose inutilement des critères tels que Source networks, Incoming interface, un utilisateur ou une application. Pour le trafic propre au pare-feu, la décision doit principalement reposer sur Destination networks et Services. Si le système distant attend une adresse source particulière, vérifiez également la Source IP et une éventuelle configuration sys-traffic-nat.

Erreurs et dépendances

Erreurs fréquentes

• SD-WAN Route avec Destination Any pour des chemins internes : le trafic interne ou l’accès d’administration peut être routé via WAN. Préférez des groupes de destinations Internet ou des réseaux de destination précis.
• Route Precedence plaçant SD-WAN avant Static : les réseaux directement connectés ou statiques peuvent être sélectionnés de manière inattendue par SD-WAN. Vérifiez la Route Precedence et placez Static avant SD-WAN si nécessaire.
• system-generate-traffic actif sans limitation de destination : les services du pare-feu peuvent emprunter le mauvais chemin. Limitez donc précisément les réseaux de destination et les Services.
• Reply Packets confondus avec de nouvelles connexions normales : l’analyse porte alors sur la mauvaise cause. Vérifiez Packet Capture et le sens du flux.
• Recherche d’une Firewall Rule pour le trafic généré par le système : ce trafic porte la Firewall Rule ID 0 et n’est pas contrôlé par les Firewall Rules normales. Vérifiez la route, le service, Live Connection et, si nécessaire, sys-traffic-nat.
• Direct Web Proxy traité comme du trafic HTTP/HTTPS normal : avec le proxy direct, la SD-WAN Route doit couvrir le port configuré sous Web > General settings > Web proxy listening port. Vous pouvez aussi définir Services sur Any. Source Network et Incoming Interface ne correspondent pas aux Reply Packets du trafic proxy ; le chemin retour nécessite au moins un WAN-Gateway ou une route statique adaptée.
• Plusieurs modifications de routage simultanées : la cause du problème reste indéterminée. Procédez étape par étape et documentez chaque test.
• Aucun accès d’administration alternatif : WebAdmin ou SSH peut devenir inaccessible depuis le réseau concerné. Préparez la fenêtre de maintenance et le chemin d’accès de secours.

Le risque est particulièrement élevé lorsque plusieurs conditions se cumulent : la Route Precedence place SD-WAN avant Static, une SD-WAN Route étendue utilise Any et le routage SD-WAN est actif pour le trafic généré par le système ou les Reply Packets. Dans ce cas, l’accès à WebAdmin ou SSH peut être perdu depuis certains sous-réseaux internes.

Interaction avec NAT, IPsec et VoIP

Le SD-WAN est rarement le seul composant en cause. Le NAT, IPsec ou le trafic propre à une application intervient dans de nombreux dysfonctionnements.

Pour le SNAT, il faut déterminer si la même adresse source est conservée sur les différents Gateways. Lire l’état actuel dans la Device Console avec show routing reroute-connection et show routing reroute-snat-connection. SFOS peut rerouter des connexions après une panne de Gateway, mais les connexions SNAT doivent conserver la même adresse source traduite sur les deux chemins. MASQ ou des adresses traduites différentes peuvent interrompre une communication active lors du rerouting. Dans cet article, ces deux valeurs sont uniquement consultées, jamais modifiées. Pour les principes de base, consultez Comprendre le NAT sur Sophos Firewall.

Avec les Route-based IPsec VPNs, les interfaces XFRM peuvent être utilisées dans les SD-WAN Routes ou les SD-WAN Profiles. Il faut alors vérifier conjointement l’état IPsec, la SD-WAN Route, la Route Precedence et les Firewall Rules. Les principes des VPN basés sur des routes sont présentés dans Configurer une route IPsec sur Sophos Firewall.

Pour les problèmes de VoIP, vérifiez également SIP, RTP, NAT et SD-WAN. Les notes de version de SFOS 22.0 MR1 documentent la correction d’un problème qui, après une mise à niveau vers SFOS 22.0 GA, limitait l’audio VoIP à un seul sens via un Route-based VPN avec SD-WAN Routing. La procédure pratique est décrite dans Résoudre les problèmes VoIP liés à SIP et RTP sur Sophos Firewall.

Rollback et finalisation

Rollback

L’état précédent doit être documenté avant la modification. Si l’accès d’administration, les services système ou le trafic de production sont ensuite affectés, n’improvisez pas davantage. Rétablissez d’abord l’état antérieur.

Concrètement :

1. Rétablissez les valeurs précédemment consignées pour reply-packet et system-generate-traffic à l’aide des commandes enable ou disable correspondantes.
2. Rétablissez l’ordre antérieur de la Route Precedence si celui-ci a été modifié.
3. Rétablissez les SD-WAN Routes modifiées à leurs valeurs antérieures documentées ; après vérification des dépendances, supprimez les routes créées uniquement pour le test.
4. Supprimez les entrées sys-traffic-nat temporaires avec exactement les mêmes sélecteurs et vérifiez avec show advanced-firewall.
5. Rétablissez les Firewall Rules, les objets Gateway, les autorisations Device Access et les paramètres de journalisation modifiés uniquement pour le test.
6. Testez l’accès d’administration et le chemin de données d’origine depuis un réseau non concerné.
7. Poursuivez seulement ensuite l’analyse de la cause réelle.

Si WebAdmin et SSH deviennent inaccessibles depuis un sous-réseau interne mais restent disponibles depuis un autre, utilisez ce dernier pour vérifier en priorité la SD-WAN Route étendue, la Route Precedence et les deux options CLI.

Liste de contrôle

• État actuel des deux options CLI documenté.
• Route Precedence documentée avec system route_precedence show.
• Trafic concerné défini précisément.
• Pour le trafic système, seuls Destination et Service sont utilisés comme critères de correspondance décisifs.
• SD-WAN Route non configurée inutilement de manière étendue avec Any.
• Route Precedence vérifiée.
• Au moins un WAN-Gateway Active disponible pour System Traffic.
• Connexion d’administration alternative préparée.
• Une seule modification effectuée par test.
• Log Viewer et Packet Capture utilisés pour la validation.
• NAT, IPsec et Firewall Rules également vérifiés.
• Résultat et rollback consignés dans le journal d’exploitation.

FAQ