Sophos Firewall SD-WAN Vérifier le routage pour Reply Packets et System Traffic

SD-WAN Les routes sur Sophos Firewall ne sont pas uniquement pertinentes pour le trafic client vers Internet classique. Selon l’environnement, Reply Packets et le trafic généré par le système peuvent également être affectés. C’est précisément là que surviennent souvent des problèmes de routage difficiles à détecter : la règle semble correcte, le Gateway est actif, mais les réponses passent par le mauvais chemin ou le pare-feu lui-même n’atteint pas un service via la ligne attendue.

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 la configuration normale de l’itinéraire SD-WAN, Configurer et tester l’itinéraire et tester Sophos Firewall SD-WAN convient en premier. Pour l’ordre général entre les routes statiques, les routes de stratégie SD-WAN et les routes VPN, Sophos Firewall modifie en toute sécurité Route Precedence convient également.

⚠️ Ces paramètres peuvent affecter immédiatement le routage productif. Avant d’effectuer une modification, vous devez documenter l’état actuel, choisir une fenêtre de maintenance et connaître un chemin de retour clair. Les routes SD-WAN larges avec Any, Route Precedence devant les routes statiques et le routage SD-WAN activé pour System Traffic ou Reply Packets sont particulièrement critiques.

De quoi parlent les deux options

Avec SD-WAN Routes, vous devez faire la différence entre 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 un seul itinéraire SD-WAN est construit correctement. Au lieu de cela, ils élargissent le type de trafic qui peut être pris en compte par le routage de stratégie SD-WAN.

Les deux options ont des tâches différentes :

• reply-packet : affecte les paquets de réponse au trafic existant. Cela permet d’influencer le chemin de retour via SD-WAN dans certains scénarios non-WAN.
• system-generate-traffic : Affecte le trafic généré par le pare-feu lui-même. Cela permet aux connexions spécifiques au pare-feu d’être acheminées via des routes SD-WAN définies.

Les deux options ne doivent pas être activées aveuglément simplement parce que « SD-WAN ne fonctionne pas ». Il faut d’abord savoir clairement si le trafic Reply Packets ou le trafic généré par le système est réellement affecté. Pour les connexions normales, la cause réelle est souvent la règle de pare-feu, l’état NAT, Route Precedence, Gateway ou une route SD-WAN trop large.

Reply Packets

Reply Packets sont des paquets de réponse au trafic existant. Sophos Firewall applique généralement un routage symétrique pour de telles réponses sur les interfaces WAN : les paquets de réponse doivent revenir via la même interface WAN par laquelle la connexion d’origine est arrivée. L’option reply-packet est particulièrement pertinente si les paquets de réponse doivent être pris en compte dans certains scénarios de routage de stratégie SD-WAN. Un exemple typique est le routage asymétrique sur des interfaces non WAN, par exemple entre LAN et DMZ.

La restriction importante est la suivante : si le trafic d’origine s’exécute via la route par défaut ou l’équilibrage de charge de lien WAN, les routes SD-WAN ne s’appliquent pas à ce Reply Packets. Le pare-feu continue alors d’utiliser le chemin de retour approprié via l’interface de la connexion d’origine.

Questions de test typiques :

• S’agit-il vraiment 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 un itinéraire SD-WAN destiné à influencer intentionnellement l’itinéraire de retour ?
• L’itinéraire est-il trop large, par exemple destination Any ?
• Route Precedence prend-il effet avant une route statique ou une route VPN ?

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

Le trafic généré par le système est le trafic que le Sophos Firewall génère lui-même. Selon l’environnement, cela peut inclure DNS, NTP, Sophos Central, Syslog, des mises à jour, une surveillance, des services d’authentification ou des connexions de diagnostic.

Avec ce trafic, le pare-feu ne reconnaît pas une interface entrante normale ni un réseau source normal comme avec le trafic client transféré. C’est pourquoi vous devez planifier les itinéraires SD-WAN particulièrement étroitement pour le trafic généré par le système : les réseaux cibles et Services doivent être choisis judicieusement. Un itinéraire très large peut autrement entraîner de manière inattendue le trafic de gestion ou du système sur une mauvaise voie.

De plus, deux limites pratiques s’appliquent :

• Si toutes les passerelles configurées sous Network > WAN link manager sont marquées comme Sauvegarde uniquement, le pare-feu ne transmettra pas le trafic généré par le système via elles. Au moins un Gateway doit être Actif.
• Le trafic RED généré par le système sur UDP 3410 est un trafic de couche 2. Les itinéraires SD-WAN ne s’appliquent pas à cela.

Quand vérifier ces paramètres

Les deux options sont particulièrement pertinentes pour les conceptions de routage plus complexes. Dans les environnements WAN simples et uniques, ils constituent rarement le premier levier.

