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 que Sophos Firewall produit lui-même. Selon l’environnement, il peut s’agir de requêtes DNS, de téléchargements de signatures, de requêtes d’authentification, de DHCP, de NTP, de Syslog ou de connexions à Sophos Central. Par défaut, ce trafic utilise les Gateways WAN actifs configurés 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 par conséquent limiter précisément uniquement 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. 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.

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.

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

Pour le trafic transféré, vérifiez les événements associés au pare-feu et au SD-WAN dans Log viewer. Log firewall traffic doit être activé pour les Firewall Rules concernées. En revanche, une Firewall Rule ne contrôle pas le trafic généré par le système. Sous Current activities > Live connections, vous pouvez l’identifier grâce à la Firewall Rule ID 0 ainsi qu’aux interfaces Inbound et Outbound.

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 l’utilisation et l’interprétation de cet outil, consultez Utiliser Packet Capture dans WebAdmin de Sophos Firewall.

Vérifier les services système

Pour le trafic généré par le système, testez spécifiquement le service concerné :

• DNS : effectuez une recherche DNS sur le pare-feu et vérifiez le chemin vers la destination.
• NTP : contrôlez l’état de l’heure et l’accessibilité du serveur NTP.
• Syslog : vérifiez un message de test ou une entrée récente sur le collecteur.
• Sophos Central : contrôlez la connexion à Central et les rapports.
• Monitoring : vérifiez SNMP, sFlow ou les contrôles externes sur le collecteur.

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. Si MASQ ou différentes adresses source traduites sont utilisées, un Failover ou un Rerouting peut interrompre la communication. 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. Désactivez temporairement les SD-WAN Routes trop larges ou limitez-les à des destinations précises.
4. Testez l’accès d’administration depuis un réseau non concerné.
5. 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