Changez le Sophos Firewall Route Precedence en toute sécurité

Le Route Precedence du Sophos Firewall détermine l’ordre dans lequel les différents types d’itinéraire sont pris en compte lors de la sélection de l’itinéraire. Cela semble être un petit ajustement, mais cela peut avoir un impact immédiat sur un trafic productif. Cela est particulièrement pertinent lorsque les routes statiques, les routes de stratégie SD-WAN et les routes VPN se chevauchent.

L’article explique quand une modification est logique, quand vous devez d’abord vérifier les autres causes et comment documenter correctement la modification à l’aide du Device Console, la tester et l’annuler si nécessaire. Si vous souhaitez d’abord planifier ou tester un itinéraire SD-WAN normal, Configuration et test de l’itinéraire SD-WAN Sophos Firewall convient.

Quand Route Precedence est important

Route Precedence devient important lorsque plusieurs mécanismes de routage correspondent théoriquement à la même destination. Le pare-feu doit alors décider quel type de routage est évalué en premier.

Situations typiques :

Un réseau cible interne peut être atteint via une route statique et en plus via une route politique SD-WAN.
Un IPsec VPN basé sur un itinéraire utilise des interfaces XFRM et est simultanément influencé par les règles SD-WAN.
Un cas spécial IPsec basé sur des politiques fonctionne avec les routes IPsec manuelles.
Le trafic généré par le système ou les paquets de réponse empruntent un itinéraire inattendu après une modification SD-WAN.
Après une mise à niveau ou une migration du firmware, les routes existantes se comportent différemment que prévu.

Pour les cas particuliers IPsec, Route Precedence n’est pas automatiquement la meilleure solution. Souvent, il faut d’abord comprendre s’il s’agit d’un problème de routage classique, d’une route IPsec, d’une règle SD-WAN, d’un NAT ou d’une règle de pare-feu.

Exigences

Sophos Firewall en mode Passerelle.
Accès au Device Console, par exemple via SSH.
Documentation actuelle des routes statiques concernées, des routes de politique SD-WAN et des connexions VPN.
Fenêtre de maintenance ou au moins un chemin de repli lorsque le trafic productif peut être affecté.
Accès au Log Viewer et, si nécessaire, au Packet Capture.

Si l’accès à la console n’est pas encore configuré, Connecter Sophos Firewall via SSH explique comment accéder au Device Console. SSH ne doit être autorisé qu’à partir de réseaux de confiance.

⚠️ Important : Une modification du Route Precedence a un effet global. Ce n’est pas seulement un tunnel ou une route unique qui est affecté, mais l’ordre des types de routage sur le pare-feu. Par conséquent, vous ne devez jamais effectuer plusieurs modifications de routage, NAT et SD-WAN en même temps.

Ordre par défaut

La documentation actuelle décrit l’ordre standard suivant :

Statique
SD-WAN
VPN

Les valeurs du Device Console sont :

static
sdwan_policyroute
vpn

Important : les connexions SSL VPN appartiennent à la catégorie static. Ceci est particulièrement pertinent lorsque le trafic d’accès à distance, les routes statiques et les règles SD-WAN sont considérés ensemble.

Également important : les réseaux directement connectés sont traités comme des routes statiques dans ce contexte. Si sdwan_policyroute se trouve devant static et qu’un itinéraire SD-WAN avec une destination très large comme Any fonctionne, le trafic interne peut soudainement se diriger vers la passerelle WAN. C’est exactement pourquoi le static est le point de départ sûr dans de nombreux environnements avant le sdwan_policyroute.

Quelle commande est correcte ?

Il n’existe pas d’ordre unique pour chaque conception. Le Route Precedence doit s’adapter au modèle de routage.

Chemins Internet normaux LAN, DMZ, VLAN, accès à distance et SD-WAN: static sdwan_policyroute vpn Les réseaux directement connectés et les routes statiques ne doivent pas être remplacés par de larges routes SD-WAN.
IPsec basé sur des règles chevauche des routes statiques ou SD-WAN: vpn static sdwan_policyroute À utiliser uniquement si les réseaux VPN doivent réellement être évalués en premier. Vérifiez ensuite le NAT, les règles de pare-feu et le chemin de retour.
Le basculement IPsec ou WAN basé sur l’itinéraire est délibérément contrôlé via SD-WAN: dépendant de la conception, souvent avec SD-WAN avant un autre type de routage Testez l’interface XFRM, les critères SD-WAN, l’état de la passerelle, NAT et Route Precedence ensemble.
MTA, routage spécial ou scénarios pratiques Sophos individuels: selon scénario testé Ne copiez pas aveuglément un exemple. Vérifiez toujours les réseaux locaux et les itinéraires de retour.

