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

La route precedence détermine si Sophos Firewall évalue d’abord les Static Routes, les SD-WAN Policy Routes ou les routes VPN. Ce réglage est global et peut affecter immédiatement le trafic de production ainsi que l’accès administratif.

Réponse courte

L’ordre par défaut est le suivant :

1. static
2. sdwan_policyroute
3. vpn

Cet ordre convient à de nombreux environnements, car les réseaux directement connectés et les routes statiques ne peuvent pas être supplantés par une route SD-WAN trop large. Il ne faut le modifier que si plusieurs types de routage sont en concurrence vers la même destination dans le flux de paquets concerné.

Avant toute modification, documenter l’ordre actuel, garantir un accès de gestion indépendant, vérifier les routes concernées et préparer le rollback exact. Une route SD-WAN classique est expliquée dans Configurer et tester une route SD-WAN sur Sophos Firewall.

Quel ordre choisir ?

Ordre par défaut et différence entre les versions

L’ordre par défaut est identique sous SFOS 21.5 et 22.0. En revanche, la classification de ipsec_route a changé :

• SFOS 21.5 : static comprend les réseaux directement connectés, ipsec_route, les Unicast Routes, les Dynamic Routes et SSL VPN. Les routes IPsec policy-based créées automatiquement appartiennent à vpn.
• SFOS 22.0 : static comprend les réseaux directement connectés, les Unicast Routes, les Dynamic Routes et SSL VPN. vpn comprend les routes IPsec policy-based créées automatiquement et ipsec_route.

C’est important lors d’une mise à niveau : Une recommandation concernant ipsec_route sous SFOS 21.5 ne doit pas être reprise telle quelle sous SFOS 22.0. Sous SFOS 22.0, le firewall traite les routes IPsec policy-based en interne. Les routes VPN policy-based créées automatiquement et celles définies avec ipsec_route ne sont pas visibles dans la table de routage. ipsec_route n’est pas nécessaire pour le trafic généré par le système. Une route IPsec manuelle n’est utile que dans le cas particulier adapté à la version.

Sur les firewalls migrés, c’est la sortie réelle qui compte, et non la valeur par défaut documentée. Une migration peut par exemple conserver sdwan_policyroute vpn static. Les routes SD-WAN migrées peuvent également rester liées à l’ID de leur règle firewall d’origine et disparaître lorsque cette règle est supprimée.

Static en premier

static sdwan_policyroute vpn est généralement le bon point de départ pour LAN, DMZ, VLAN, SSL VPN et les chemins Internet SD-WAN classiques. Les réseaux directement connectés sont traités comme des routes statiques.

Cela protège les destinations internes des routes SD-WAN trop larges. Si sdwan_policyroute précède static et qu’une route SD-WAN utilise une destination telle que Any, le trafic interne ou administratif peut être envoyé de manière inattendue vers le gateway WAN.

SD-WAN en premier

sdwan_policyroute static vpn convient lorsque le policy routing doit volontairement être prioritaire sur les routes statiques. Cela doit être planifié avec des sources, destinations et services précis. Les routes SD-WAN ne s’appliquent aux reply packets et au trafic généré par le système que si les options CLI correspondantes sont activées.

Vérifier le routage SD-WAN Sophos Firewall pour reply packets et system traffic explique ces deux options en détail.

VPN en premier

vpn static sdwan_policyroute est une exception ciblée, par exemple pour les scénarios L2TP documentés. La priorité de vpn sur static ne s’applique qu’au trafic dont la route concurrente pointe vers la zone WAN. Ce n’est pas une solution universelle pour chaque tunnel IPsec.

Les connexions SSL VPN appartiennent à la catégorie static, et non à vpn. L’IPsec route-based via des interfaces XFRM est piloté par la route statique, dynamique ou SD-WAN configurée à cet effet. L’interface XFRM, la route, les critères SD-WAN, le NAT, la règle firewall et le chemin retour sont donc déterminants.

Une modification globale ne convient pas lorsqu’un seul réseau de destination est mal routé. Une route statique ou SD-WAN plus spécifique, la configuration VPN ou un ipsec_route adapté à la version constitue généralement un levier plus précis.

Préparer la modification en sécurité

Les commandes s’exécutent dans la Device Console, et non dans l’Advanced Shell. Si l’accès n’est pas encore configuré, voir Se connecter à Sophos Firewall par SSH. SSH ne doit être autorisé que depuis des réseaux de confiance.

Préparation :

1. Garantir et tester activement un chemin indépendant vers le firewall avant la modification, par exemple une console locale, une interface de gestion dédiée ou un chemin administratif confirmé comme non concerné.
2. Noter la source, la destination, le service, la zone et les interfaces impliquées.
3. Vérifier les routes statiques, les SD-WAN Policy Routes, les routes VPN et les interfaces XFRM.
4. Identifier les routes SD-WAN larges avec Any ainsi que les règles migrées.
5. Vérifier le NAT, la règle firewall et le chemin retour du système distant.
6. Définir la fenêtre de maintenance, le test de validation et le rollback.

⚠️ Important : La route precedence est globale. Ne pas modifier simultanément les règles de routage, NAT, firewall et SD-WAN, sinon l’effet ne peut plus être attribué de manière fiable.

Afficher l’ordre actuel et le documenter exactement :

system route_precedence show

Consigner la sortie complète avec la date, le motif, les réseaux concernés et le comportement attendu. Préparer avant la modification le rollback exact à partir des trois valeurs.

L’ordre actuel est également visible ici dans WebAdmin :

