Modifier la route precedence de Sophos Firewall en toute sécurité

La route precedence détermine globalement si Sophos Firewall évalue d’abord les Static Routes, les SD-WAN Policy Routes ou les routes VPN. Cet ordre s’applique lorsque plusieurs catégories correspondent au même flux. Exception importante : vpn avant static ne supplante les routes statiques ou locales que pour les destinations de la zone WAN.

Pourquoi la route precedence est nécessaire

Sophos Firewall ne regroupe pas Static, SD-WAN et VPN dans une seule liste de routage. Il s’agit de catégories distinctes, et plusieurs catégories peuvent contenir simultanément un chemin correspondant vers la même destination. La route precedence détermine dans quelle catégorie le firewall recherche d’abord une route correspondante.

Exemple typique : un client du LAN doit atteindre le réseau distant 10.20.0.0/16 par un tunnel IPsec policy-based. En parallèle, une route SD-WAN avec la destination Any correspond également à ce trafic.

• Avec static sdwan_policyroute vpn, le firewall vérifie d’abord Static. S’il n’y trouve aucun chemin correspondant, la route SD-WAN générale correspond ensuite et le trafic peut partir vers le gateway WAN au lieu du tunnel VPN.
• Avec static vpn sdwan_policyroute, le firewall vérifie les routes VPN juste après Static. La route vers le réseau distant est alors prioritaire sur la route SD-WAN générale.

Remplacer le réseau d’exemple 10.20.0.0/16 par le réseau distant réel. La question n’est pas de savoir quel ordre semble généralement « meilleur », mais quel type de routage doit être prioritaire pour ce flux de paquets précis.

La route precedence ordonne uniquement les catégories. Elle ne modifie pas l’ordre des différentes Static Routes ou SD-WAN Routes au sein de leur catégorie. Avant de la modifier, répondre à trois questions :

1. Quel trafic précis emprunte actuellement le mauvais chemin ?
2. Lesquelles des trois catégories contiennent une route correspondante ?
3. Quelle catégorie doit être prioritaire pour ce trafic ?

Si une seule catégorie correspond, modifier la route precedence ne résout pas le problème. Il faut alors corriger la route concernée, la Policy SD-WAN, la configuration VPN, la règle NAT ou le chemin retour. La route precedence n’autorise pas non plus le trafic entre zones ; une règle firewall appropriée reste nécessaire.

Afficher et modifier directement la route precedence

Les commandes s’exécutent dans la Device Console, et non dans l’Advanced Shell. Après la connexion SSH, sélectionner l’option de menu 4. Si l’accès n’est pas encore configuré, voir Se connecter à Sophos Firewall par SSH.

Consigner d’abord l’ordre actuel complet afin d’en déduire la commande de rollback. La valeur par défaut actuelle de Sophos ne peut pas s’y substituer, car un firewall migré ou personnalisé peut partir d’un ordre différent.

⚠️ Important : La modification est globale. Avant la commande set, consigner l’ordre initial et s’assurer de disposer d’un accès de gestion indépendant. Un ordre inadapté peut affecter le trafic de production ainsi que les accès WebAdmin et SSH.

L’exemple suivant place Static en premier, VPN en deuxième et SD-WAN en dernier :

system route_precedence show
system route_precedence set static vpn sdwan_policyroute
system route_precedence show

La première commande affiche l’ordre actuel, la deuxième le modifie et la troisième contrôle le résultat. La position des valeurs détermine leur priorité. La sortie finale doit afficher static, vpn, sdwan_policyroute exactement dans cet ordre ; tester ensuite le flux réel.

L’ordre par défaut actuel de Sophos est :

system route_precedence set static sdwan_policyroute vpn

Cette commande ne constitue un rollback que si system route_precedence show affichait exactement cet ordre avant la modification.

WebAdmin affiche également l’ordre actuel sous Routing > SD-WAN routes, mais la modification n’est possible que depuis la Device Console.

Signification de Static, SD-WAN et VPN

Les trois valeurs représentent des catégories de routage et non des routes individuelles :

• static comprend les réseaux directement connectés, les Unicast Routes, les Dynamic Routes et SSL VPN.
• sdwan_policyroute comprend les Policy Routes configurées sous Routing > SD-WAN routes.
• vpn comprend les routes IPsec policy-based créées automatiquement. Sous SFOS 22.0, cette catégorie comprend également les routes définies avec ipsec_route.

Les routes IPsec policy-based et les entrées ipsec_route ne figurent pas dans la table de routage de WebAdmin. Lors de l’analyse, tenir aussi compte de la configuration VPN et des routes créées dans la Device Console. Le guide sur les routes IPsec de Sophos Firewall explique la classification complète.

SSL VPN appartient à static, et non à vpn. L’IPsec route-based via des interfaces XFRM est piloté par la route statique, dynamique ou SD-WAN configurée. L’interface XFRM, la route et son Administrative Distance sont déterminantes, pas seulement la position de vpn. Si aucune route ne correspond, WAN Link Manager fournit la route par défaut.

Static, SD-WAN, VPN

system route_precedence set static sdwan_policyroute vpn

Il s’agit de l’ordre par défaut et du bon point de départ pour de nombreux environnements. Il empêche les routes SD-WAN trop larges de supplanter les réseaux directement connectés, LAN, DMZ, VLAN et SSL VPN.

Static, VPN, SD-WAN

system route_precedence set static vpn sdwan_policyroute

Cet ordre conserve Static en première position, évalue ensuite les routes VPN et utilise SD-WAN en dernier. Il convient lorsque les chemins statiques et directement connectés doivent conserver leur priorité tandis qu’une route VPN policy-based concurrente doit être vérifiée avant SD-WAN. Sophos l’utilise aussi pour le failover VPN route-based avec deux connexions Internet et le MTA avec plusieurs connexions WAN.