Si un exemple Sophos montre un ordre différent, cela ne constitue pas automatiquement une nouvelle norme. De nombreux exemples résolvent un problème concret et particulier. Ce qui compte pour un pare-feu productif, c’est de savoir quels réseaux source et cible sont réellement en concurrence.

Limite avant changement

Route Precedence ne doit pas être la première réaction lorsqu’un réseau cible ne peut pas être atteint. Vous devez d’abord affiner le flux de paquets concerné.

Vérifiez :

Quelles sources et destinations sont concernées ?
Quelle zone et quelle interface sont concernées ?
Existe-t-il un itinéraire statique approprié ?
Existe-t-il un itinéraire politique SD-WAN plus large que prévu ?
Une route VPN ou une interface XFRM est-elle impliquée ?
NAT ou MASQ s’appliquent-ils ?
La règle de pare-feu attendue est-elle respectée dans le Log Viewer ?
Packet Capture affiche-t-il le chemin d’entrée et de sortie attendu ?

Règle de test Sophos Firewall avec Log Viewer et Packet Capture et Sophos Firewall utilise Packet Capture dans WebAdmin aident à l’examen pratique. Pour les questions NAT, Comprendre NAT sur Sophos Firewall convient.

Afficher le Route Precedence actuel

Les commandes sont exécutées dans le Device Console, pas dans le Advanced Shell.

Afficher la commande en cours :

system route_precedence show

Le résultat doit être documenté avant tout changement. Il est préférable de noter également la date, la raison, les réseaux concernés et le comportement attendu. Si une restauration est nécessaire, cet ordre exact doit être à nouveau défini.

Dans le WebAdmin, vous pouvez également voir le Route Precedence actuel sous :

Routing > SD-WAN routes

Là, il sera affiché dans la zone de conseil d’itinéraire. L’ordre est modifié via le Device Console.

Route Precedence changement

La syntaxe est :

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

L’ordre des trois valeurs détermine la priorité. Un exemple typique place les routes statiques devant les routes de stratégie SD-WAN et les routes VPN :

system route_precedence set static sdwan_policyroute vpn

Si cette commande est déjà active, le problème ne vient probablement pas de Route Precedence. Ensuite, vous devez spécifiquement vérifier la recherche d’itinéraire, les itinéraires de politique SD-WAN, la configuration IPsec, le NAT, les règles de pare-feu et les itinéraires de retour.

Un autre exemple place les routes de stratégie SD-WAN avant les routes statiques :

system route_precedence set sdwan_policyroute static vpn
```Cela peut être intentionnel dans certaines conceptions SD-WAN, mais cela s'avère risqué lorsque les règles larges du SD-WAN fonctionnent avec le `Any` ou avec de vastes zones de réseau. Dans de tels cas, l'accès à la gestion, les réseaux internes ou les paquets de retour peuvent être acheminés de manière inattendue via SD-WAN. L'article [Sophos Firewall SD-WAN Vérifier le routage des paquets de réponse et du trafic système](/fr/kb/sophos-firewall-sd-wan-routing-reply-packet-system-traffic/) explique ces interactions plus en détail.

Pour les cas particuliers IPsec basés sur des politiques, `vpn` peut également être nécessaire en premier lieu :

```shell
system route_precedence set vpn static sdwan_policyroute

Cela ne doit être effectué que si les routes statiques ou SD-WAN remplacent les réseaux IPsec distants. Avec IPsec basé sur l’itinéraire avec

Tester le changement

Après ajustement, vérifiez d’abord la nouvelle commande :

system route_precedence show

Testez ensuite spécifiquement le trafic concerné. Un statut vert VPN ou un itinéraire existant ne constitue pas une preuve suffisante.

Vérifiez :

Connexion au réseau cible avec ping, test TCP ou test applicatif.
Filtrer Log Viewer sur la source, la destination et la règle de pare-feu.
Exécutez Packet Capture sur l’interface d’entrée et de sortie.
Vérifiez la recherche d’itinéraire ou la règle SD-WAN concernée.
Vérifiez la règle NAT et l’adresse IP source traduite.
Vérifiez le chemin de retour de la station distante.
Testez l’accès à la gestion des WebAdmin et SSH à partir des réseaux d’administration concernés.

Si plusieurs emplacements sont concernés, vous ne devez pas simplement vérifier un seul client de test. Il est préférable d’avoir au moins un client par réseau concerné, un serveur cible et un accès distant ou un test VPN si ces chemins sont concernés par le changement.

Restauration

Un rollback ne consiste pas en une valeur par défaut conseillée, mais en un ordre préalablement documenté.

Exemple :

system route_precedence set static sdwan_policyroute vpn

ou :

system route_precedence set sdwan_policyroute static vpn

Vérifiez à nouveau après la restauration :

system route_precedence show

