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. L’ordre se lit de gauche à droite : le premier type de routage qui correspond est prioritaire.

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.

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.

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 confirme le résultat. Une commande set contient toujours les trois valeurs. Leur position détermine l’ordre ; aucun numéro n’est ajouté.

⚠️ Important : La modification prend effet immédiatement et globalement. Avant d’exécuter la commande set, consigner l’ordre initial complet et vérifier un chemin de gestion indépendant. Un ordre incorrect peut affecter le trafic de production ainsi que les accès WebAdmin et SSH.

La commande suivante restaure l’ordre par défaut de Sophos :

system route_precedence set static sdwan_policyroute vpn

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.

La version SFOS est importante pour ipsec_route : sous SFOS 21.5, cette commande appartient à la catégorie static, tandis que sous SFOS 22.0 elle appartient à vpn. Le guide sur les routes IPsec de Sophos Firewall explique la classification complète.

SSL VPN appartient toujours à static, et non à vpn. L’IPsec route-based via des interfaces XFRM est piloté par la route statique, dynamique ou SD-WAN configurée. Dans ce cas, l’interface XFRM, la route et sa distance administrative sont déterminantes, et pas seulement la position de vpn.

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 rester prioritaires, mais qu’une route VPN policy-based concurrente doit être vérifiée avant SD-WAN. Sophos utilise également cet ordre dans des scénarios documentés de failover VPN route-based et de 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. Sophos exige par exemple cet ordre pour l’accès distant L2TP. 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.

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 font pas partie de la route precedence, mais elles peuvent amplifier son effet. Vérifier le routage SD-WAN Sophos Firewall pour reply packets et system traffic les explique en détail.

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 <première valeur> <deuxième valeur> <troisième valeur>

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.

FAQ