Déclencheurs utiles :

• Le trafic natif du pare-feu n’utilise pas le chemin WAN ou VPN attendu.
• Syslog, Central, DNS, NTP ou surveillance doivent fonctionner sur une ligne spécifique.
• IPsec VPN basé sur les routes avec interfaces XFRM est utilisé avec les routes SD-WAN.
• La VoIP ou tout autre trafic sensible ne fonctionne que dans un sens via SD-WAN/VPN.
• Packet Capture affiche les réponses sur une interface différente de celle attendue.
• Après une mise à niveau, SD-WAN, IPsec ou NAT se comporte différemment qu’avant.
• Une large route SD-WAN affecte soudainement les réseaux internes ou l’accès à la gestion. Pour les scénarios IPsec, vous devez également inclure Dépannage Sophos Firewall IPsec VPN. Pour les connexions individuelles, Test de règle Sophos Firewall avec Log Viewer et Packet Capture constitue souvent un meilleur point de départ.

Afficher l’état actuel

Les commandes sont exécutées dans le Device Console, pas dans le Advanced Shell. Si l’accès à la console n’est pas encore clair, Connecter Sophos Firewall via SSH vous aidera.

Vérifier l’état de Reply Packets :

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

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

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

De plus, le WebAdmin sous Routing > SD-WAN routes indique dans l’info-bulle des informations de routage si le routage SD-WAN est actif pour le trafic généré par le système et Reply Packets.

Avant d’apporter des modifications, l’édition actuelle doit être documentée. Ceci est important car une restauration ultérieure n’est possible proprement que si l’état précédent est connu.

Activer les options

SD-WAN Activer le routage pour Reply Packets :

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

SD-WAN Activer le routage 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 documentez la sortie.

⚠️ N’effectuez pas plusieurs modifications d’itinéraire en même temps. Si Route Precedence, la route SD-WAN, la règle NAT et ces options CLI sont modifiées en même temps, il est difficile d’attribuer clairement une erreur par la suite.

Flux sécurisé pour les modifications

Un processus pragmatique réduit le risque :

1. Définissez spécifiquement le trafic affecté : Source, Destination, Service, Zone, Gateway attendu.
2. Documentez les routes, passerelles et Route Precedence existants.
3. Vérifiez si la destination Any est vraiment nécessaire.
4. Documentez l’état actuel de reply-packet et system-generate-traffic.
5. Modifiez une seule option.
6. Exécutez le test avec un exemple de trafic clair.
7. Vérifiez les compteurs Log Viewer, Packet Capture et Gateway.
8. Documentez le résultat et effectuez ensuite d’autres ajustements. Si l’accès à la gestion peut être affecté, un moyen d’accès secondaire doit être disponible : console locale, autre chemin d’accès interne ou accès à partir d’un réseau de gestion non affecté.

Validation après changement

Après l’activation, un statut vert Gateway ne suffit pas. Il faut vérifier si le trafic souhaité emprunte réellement le chemin attendu.

Journaux Log Viewer et SD-WAN

Les événements liés au pare-feu et à SD-WAN doivent être vérifiés dans la Visionneuse de journaux. Pour les règles de pare-feu pertinentes, Log firewall traffic doit être actif. Sans journalisation, vous ne voyez souvent qu’une partie de la décision.

Pour vérifier :

• Quel Firewall Rule ID est touché ?
• Quel NAT Rule ID est utilisé ?
• Quel Gateway ou quelle interface apparaît dans le log ?
• Y a-t-il des baisses, des violations de politique ou des décisions inattendues en matière de fonctionnalités de sécurité ?

Packet Capture

Le flux de paquets réel peut être vérifié avec Diagnostics > Packet capture. Pour les questions de routage, le filtre doit être étroit : Source IP, Destination IP, Port et Protocole.

La comparaison est importante :

• Le colis arrive-t-il sur l’interface attendue ?
• Est-ce qu’il sort du pare-feu sur l’interface attendue ?
• La réponse reviendra-t-elle ?
• NAT est-il utilisé ?
• L’itinéraire retour est-il plausible pour Reply Packets ?

Utiliser Sophos Firewall Packet Capture dans WebAdmin convient au fonctionnement et à l’interprétation.

Vérifier les services système

Dans le cas de trafic généré par le système, vous devez spécifiquement tester le service concerné :

• DNS : Exécutez la recherche DNS sur le pare-feu et vérifiez le chemin cible.
• NTP : Vérifiez l’état horaire et la disponibilité du serveur NTP.
• Syslog : Vérifiez le message de test ou le journal actuel sur le collecteur.
• Sophos Central : Vérifiez la connexion centrale et les rapports.
• Surveillance : Vérifiez SNMP, sFlow ou contrôles externes sur le collecteur.

