Configurer et tester une route statique sur Sophos Firewall

Une route statique indique à Sophos Firewall par quel Next Hop fixe ou quelle interface de tunnel elle atteint une destination donnée. Elle convient lorsque le chemin est fixe et qu’aucune sélection selon la source, le service, l’application ou la qualité de la liaison n’est nécessaire.

Réponse courte

Une route IPv4 se crée ici :

Routing > Static routes > IPv4 unicast route > Add

Pour un réseau de destination 10.20.0.0/24, joignable via le routeur 192.0.2.2 sur Port4, renseigner :

Destination IP / Netmask: 10.20.0.0/24
Gateway IP: 192.0.2.2
Interface: Port4
Administrative distance: 1
Metric: 10
Description: Branch_10.20_via_Core

Le réseau de destination, le gateway et l’interface doivent correspondre à l’environnement concerné. Ne reprendre l’Administrative Distance et la Metric qu’après avoir contrôlé les routes existantes vers la même destination ; 1 et 10 ne sont que des exemples.

Vérifier ensuite la destination 10.20.0.10 sous Diagnostics > Tools > Route lookup. Si le résultat indique Port4, la décision de routage est correcte. La modification n’est entièrement validée que lorsqu’une connexion client réelle fonctionne et que la réponse revient.

Pour que le trafic fonctionne réellement, il faut également une règle firewall adaptée et une route de retour sur le système distant. Une route statique n’autorise aucun trafic et n’effectue pas automatiquement de NAT.

Comprendre l’exemple

L’exemple utilise l’architecture suivante :

Le réseau client derrière Sophos Firewall est 10.10.0.0/24.
Le client de test utilise l’adresse 10.10.0.10 dans ce réseau.
Port4 du firewall possède l’adresse de transit 192.0.2.1/30.
Le routeur suivant possède l’adresse 192.0.2.2 sur ce réseau.
Le réseau de destination 10.20.0.0/24 se trouve derrière ce routeur.
Le système de test utilise l’adresse 10.20.0.10.

La Destination est toujours la destination distante, et non le routeur suivant. Gateway IP est le Next Hop directement joignable qui transfère le paquet. Interface est le port ou l’interface de tunnel par lequel ce Next Hop est atteint.

La destination peut être un réseau ou un seul hôte. Si seul le système de test doit emprunter ce chemin, utiliser par exemple 10.20.0.10/32 pour IPv4 ou 2001:db8:20::10/128 pour IPv6 plutôt qu’un réseau entier. Un préfixe plus large couvre d’autres adresses de destination et ne doit être choisi que si elles sont également joignables via ce Next Hop. L’autorisation firewall reste indépendante.

L’adresse se saisit directement dans Gateway IP ; aucun objet gateway sous Routing > Gateways n’est nécessaire. Pour l’environnement concerné, il faut remplacer ensemble le réseau de destination, le gateway et l’interface. Si une seule adresse d’exemple est reprise, la route peut être enregistrée tout en pointant vers le mauvais réseau ou vers un routeur inaccessible. L’adresse IP du gateway doit appartenir au réseau de l’interface sélectionnée.

Si le chemin doit au contraire disposer de son propre Health Check ou pouvoir être sélectionné dans une SD-WAN Route, suivre la procédure dédiée aux Custom Gateways sur Sophos Firewall.

Les principes concernant les ports, les zones et les adresses d’interface sont expliqués dans Configurer les zones et interfaces Sophos Firewall.

Quand utiliser une route statique

Cet article traite des réseaux de destination unicast. Si un émetteur doit atteindre un groupe multicast via plusieurs interfaces, utiliser la procédure dédiée pour configurer le multicast avec une route multicast statique.

