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

Vérifier ensuite la destination 10.20.0.10 sous Diagnostics > Tools > Route lookup. L’interface attendue est Port4.

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.

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.

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

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 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.

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 failover simple fondé sur la disponibilité, il est possible d’utiliser des objets gateway surveillés avec des routes statiques dont les valeurs d’Administrative Distance diffèrent. Pour une sélection selon la latence, la gigue ou la perte de paquets, utiliser un SD-WAN Profile et une route SD-WAN.

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. Le trafic est ainsi réparti, 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.

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. Cela ne s’applique pas aux anciens tunnels RED Server/Client vers Sophos UTM supprimés sous SFOS 22.

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 :

Zielnetz: 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.

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.

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 après un failover sur le nouveau Primary ; les journaux ne sont pas synchronisés entre les appareils.

Questions fréquentes

Faut-il toujours renseigner le gateway et l’interface ensemble ?

Pour une route Ethernet normale, oui en règle générale. Un tunnel IPsec route-based peut utiliser uniquement l’interface XFRM ; dans le cas particulier RED décrit, seule l’adresse IP RED du pair est renseignée comme gateway.

Pourquoi la connexion échoue-t-elle malgré un Route Lookup correct ?

Route Lookup confirme uniquement le chemin sélectionné. Il manque souvent la règle firewall, le chemin retour, une décision NAT appropriée ou l’autorisation sur le système de destination.

Une route statique surveille-t-elle automatiquement le gateway ?

L’Administrative Distance et la Metric ne surveillent pas le gateway. Un failover simple fondé sur la disponibilité est possible avec des objets gateway surveillés et des routes statiques priorisées ; pour des critères de qualité comme la latence, la gigue ou la perte de paquets, utiliser SD-WAN.