Si le trafic généré par le système n’est pas visible, vous devez également vérifier si la route SD-WAN doit correspondre uniquement aux réseaux sources ou aux interfaces entrantes. Ces critères ne sont pas disponibles pour le trafic appartenant au pare-feu, comme ils le sont pour le trafic client.

Erreurs typiques

• Route SD-WAN avec destination Any pour les chemins internes : Le trafic interne ou l’accès à la gestion peuvent être acheminés via WAN. Il est préférable de cibler des groupes cibles Internet ou des réseaux cibles spécifiques.
• Route Precedence définit SD-WAN avant Statique : Les réseaux directement connectés ou statiques peuvent être mis en correspondance de manière inattendue par SD-WAN. Vérifiez Route Precedence et définissez Statique devant SD-WAN si nécessaire.
• system-generate-traffic actif sans limitation de destination : Les services spécifiques au pare-feu peuvent utiliser le mauvais chemin. Par conséquent, définissez étroitement les réseaux cibles et Services.
• Reply Packets confondu avec de nouvelles connexions normales : La mauvaise cause est alors traitée. Packet Capture et vérifiez le sens du débit.
• Plusieurs changements de routage en même temps : La cause de l’erreur reste floue. Changez progressivement et documentez chaque test.
• Aucun accès de gestion alternatif : WebAdmin ou SSH peut être perdu du réseau concerné. Préparez la fenêtre de maintenance et le chemin d’accès.

Un risque particulièrement critique survient lorsque plusieurs conditions sont réunies : Route Precedence est sur SD-WAN avant le trafic statique, une route SD-WAN large utilise Any et le routage SD-WAN pour le trafic généré par le système ou Reply Packets est actif. Dans ce cas, l’accès à WebAdmin ou SSH depuis certains sous-réseaux internes peut être perdu.

Interaction avec NAT, IPsec et VoIP

SD-WAN est rarement impliqué seul. NAT, IPsec ou le trafic spécifique à l’application joue un rôle dans de nombreuses perturbations. Ce qui est important pour SNAT est de savoir si la même source IP est conservée sur différentes passerelles. Si MASQ ou différentes adresses source traduites sont utilisées, le basculement ou le reroutage peut entraîner des problèmes de communication. Pour les bases, Comprendre que NAT convient à Sophos Firewall.

Pour les VPN IPsec basés sur des routes, les interfaces XFRM peuvent être utilisées dans les routes SD-WAN ou les profils SD-WAN. Ensuite, l’état IPsec, l’itinéraire SD-WAN, Route Precedence et les règles de pare-feu doivent être vérifiés ensemble. Les bases de VPN basées sur les itinéraires sont classées dans Route IPsec sur Sophos Firewall. Si vous rencontrez des problèmes VoIP, cela vaut également la peine de consulter SIP, RTP, NAT et SD-WAN. Les notes de version SFOS-22.0-MR1 documentent un problème résolu où l’audio VoIP ne fonctionnait que dans un sens via VPN basé sur le routage avec le routage SD-WAN après la mise à niveau vers SFOS 22.0 GA. Le processus pratique peut être trouvé dans Sophos Firewall Résoudre les problèmes VoIP avec SIP et RTP.

Restauration

Avant d’apporter des modifications, l’ancien statut doit être documenté. Si l’accès à la gestion, les services système ou le trafic productif sont alors affectés, l’improvisation n’est plus nécessaire. Restaurez d’abord l’état précédent.

Concrètement, cela signifie :

1. Réinitialisez les valeurs documentées avant pour reply-packet et system-generate-traffic.
2. Remettez le Route Precedence à la commande précédente en cas de modification.
3. Désactivez temporairement les itinéraires SD-WAN trop larges ou limitez-les à des destinations spécifiques.
4. Testez l’accès à la gestion à partir d’un réseau non affecté.
5. Ensuite, affinez davantage la cause réelle.

Si l’accès à WebAdmin et SSH est perdu à partir d’un sous-réseau interne mais est toujours possible à partir d’un autre sous-réseau, la route large SD-WAN, Route Precedence et les deux options CLI doivent d’abord être vérifiées à partir de là.

Liste de contrôle

• État actuel des deux options CLI documenté.
• Trafic concerné spécifiquement défini.
• Route SD-WAN non construite inutilement large avec Any.
• Route Precedence vérifié.
• Au moins un WAN-Gateway pour System Traffic disponible en tant que Actif.
• Connexion de gestion alternative préparée.
• Un seul changement effectué par test.
• Log Viewer et Packet Capture utilisés pour la validation.
• NAT, IPsec et règles de pare-feu vérifiées.
• Résultat et rollback documentés dans le journal des opérations.

FAQ