Le multicast envoie un seul flux à un groupe plutôt que des copies distinctes à chaque destinataire, par exemple pour la visioconférence, la formation ou la distribution de logiciels. Les destinataires doivent rejoindre le groupe ; les émetteurs, les destinataires et les routeurs concernés doivent prendre en charge le multicast. Les adresses de groupe IPv4 vont de 224.0.0.0 à 239.255.255.255, tandis que l’adresse source reste une adresse unicast. Il s’agit de la plage générale, et non d’une autorisation d’utiliser toutes ces destinations dans une route multicast statique. Sous Routing > Static routes, Enable multicast forwarding active le transfert. Manage multicast route permet l’ajout, la modification, la suppression et le filtrage par IP source, IP multicast, Source Interface ou Destination Interface. La procédure multicast liée explique les prérequis, la plage autorisée, le test sécurisé et le rollback.

Une route statique convient lorsqu’un réseau reste durablement joignable via le même Next Hop, par exemple :

un réseau d’agence derrière un core router interne
un réseau de serveurs derrière un switch de couche 3
un réseau derrière un tunnel RED
un réseau distant via l’interface XFRM d’un tunnel IPsec route-based

Si le firewall doit également décider selon la source, le service ou l’application, ou changer de chemin selon la latence, la gigue et la perte de paquets, une route SD-WAN est généralement plus adaptée. Dans les domaines de routage petits ou existants, RIPv2 peut échanger automatiquement des réseaux simples. Dans les réseaux plus vastes et fréquemment modifiés, OSPF ou BGP réduisent le travail de maintenance manuelle.

Configurer la route IPv4

Avant la modification, documenter le réseau de destination, le Next Hop, l’interface de sortie, la zone attendue, le chemin retour et un hôte de test joignable. Ensuite :

Ouvrir Routing > Static routes.
Sous IPv4 unicast route, cliquer sur Add.
Saisir 10.20.0.0/24 dans Destination IP / Netmask.
Saisir le routeur suivant 192.0.2.2 dans Gateway IP.
Sélectionner Port4 comme Interface.
Régler Administrative distance sur 1.
Saisir 10 dans Metric.
Ajouter une Description explicite telle que Branch_10.20_via_Core.
Enregistrer avec Save.

Pour cette route, Sophos Firewall tient d’abord compte de l’interface sélectionnée, puis du gateway. Si l’un de ces deux champs est incorrect, le Next Hop prévu n’est pas atteint. Dans la liste IPv4, il est possible de filtrer par adresse IP, Gateway IP, Interface ou Description, puis de modifier, cloner, supprimer, activer ou désactiver une route. La liste IPv6 permet de filtrer par adresse IP, Gateway IP ou Interface, puis d’ajouter, modifier ou supprimer une route.

Administrative Distance et Metric

L’Administrative Distance évalue les sources de routage concurrentes. Une valeur plus faible est prioritaire : une route avec 1 est préférée à une route avec 5.

Lorsque plusieurs routes statiques vers la même destination possèdent la même Administrative Distance, la Metric les départage. Là encore, la valeur la plus faible est prioritaire.

La Route Precedence globale entre Static, SD-WAN et VPN intervient à un autre niveau que l’Administrative Distance et la Metric. Elle ne doit pas être modifiée à la hâte pour une seule nouvelle route.

Les valeurs d’exemple 1 et 10 sont de simples valeurs de départ pour une route unique, et non une règle générale du produit. Avant de les reprendre, comparer les routes existantes vers la même destination. Pour un scénario Primary/Backup ou ECMP, choisir délibérément l’Administrative Distance et la Metric selon la priorité voulue.

Deux routes avec des valeurs d’Administrative Distance différentes peuvent définir un chemin préféré et un chemin secondaire. L’Administrative Distance et la Metric ne surveillent toutefois pas elles-mêmes le Next Hop. Pour un contrôle de disponibilité, utiliser un gateway surveillé dans une route SD-WAN. Pour sélectionner un chemin selon la latence, la gigue ou la perte de paquets, la route nécessite en plus un SD-WAN Profile avec Best quality ou Custom SLA.

Rendre l’IPsec Route-based redondant avec deux accès Internet présente un exemple complet avec deux opérateurs et deux tunnels XFRM Any-to-Any. Les gateways, les routes en miroir, Route Precedence, le Failover et le Failback y sont validés ensemble.