SD-WAN, Static, VPN

system route_precedence set sdwan_policyroute static vpn

Cette variante ne convient que si le Policy Routing doit volontairement être prioritaire sur les routes statiques. Une prudence particulière s’impose lorsqu’une route SD-WAN a pour destination Any : elle peut aussi inclure les réseaux internes ou l’accès de gestion et envoyer ce trafic vers le gateway WAN. Une route SD-WAN doit donc utiliser des destinations aussi précises que possible et être testée.

VPN, Static, SD-WAN

system route_precedence set vpn static sdwan_policyroute

Placer VPN en premier est une exception ciblée, et non une solution générale aux problèmes IPsec. Pour L2TP Remote Access, vpn doit être en tête ; static et sdwan_policyroute peuvent ensuite apparaître dans l’un ou l’autre ordre. Toutefois, vpn avant static ne donne la priorité au VPN sur Static que lorsque la route statique concurrente pointe vers la zone WAN. Pour les destinations situées dans d’autres zones, le firewall continue d’utiliser la route statique ou locale.

L’architecture policy-based qui achemine le trafic Internet d’une agence via le siège exige elle aussi précisément cet ordre. Elle combine des sélecteurs Any, une règle VPN-to-WAN, MASQ et un choix distinct pour le trafic généré par le système.

Modifier la route precedence en sécurité

Avant une modification en production, préparer la commande et le flux de paquets concerné :

1. Enregistrer l’ordre actuel complet avec system route_precedence show et préparer la commande de rollback à partir de cette sortie.
2. Identifier la source, la destination, le service, la zone et les interfaces impliquées. Vérifier les Static Routes, SD-WAN Routes, routes VPN et interfaces XFRM qui couvrent des destinations concurrentes.
3. Tester un chemin indépendant vers le firewall, par exemple une console locale, une interface de gestion séparée ou un chemin administratif non concerné.
4. Modifier uniquement la route precedence. Ne pas changer simultanément les règles NAT, firewall, VPN et SD-WAN afin que la cause et l’effet restent identifiables.

Si SD-WAN intervient, vérifier également s’il est activé pour le trafic généré par le système ou les reply packets :

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

Ces options ne modifient pas l’ordre. Elles étendent le trafic auquel les SD-WAN Routes s’appliquent : le routage des Reply Packets ne s’applique pas si l’aller a uniquement utilisé la route par défaut de WAN Link Manager. Pour le trafic généré par le système, utiliser seulement les réseaux de destination et services, car Incoming Interface et Source Network sont inconnus. Au moins un gateway de WAN Link Manager doit être Active ; des gateways uniquement en Backup ne suffisent pas. Le trafic RED généré par le système sur UDP 3410 reste hors du routage SD-WAN, car il relève de Layer 2. Vérifier le routage SD-WAN Sophos Firewall pour Reply Packets et System Traffic fournit les détails.

Après la commande set, confirmer d’abord l’ordre avec system route_precedence show. Tester ensuite le cas d’utilisation concret :

• Tester l’application, la connexion TCP ou le ping vers la destination.
• Vérifier Route Lookup, Log Viewer et, si nécessaire, Packet Capture.
• Contrôler le NAT et le chemin retour du système distant.
• Tester WebAdmin et SSH depuis les réseaux de gestion concernés.

Un statut VPN vert ou une route existante ne prouvent pas que le flux de paquets fonctionne. Les contrôles pratiques sont décrits dans Tester une règle Sophos Firewall avec Log Viewer et Packet Capture et Utiliser Packet Capture dans Sophos Firewall WebAdmin.

Rollback

Pour le rollback, rétablir exactement l’ordre initial consigné avant la modification :

system route_precedence set <erster Wert> <zweiter Wert> <dritter Wert>

Remplacer les trois placeholders. L’état précédent ne peut pas être déduit de la première valeur seule, car six ordres sont possibles. Répéter ensuite system route_precedence show ainsi que les mêmes tests fonctionnels et de gestion.

Si la modification ne résout pas le problème

• Un seul réseau de destination est concerné : Une route statique plus spécifique, une route SD-WAN plus étroite ou une configuration VPN corrigée sont généralement plus précises qu’une modification globale.
• Le tunnel VPN est vert, mais le trafic emprunte le mauvais chemin : Pour l’IPsec route-based, vérifier d’abord l’interface XFRM et la route. Pour l’IPsec policy-based, contrôler aussi les Traffic Selectors et le traitement de ipsec_route selon la version. Suivre le guide de dépannage VPN IPsec.
• Le chemin aller est correct, mais pas le chemin retour : Le routage détermine le chemin, tandis que le NAT modifie l’adresse source ou destination. Vérifier la route retour et la configuration NAT.
• Un firewall migré affiche un ordre inattendu : La sortie de system route_precedence show fait foi, et non la valeur par défaut actuelle. Les routes SD-WAN migrées peuvent aussi rester liées à leur règle firewall d’origine et disparaître si cette règle est supprimée.
• WebAdmin ou SSH n’est plus accessible après une modification SD-WAN : Trois conditions sont souvent réunies : SD-WAN précède Static, une route SD-WAN correspondante utilise Any, et System Traffic ou Reply Packets sont activés pour SD-WAN. Restaurer l’ordre initial par le chemin de gestion préparé et restreindre la route SD-WAN.
• Une requête SSL VPN atteint la destination interne, mais la réponse ne revient pas au client : SSL VPN appartient à static. Si SD-WAN la précède, une route SD-WAN trop large peut détourner du tunnel la réponse destinée à la plage d’adresses. Restreindre précisément la route ; la procédure complète figure dans Configurer et tester l’accès distant SSL VPN.

FAQ