Répétez ensuite les mêmes tests qu’après le changement. Si cela provoque le retour de l’erreur d’origine, cela indique fortement que le Route Precedence est effectivement impliqué. Si rien ne change, la cause est probablement ailleurs.

Erreurs courantes

La règle SD-WAN est trop large

Si un itinéraire stratégique SD-WAN correspond à des sources ou des destinations très larges, il peut capter plus de trafic que prévu. Ceci est particulièrement dangereux si SD-WAN est prioritaire sur static. L’accès à la gestion ou les réseaux cibles internes peuvent alors s’exécuter de manière inattendue via une route WAN.

Modèle typique :

Route Precedence est sur sdwan_policyroute static vpn.
Un itinéraire SD-WAN utilise Any comme destination.
Le trafic généré par le système ou les paquets de réponse sont également évalués via SD-WAN.

L’accès à WebAdmin ou SSH depuis un sous-réseau interne peut alors être perdu, même si le pare-feu reste accessible depuis d’autres réseaux.

Le statut VPN est confondu avec le routage

Un tunnel IPsec actif prouve uniquement que le tunnel a été négocié. Cela ne prouve pas que le pare-feu achemine le trafic vers le tunnel, que le NAT est correct ou que la station distante connaît le chemin du retour.

Avec IPsec basé sur des stratégies, il est particulièrement important que les routes statiques ou SD-WAN s’adaptent également aux sous-réseaux distants. Si oui, vpn static sdwan_policyroute peut être nécessaire. Pour le IPsec basé sur la route, vous devez d’abord vérifier l’interface XFRM, la route, la route SD-WAN et les règles de pare-feu.

NAT est négligé

Le routage décide où un paquet est envoyé. NAT décide si l’adresse source ou de destination est modifiée. Si une route est correcte mais que la route de retour ne fonctionne pas, le NAT ou la route de retour est souvent impliqué.

Plusieurs changements à la fois

Si les règles Route Precedence, SD-WAN, NAT, les règles de pare-feu et les paramètres VPN sont modifiés en même temps, l’effet peut difficilement être clairement attribué. Il est préférable d’effectuer une modification, puis de tester, puis d’effectuer la modification suivante.

Liste de contrôle

Route Precedence actuel documenté avec system route_precedence show.
Sources, destinations, réseaux et services concernés notés.
Routes statiques, routes politiques SD-WAN et routes VPN vérifiées.
Prise en compte des réseaux directement connectés et des chemins de gestion internes.
Larges itinéraires SD-WAN identifiés avec Any.
Règles NAT et pare-feu vérifiées.
Fenêtre de maintenance ou chemin de repli défini.
Changer l’ensemble avec la commande exacte.
Après modification Log Viewer, Packet Capture et test d’application effectué.
Accès à la gestion des réseaux d’administration vérifié.
Ordre de restauration documenté.

FAQ

Quelle est la priorité de routage par défaut du Sophos Firewall ?

L’ordre par défaut est static, sdwan_policyroute, vpn. Il devient visible avec system route_precedence show.

Où pouvez-vous voir la priorité des itinéraires dans WebAdmin ?

Dans WebAdmin, vous pouvez voir le Route Precedence actuel sous Routing > SD-WAN routes dans la zone d’avis de routage. Il est modifié via le Device Console avec le system route_precedence.

Le VPN SSL fait-il partie du VPN ou est-il statique ?

Sophos attribue les connexions SSL VPN à la catégorie static. Ceci est important lors de la vérification conjointe du trafic d’accès à distance et des règles SD-WAN.

Devez-vous ajuster la priorité de routage pour chaque VPN ?

Non. Route Precedence est un classement global des types de routage. Pour les cas particuliers IPsec basés sur des stratégies individuelles, une [route IPsec] ciblée (/fr/kb/comment-creer-une-route-ipsec-sur-le-sophos-firewall/) ou une règle SD-WAN/routage propre est souvent préférable à un changement global.

Pourquoi le tunnel fonctionne-t-il mais pas de circulation ?

Parce que l’état du tunnel, le routage, le NAT, les règles de pare-feu et le chemin de retour sont des choses différentes. Un tunnel peut être connecté tout en ayant un trafic mal géré par Route Precedence, NAT ou des règles de pare-feu. Pour une analyse systématique, Sophos Firewall IPsec VPN Dépannage convient.

Le SD-WAN doit-il toujours passer avant le statique ?

Non, cela dépend de la conception. SD-WAN avant Static peut être utile si le routage de politique doit être consciemment priorisé. Cependant, il peut également enregistrer de manière incorrecte l’accès à la gestion ou les réseaux internes si les règles SD-WAN sont trop larges. Ceci est particulièrement critique avec les paquets de réponse ou le trafic généré par le système.