Pour l’ECMP IPv4, créer plusieurs routes vers la même destination avec la même Administrative Distance et la même Metric, mais des Next Hops différents. Les connexions peuvent ainsi être réparties entre plusieurs Next Hops de coût égal, sans créer de chemin Primary/Backup fondé sur la qualité.

Utiliser Blackhole de manière ciblée

Avec Blackhole, le firewall rejette le trafic vers la destination indiquée sans répondre à la source. Cette option peut être utile pour des réseaux volontairement bloqués ou agrégés, mais elle ne remplace pas un Next Hop normal.

Si des routes statiques sont redistribuées via RIP, OSPF ou BGP, il faut y filtrer explicitement les routes Blackhole. Sinon, le firewall peut également diffuser cette route de rejet vers d’autres routeurs.

Cas particuliers IPv6 et tunnels

Sous IPv6 unicast route, renseigner l’adresse de destination avec son préfixe, Gateway IP, Interface et Metric. Pour le formulaire IPv6, Sophos ne documente ni Administrative Distance, ni option Blackhole, ni description, ni fonction Clone, ni fonction d’activation ou de désactivation. Les réglages IPv4 ne doivent donc pas être repris tels quels pour IPv6.

Pour un réseau IPv6 routé normalement, procéder ainsi :

Sous Routing > Static routes > IPv6 unicast route, cliquer sur Add.
Saisir un réseau de destination tel que 2001:db8:20::/64.
Saisir 2001:db8:4::2 dans Gateway IP et sélectionner Port4 dans Interface.
Choisir une Metric telle que 10 après comparaison des routes existantes, puis enregistrer avec Save.

Cet exemple suppose 2001:db8:4::1/64 sur Port4 et un routeur directement joignable à l’adresse 2001:db8:4::2. Toutes les adresses IPv6 sont des valeurs de documentation : les remplacer ensemble par celles du plan d’adressage réel. Avant la modification, noter les anciennes valeurs des routes et garantir un accès de gestion indépendant. Ensuite, vérifier 2001:db8:20::10 avec Route lookup, une connexion client IPv6 réelle et Packet capture avec host 2001:db8:20::10 ; le trafic sortant et les réponses doivent suivre le chemin prévu. Une règle firewall IPv6 et une route de retour vers le réseau client sont également nécessaires. L’exception RED/ARP décrite ci-dessous ne prouve pas que ce mécanisme s’applique à IPv6 ; confirmer tout cas particulier RED IPv6 pour le build installé avant la modification.

Avec un tunnel IPsec route-based utilisant des Any-to-Any-Subnets, la route peut pointer directement vers l’interface XFRM sans nécessiter de gateway distinct. Si le tunnel utilise des Traffic Selectors précis, SFOS crée automatiquement la route ; aucune adresse IP propre ni route supplémentaire n’est alors configurée sur l’interface XFRM. Une route XFRM n’est pas non plus le cas particulier CLI ipsec_route, qui dépend de la version ; Créer une route IPsec sur Sophos Firewall explique cette distinction.

Pour un réseau situé derrière l’interface du pair d’un tunnel RED Site-to-Site entre deux Sophos Firewall, une autre exception s’applique : saisir comme gateway l’adresse IP de l’interface RED du pair, sans sélectionner d’interface. Le firewall peut ainsi déterminer l’interface joignable via ARP. Configurer Site-to-Site RED entre deux Sophos Firewall explique l’architecture complète du serveur et du client.

Règle firewall, NAT et chemin retour

Le routage détermine le chemin. La règle firewall décide si le paquet peut passer et le NAT modifie ses adresses si nécessaire. Ces trois fonctions se configurent séparément.

Pour cet exemple, il faut une règle du réseau client 10.10.0.0/24 vers le réseau de destination 10.20.0.0/24. La Destination Zone correspond à la zone de Port4. Limiter la règle aux services réellement nécessaires et activer le logging pour le test.

Sur un réseau de site routé normalement, le SNAT n’est généralement pas souhaité, car le système distant doit voir l’adresse IP réelle du client. Le routeur 192.0.2.2 nécessite alors cette route de retour :