Routing > SD-WAN routes

La modification s’effectue dans la Device Console. Si SD-WAN est impliqué, relever aussi au préalable l’état du trafic généré par le système et des reply packets :

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

Ces valeurs ne doivent pas être confondues avec l’effet de la route precedence. Une combinaison particulièrement critique existe lorsque sdwan_policyroute précède static, qu’une route SD-WAN correspondante utilise la destination Any et que SD-WAN est activé à la fois pour le trafic généré par le système et les reply packets. WebAdmin et SSH peuvent alors devenir inaccessibles depuis le sous-réseau interne concerné, tandis que le firewall reste éventuellement accessible depuis d’autres sous-réseaux.

Modifier la route precedence

La syntaxe contient toujours les trois valeurs :

system route_precedence set [sdwan_policyroute] [static] [vpn]

Définir l’ordre par défaut :

system route_precedence set static sdwan_policyroute vpn

Si cet ordre est déjà actif, l’erreur se trouve probablement dans le route lookup, les critères SD-WAN, la configuration VPN, le NAT, la règle firewall ou le chemin retour.

⚠️ Avant SD-WAN-First : Vérifier si des routes SD-WAN larges incluent des réseaux internes ou l’accès de gestion. Exécuter la commande uniquement avec un chemin de récupération préparé.

Évaluer les SD-WAN Policy Routes en premier :

system route_precedence set sdwan_policyroute static vpn

⚠️ Avant VPN-First : Utiliser cet ordre uniquement pour un cas particulier VPN confirmé. Il ne corrige pas une route manquante, des traffic selectors incorrects, le NAT ou les problèmes de chemin retour.

Évaluer les routes VPN en premier :

system route_precedence set vpn static sdwan_policyroute

Tester et annuler la modification

Après la modification, confirmer d’abord que l’ordre attendu est actif :

system route_precedence show

Tester ensuite le flux de paquets concerné :

• Tester l’application, la connexion TCP ou le ping vers la destination.
• Filtrer Log Viewer selon la source, la destination et la règle firewall.
• Effectuer un Packet Capture sur les interfaces d’entrée et de sortie.
• Vérifier le route lookup et la route SD-WAN concernée.
• Vérifier le NAT et l’adresse source traduite.
• Confirmer le chemin retour du système distant.
• Tester WebAdmin et SSH depuis les réseaux administratifs concernés.

Un statut VPN vert ou une route existante ne prouve pas qu’un flux de paquets fonctionne. Les étapes pratiques sont décrites dans Tester une règle Sophos Firewall avec Log Viewer et Packet Capture et Utiliser Packet Capture dans Sophos Firewall WebAdmin.

Si plusieurs sites ou chemins de routage sont concernés, tester au moins un client par réseau pertinent, une destination serveur ainsi que les chemins Remote Access ou VPN affectés.

Pour le rollback, définir exclusivement l’ordre initial complet précédemment documenté. Il ne peut pas être déduit de la première valeur seule, car six combinaisons sont possibles. Utiliser la commande préparée selon ce modèle :

system route_precedence set <première valeur> <deuxième valeur> <troisième valeur>

Remplacer les placeholders par les trois valeurs de la sortie enregistrée auparavant. Vérifier ensuite à nouveau :

system route_precedence show

Répéter ensuite les mêmes tests fonctionnels, de routage et de gestion. Si l’erreur d’origine revient après le rollback, la route precedence était probablement impliquée. Si rien ne change, la cause se trouve ailleurs.

Erreurs fréquentes

La route SD-WAN est trop large

Une route SD-WAN avec de grandes plages réseau ou la destination Any peut inclure plus de trafic que prévu. Si SD-WAN précède Static, les destinations internes et les accès de gestion peuvent être envoyés de manière inattendue vers le gateway WAN. Les reply packets et le trafic généré par le système sont concernés lorsque les options SD-WAN correspondantes sont activées.

Le statut VPN est confondu avec le routage

Un tunnel actif confirme uniquement la réussite de la négociation. Il ne prouve pas que le routage, les traffic selectors, les règles firewall, le NAT et le chemin retour sont corrects. Pour l’IPsec route-based, vérifier d’abord l’interface XFRM et la route ; pour l’IPsec policy-based, vérifier aussi le traitement de ipsec_route selon la version. Dépannage VPN IPsec Sophos Firewall guide systématiquement l’analyse.

Le NAT est oublié

Le routage détermine le chemin du paquet, tandis que le NAT modifie son adresse source ou destination. Si la route est correcte mais que le retour échoue, le NAT ou la route retour est souvent en cause. Voir Comprendre le NAT sur Sophos Firewall.

Plusieurs modifications sont effectuées simultanément

Modifier simultanément la route precedence, SD-WAN, le NAT, les règles firewall et les paramètres VPN empêche de distinguer clairement la cause de l’effet. Il vaut mieux effectuer une modification, réaliser un test complet, puis passer à la suivante.

Liste de contrôle

• Route precedence actuelle documentée.
• Version SFOS et classification de ipsec_route prises en compte.
• Sources, destinations, réseaux et services concernés notés.
• Static, SD-WAN, VPN et XFRM vérifiés.
• Réseaux directement connectés et chemins de gestion pris en compte.
• Routes SD-WAN larges avec Any identifiées.
• État du trafic système et des reply packets relevé.
• NAT, règles firewall et chemin retour vérifiés.
• Accès de gestion indépendant et rollback préparés.
• Modification effectuée isolément.
• Application, Log Viewer, Packet Capture et accès de gestion testés.

FAQ