Réseau de destination: 10.10.0.0/24
Next Hop: 192.0.2.1

Si aucune route de retour ne peut être configurée sur le système distant, le SNAT peut techniquement aider. Il masque toutefois l’adresse IP d’origine du client et doit rester une décision de conception consciente. Comprendre le NAT sur Sophos Firewall explique ces interactions.

Routes statiques via l’API XML : champs et limites de modification

Pour automatiser les routes statiques, il faut distinguer les champs XML sous UnicastRoute des libellés de l’interface. Les tableaux des paramètres de l’API pour SFOS 22.0 et 23.0 documentent les éléments suivants :

Distance désigne la Metric, et non l’Administrative Distance : facultatif, valeur par défaut 0, plage 0–255.
AdministrativeDistance désigne l’Administrative Distance : facultatif, valeur par défaut 1, plage 1–255.

Ces valeurs par défaut de l’API ne constituent ni une recommandation pour la route présentée ci-dessus, ni une preuve que les champs omis restent inchangés lors d’une mise à jour. La priorité souhaitée doit toujours être comparée à celle des routes existantes.

L’exemple XML contient également OldConfiguration, avec les anciens champs de destination, de gateway, d’interface et de priorité. Toutefois, le tableau des paramètres ne décrit pas ce bloc. L’exemple ne prouve donc ni quels champs servent à identifier la route à modifier, ni quelles anciennes valeurs sont obligatoires, ni si les modifications concurrentes sont détectées ou font l’objet d’une comparaison atomique. L’automatisation ne doit pas s’appuyer sur cet exemple pour garantir la correspondance lors d’une mise à jour ou le contrôle de concurrence.

Pour les champs d’adresse également, l’exemple et le tableau présentent des incohérences :

IPFamily : l’exemple indique IPv4/IPv6, tandis que le tableau spécifie le type de données INTEGER et la valeur par défaut IPv4.
DestinationIP : la description mentionne des adresses IPv4/IPv6, mais le type de données est IPADDRESS6.
Netmask : l’exemple indique 0.0.0.0, tandis que le tableau décrit un préfixe de type INTEGER dans la plage 0–128.

Il n’est pas possible d’en déduire une requête IPv4/IPv6 universelle et exécutable. Avant toute modification via l’API en production, clarifier et vérifier dans un environnement de test le schéma de requête et la correspondance univoque avec la route existante pour le build installé. Noter au préalable les anciennes valeurs et garantir un accès de gestion indépendant. Ensuite, vérifier les valeurs de route enregistrées, Route Lookup et une connexion client réelle, y compris son chemin retour ; le rollback décrit ci-dessous reste nécessaire. Tant que le schéma ou la correspondance restent incertains, effectuer la modification selon la procédure dans l’interface décrite ci-dessus plutôt qu’avec une requête XML supposée correcte.

La suppression est soumise à des limites documentaires spécifiques. Les tableaux de Delete Unicast Route pour SFOS 22.0 et 23.0 indiquent que DestinationIP et Netmask sont des champs obligatoires. Cela ne suffit toutefois pas à établir un sélecteur complet identifiant de manière univoque la route à supprimer. Les dix cellules de valeurs par défaut sont vides ; cela n’implique ni la valeur 0, ni « inchangé », ni null. Pour IPFamily, seul le type de données INTEGER est indiqué, sans correspondance entre les valeurs autorisées et IPv4 ou IPv6. Aucun exemple de requête Delete n’est fourni.

Les valeurs par défaut Add/Update décrites ci-dessus et les hypothèses concernant OldConfiguration ne doivent donc pas être transposées à Delete. Tant que le schéma de requête et l’identification univoque de la route cible pour le build installé ne sont pas clarifiés, utiliser la procédure de suppression dans l’interface et le rollback décrit ci-dessous, plutôt qu’une requête de suppression XML fondée sur des suppositions. Au préalable, sauvegarder les valeurs existantes des routes et garantir un accès de gestion indépendant ; ensuite, vérifier les valeurs des routes, Route Lookup et une connexion client réelle, y compris son chemin retour.

Vérifier la route

Une route enregistrée n’est validée que lorsqu’un client réel atteint le système distant et que le chemin retour fonctionne.

Les contrôles CLI ci-dessous s’effectuent dans 4. Device Console, et non dans l’Advanced Shell, et ne font que lire l’état actuel. Avant leur exécution, vérifier la syntaxe complète sur le build installé avec Tab ou ?. Ne pas exécuter de commandes incomplètes : elles peuvent empêcher le service access_server de répondre.

Sous Diagnostics > Tools > Route lookup, saisir 10.20.0.10. La sortie doit indiquer Port4.
Dans la Device Console, vérifier les routes IPv4 ou IPv6 configurées et, en cas de concurrence avec SD-WAN ou VPN, la Route Precedence :
```
show static-route
show static-route6
system route_precedence show
```
Depuis le client 10.10.0.10, établir une connexion réelle vers 10.20.0.10, par exemple avec Ping ou TCP 443, conformément à la règle firewall.
Dans Log viewer, contrôler la source, la destination, le service, le Firewall Rule ID et un éventuel NAT Rule ID.
Sous Diagnostics > Packet capture, utiliser host 10.20.0.10 pour vérifier que les requêtes sortent via Port4 et que les réponses reviennent.

Si Route Lookup indique le bon chemin, mais qu’aucun trafic ne passe, la cause se trouve généralement dans la règle firewall, le NAT, la route de retour ou le système de destination. Le test complet du flux de paquets est décrit dans Tester une règle Sophos Firewall avec Log Viewer et Packet Capture.

Pour les problèmes de routage plus profonds, les dernières entrées des journaux Unicast et kernel sont disponibles dans la Device Console :

show logs staticd.log lines 50
show logs zebra.log lines 50

staticd.log concerne les routes Unicast statiques ; zebra.log indique l’installation des routes Unicast IPv4 statiques dans le kernel. Fichiers de service et journaux Sophos Firewall associe les autres fichiers journaux aux services responsables.

Après le redémarrage d’une interface ou d’un tunnel, une route uniquement définie par gateway peut d’abord être absente de la table de routage. Elle apparaît dès qu’un trafic correspondant à la destination et au gateway amène le firewall à sélectionner l’interface. Une entrée manquante juste après le redémarrage ne prouve donc pas encore un défaut.

Identifier les erreurs et effectuer un rollback

Route Lookup indique la mauvaise interface

Vérifier l’adresse de destination et le préfixe ; une faute de saisie peut faire correspondre un autre réseau.
Le gateway doit être directement joignable via l’interface sélectionnée.
Comparer les routes statiques concurrentes ainsi que leur Administrative Distance et leur Metric.
Avec SD-WAN ou VPN, vérifier l’ordre actuel avec system route_precedence show. La modification globale est expliquée dans Modifier la Route Precedence en toute sécurité.

La requête sort, mais aucune réponse ne revient

Vérifier la route de retour sur le routeur suivant et sur le système de destination.
Vérifier la règle firewall pour le sens initiateur et les règles NAT existantes. Une règle dans le sens inverse n’est nécessaire que si le système distant initie lui-même de nouvelles connexions.
Utiliser Packet Capture pour déterminer si la réponse revient sur Port4.
Vérifier le firewall local et le default gateway du système de destination.

Rollback sécurisé

Une nouvelle route IPv4 est d’abord désactivée plutôt que supprimée. Vérifier ensuite à nouveau Route Lookup, une nouvelle connexion client et le chemin précédent. Une fois l’état initial confirmé, supprimer si nécessaire la route ainsi que les règles ou objets NAT créés exclusivement pour cette modification.

Pour IPv6, Sophos ne documente aucune fonction d’activation ou de désactivation. Il faut donc noter au préalable les valeurs existantes, puis modifier ou supprimer la nouvelle route lors d’un rollback. Dans un cluster HA, répéter le test de bout en bout après un failover sur le nouveau Primary.