Configurer et valider RIP sur Sophos Firewall

RIP distribue automatiquement des routes IPv4 entre des routeurs. Sur Sophos Firewall, le protocole convient surtout aux domaines de routage petits ou existants, dans lesquels quelques routeurs doivent échanger des réseaux sans sélection complexe du chemin.

La procédure courte et sûre est la suivante :

Documenter le réseau de transit, les LAN locaux, le peer, les préfixes attendus et le chemin retour.
Préparer une sauvegarde de la configuration et un accès de gestion indépendant.
Tester l’accessibilité IP directe entre les adresses de transit.
Sous Administration > Device access, autoriser Dynamic Routing uniquement pour la zone du peer ou au moyen d’une exception restrictive.
Sous Routing > RIP, sélectionner RIPv2 et laisser d’abord les timers globaux inchangés.
Ajouter le réseau de transit et les LAN locaux sous RIP Networks.
Mettre les interfaces LAN en Passive mode à l’aide de Override interface configuration.
Faire correspondre la version et l’authentification de l’interface de transit avec celles du peer.
Sous Routing > Information > RIP, vérifier le statut et les routes apprises.
Tester Route Lookup, Firewall Rule ID et un service bidirectionnel réel.

⚠️ Default information originate et la redistribution de Connected, Static, OSPF ou BGP restent désactivés tant que chaque préfixe annoncé et son chemin retour ne sont pas connus. Une redistribution étendue peut propager involontairement des routes Connected ou Static dans tout le domaine de routage RIP.

Cette procédure traite RIPv2 pour IPv4 en Gateway Mode. RIPv1 est uniquement présenté comme cas d’interopérabilité hérité. Sophos Firewall ne prend pas en charge RIP en Transparent Mode.

Quand RIP convient et quand il ne convient pas

RIP est un protocole à vecteur de distance. Il évalue un chemin selon le nombre de sauts de routeur. Une route avec une métrique plus faible est préférée. Au maximum 15 sauts sont accessibles ; la métrique 16 signifie inaccessible.

Les routeurs échangent périodiquement des mises à jour de routage. Le routeur destinataire intègre les modifications dans sa table de routage, augmente la métrique du chemin de 1 et utilise l’émetteur comme next hop.

Ce modèle simple est avantageux lorsque :

seuls quelques routeurs participent,
la topologie est petite et largement stable,
un peer existant ne prend en charge que RIP,
la maintenance automatique des routes est plus importante qu’une convergence rapide et qu’une politique complexe.

Pour un seul chemin fixe, une route statique est souvent plus simple. Avec plusieurs chemins redondants, une convergence rapide ou des réseaux internes plus grands, OSPF est généralement le protocole le plus adapté. BGP correspond aux designs utilisant des systèmes autonomes, des fournisseurs ou une politique de routage délibérée.

RIP ne remplace pas une règle de pare-feu et ne surveille pas la qualité des applications. Une route SD-WAN est le niveau approprié pour une sélection selon la source, le service, l’application, la latence, la gigue ou la perte de paquets.

Distinguer RIPv1 et RIPv2

Pour les nouvelles configurations, utiliser RIPv2. Il transmet les masques de sous-réseau et prend en charge l’authentification. RIPv1 est classful, ne transmet pas les masques de sous-réseau et ne prend pas en charge l’authentification sur Sophos Firewall.

Sous RIP version, SFOS fournit ces trois paramètres :

Send V2 and receive both: envoyer RIPv2 et recevoir RIPv1 et RIPv2
V1: envoyer et recevoir RIPv1
V2: envoyer et recevoir RIPv2

Dans l’exemple, les deux peers utilisent RIPv2. Send V2 and receive both peut être utile pendant une transition contrôlée, mais continue d’accepter les mises à jour RIPv1. Dès que tous les peers utilisent RIPv2, régler les versions d’envoi et de réception sur V2.

Comprendre RIP Networks et Passive Mode

Un RIP Network n’est pas le réseau de destination distant. L’entrée active RIP sur les interfaces locales dont l’adresse IP correspond au réseau indiqué. Le réseau directement connecté est ainsi inclus dans le processus RIP et peut être annoncé.

Pour l’exemple, le réseau de transit 198.51.100.0/30 et le LAN local 10.10.10.0/24 sont tous deux saisis sur Firewall A :

Le réseau de transit active RIP sur l’interface orientée vers le peer.
Le LAN est annoncé comme réseau local accessible.
Passive mode sur l’interface LAN empêche le pare-feu d’y envoyer des mises à jour RIP.

Passive Mode ne supprime pas le LAN du processus de routage. Il empêche uniquement l’envoi d’annonces RIP via cette interface. En outre, Dynamic Routing reste désactivé dans la zone cliente afin que les clients ne puissent pas envoyer de mises à jour de routage au pare-feu.

Planifier la topologie d’exemple

L’exemple de bout en bout relie deux LAN :

Firewall A: IP de transit 198.51.100.1/30, LAN local 10.10.10.0/24
Firewall B: IP de transit 198.51.100.2/30, LAN local 10.20.20.0/24
Réseau de transit: 198.51.100.0/30
Client de test A: 10.10.10.10
Serveur de test B: 10.20.20.10

198.51.100.0/24 est réservé à la documentation. Remplacez de manière cohérente le réseau de transit, les IP de transit, les préfixes LAN et les hôtes de test par les valeurs de votre environnement. Ne pas reprendre telles quelles les adresses de documentation dans une configuration de production. Les deux IP de transit doivent être directement accessibles.

Firewall A doit apprendre 10.20.20.0/24 via 198.51.100.2. Le peer doit apprendre 10.10.10.0/24 via 198.51.100.1. Seuls ces chemins aller et retour permettent un trafic routé sans source NAT.

Avant la modification, documenter l’interface, la zone, les routes existantes, Route Precedence, la métrique attendue et un hôte de test accessible. Une sauvegarde récente de la configuration et un chemin de gestion indépendant du nouveau routage permettent un retour arrière contrôlé.

Autoriser Dynamic Routing de manière restrictive

Sous Administration > Device access, vérifier d’abord les zones pour lesquelles Dynamic Routing est actuellement autorisé. Dans l’exemple, ne l’autoriser que pour la zone de transit dédiée ou au moyen d’une exception ACL visant le peer.

La matrice Device Access s’applique à toute la zone. Pour une zone de transit dédiée et fiable, vous pouvez y activer Dynamic Routing. Si l’accès doit être limité à un peer ou à un réseau de transit précis, laisser la case de la zone décochée et créer plutôt, sous Local service ACL exception rule, une exception Allow restrictive pour la source et le service. Une autorisation simultanée à l’échelle de la zone annulerait cette restriction. Device Access et Local Service ACL explique la distinction.

Cette autorisation concerne les paquets RIP au pare-feu et ne peut être remplacée par une règle de pare-feu normale. Le flux de données entre 10.10.10.0/24 et 10.20.20.0/24, par contre, nécessite toujours des règles de pare-feu normales. Dynamic Routing n’est pas activé dans la zone LAN simplement parce que le LAN est annoncé comme RIP Network. Documenter l’état effectif de Device Access avant la modification, sans présumer d’une autorisation générale par défaut.

Si les deux pare-feu envoient des mises à jour RIP par l’interface de transit, mais que seul Firewall A autorise les mises à jour entrantes, l’apprentissage des routes devient unilatéral : A reçoit les mises à jour de B et apprend 10.20.20.0/24 via 198.51.100.2. B continue d’envoyer ses mises à jour, mais rejette celles provenant de A, car l’autorisation pour Dynamic Routing manque sur B. B n’apprend donc pas par RIP la route vers 10.10.10.0/24 annoncée par A.

Il s’agit d’une asymétrie dans l’échange des informations de routage (plan de contrôle), et non d’une preuve d’un dysfonctionnement précis du trafic de données. Vérifier les deux côtés sous Routing > Information > RIP > Routes et contrôler l’autorisation effective de réception sur le pare-feu qui n’apprend pas les routes. Toute correction reste limitée à la zone réelle du peer ou à une exception ACL restrictive ; ne pas autoriser globalement l’accès depuis WAN. Vérifier ensuite séparément Route Lookup, les règles de pare-feu, NAT et les chemins aller et retour réels.

Configurer RIPv2 dans WebAdmin

L’exemple utilise un second Sophos Firewall côté B. Avec deux Sophos Firewall, reproduisez la configuration sur le pair ; seuls l’IP de transit et le LAN local diffèrent. Pour un routeur d’un autre constructeur, configurer RIPv2, le réseau de transit, le LAN local, Passive mode et, le cas échéant, l’authentification au moyen des fonctions équivalentes de cet équipement.

1. Définir les valeurs globales

Ouvrir les paramètres globaux sous Routing > RIP :

Définir RIP version sur V2.
Laisser Default metric sur sa valeur par défaut existante 1.
Laisser Administrative distance sur sa valeur par défaut existante 120.
Laisser d’abord Update, Timeout et Garbage sur 30, 180 et 120 secondes.
Laisser Default information originate désactivé.
Ne pas activer la redistribution.
Sélectionnez Apply pour enregistrer les modifications.

Default information originate génère et annonce une route par défaut dans le domaine RIP et est désactivé par défaut. Cette option n’est appropriée que si ce pare-feu doit délibérément servir de sortie pour toutes les destinations inconnues et si le chemin retour ainsi que le cas de panne ont été planifiés.

La valeur par défaut de Default metric pour les routes redistribuées est 1 ; la plage autorisée va de 1 à 16. Administrative distance vaut 120 par défaut et accepte des valeurs de 1 à 255. Conserver ces deux valeurs en l’absence d’une justification documentée dans la conception du routage.

Administrative distance aide le routeur à choisir la meilleure route entre des sources de routage concurrentes ; la métrique RIP compare, quant à elle, les chemins au sein de RIP.

Les valeurs par défaut de Update, Timeout et Garbage sont respectivement 30, 180 et 120 secondes. Update définit l’intervalle entre deux mises à jour périodiques de routage. La documentation officielle de SFOS 22.0 indique de 5 à 2147483647 secondes pour chacun de ces trois timers ; celle de SFOS 23.0 indique de 1 à 32767 secondes pour chacun et nomme Timeout Time-out. Il s’agit de valeurs documentées par version, pas d’une garantie de validation des saisies sur une version logicielle testée. L’exemple conserve les valeurs par défaut ; ne choisir d’autres valeurs que si les deux peers partagent une conception documentée des timers et de la gestion des pannes.

Si la redistribution est délibérément nécessaire, n’activer que les sources prévues sous Routing > RIP : Redistribute connected pour les routes directement connectées, Redistribute static pour les routes statiques, Redistribute OSPF pour les routes OSPF et Redistribute BGP pour les routes BGP. Définir la métrique de redistribution correspondante pour chaque source activée ; les quatre champs autorisent de 0 à 16, contrairement au paramètre global Default metric. Choisir les valeurs selon la conception documentée du routage, sans reprendre une valeur générique. Enregistrer avec Apply, puis vérifier les préfixes attendus et inattendus ainsi que le chemin retour comme décrit ci-dessous. Les quatre sources restent désactivées dans l’exemple.

2. Ajouter les RIP Networks

Sous Routing > RIP > RIP Networks > Add, saisir les réseaux locaux suivants sur Firewall A :

198.51.100.0 avec le masque de sous-réseau 255.255.255.252
10.10.10.0 avec le masque de sous-réseau 255.255.255.0

Sur le peer B, saisir le même réseau de transit et 10.20.20.0/24.

Avant d’enregistrer, vérifier à quelle interface locale correspond chaque Network. Un Network trop large peut activer RIP sur d’autres interfaces et inclure davantage de réseaux directement connectés dans le processus.

3. Définir les Interface Overrides

Sous Routing > RIP > Override interface configuration, utilisez Select interface pour choisir l’interface participante.

Send et Receive permettent chacun, indépendamment, V1, V2 ou les deux versions. La sélection de chaque interface remplace le paramètre global RIP version. Send vaut V2 par défaut ; la version de réception V2 choisie ci-dessous est un réglage délibéré de l’exemple, pas une affirmation sur la valeur par défaut de Receive. Passive mode est désactivé par défaut et est activé expressément pour le LAN.

Pour une connexion RIPv2 volontairement authentifiée, activer Authentication et saisir un mot de passe ; la configuration doit correspondre sur les deux peers. Si l’authentification est sélectionnée pour une interface RIPv1, celle-ci envoie des mises à jour de routage mais n’accepte pas de routes. Lorsque les deux versions sont sélectionnées, RIPv2 continue de fonctionner avec l’authentification. Sophos recommande de configurer RIPv1 sur une interface différente de celle utilisée pour RIPv2 authentifié.

Pour l’interface de transit :

Send version: V2
Receive version: V2
Passive mode: désactivé
Split horizon: conserver l’état antérieur documenté ; SFOS désactive cette option par défaut
Poisoned reverse: disponible uniquement lorsque Split Horizon est activé et désactivé par défaut
Authentication: vérifier l’état antérieur effectif et régler délibérément les deux côtés de façon identique

Pour l’interface LAN :

Send version: V2
Receive version: V2
Passive mode: activé

Enregistrez la sélection avec Save. RIPv2 prend en charge le texte clair et l’authentification MD5. Plaintext ne protège pas le mot de passe. MD5 authentifie les mises à jour de routage, mais il ne chiffre ni préfixes ni métriques. Les segments de transit restent donc limités aux routeurs prévus. L’aide publique de la CLI SFOS 22 et celle de WebAdmin donnent des indications contradictoires sur l’état par défaut de l’authentification. Ce guide ne suppose donc aucune valeur par défaut : vérifiez les deux interfaces de transit et configurez-les délibérément et de manière identique.

Split horizon empêche normalement qu’une route apprise via une interface soit annoncée à nouveau sur cette même interface. Poisoned reverse peut l’y annoncer explicitement avec la métrique 16 comme inaccessible. Ces options ne sont modifiées que si la topologie hub, spoke ou multi-accès l’exige et sont testées avec le peer.

4. Reproduire la configuration sur le peer

Sur Firewall B, définir la même version, les mêmes timers et la même authentification. Utiliser 198.51.100.0/30 et 10.20.20.0/24 comme Networks, puis rendre passive l’interface du LAN local.

Une configuration unilatérale ne suffit pas. Sans annonce du réseau retour, Firewall A peut apprendre le LAN distant, mais les réponses ne trouvent pas de chemin retour.

Pourquoi ce guide utilise WebAdmin pour les modifications

L’accès à la CLI documenté diffère selon la version : l’aide de SFOS 22.0 indique 3. Route Configuration > 1. Configure Unicast Routing > 1. Configure RIP, l’invite rip>, puis enable. L’aide de SFOS 23.0 indique en revanche 3. Route Configuration > 1. Configure Unicast Routing, l’invite router#, puis router#configure terminal. L’entrée router rip du tableau est une commande CLI, et non un choix de menu supplémentaire. Il s’agit d’une comparaison des accès documentés, pas d’une séquence de configuration exécutable.

L’aide publique de la CLI SFOS 22 contient des commandes d’authentification incorrectement concaténées et ne documente pas toutes les commandes nécessaires à l’enregistrement et à la validation. L’aide de SFOS 23.0 reste elle aussi ambiguë quant aux contextes CLI de l’authentification et à l’exemple MD5. La correction des exemples en texte clair ne rend pas automatiquement les autres commandes fiables en tant que séquence. Ce guide n’en déduit ni syntaxe non vérifiée ni étapes de changement de contexte ou d’enregistrement.

La configuration et le retour arrière passent donc par les champs WebAdmin documentés. N’utiliser la CLI que pour les diagnostics de support en lecture seule documentés pour la version SFOS installée.

Règles de pare-feu, NAT et Route Precedence

Pour le test, les deux pare-feu ont besoin de règles restrictives et journalisées pour les services réellement nécessaires entre 10.10.10.0/24 et 10.20.20.0/24. Créer correctement des règles de pare-feu explique le fonctionnement des règles.

Dans un réseau intersites normalement routé, source NAT reste désactivé. Les deux côtés doivent voir l’adresse source réelle et connaître le chemin retour via RIP. SNAT peut masquer des routes de retour manquantes et compliquer l’analyse ultérieure ainsi que le contrôle d’accès.

Au sein de RIP, SFOS conserve pour une destination la route dont la métrique en sauts est la plus faible. Cela ne prouve pas que ce chemin est également la route active à l’échelle du système. Lorsqu’une route statique, SD-WAN ou VPN est en compétition, utilisez Diagnostics > Tools > Route lookup pour vérifier le chemin réellement sélectionné. Ne modifiez pas globalement Route Precedence pour un seul test RIP.

Valider RIP et le chemin de données réel

La validation distingue trois questions : les routes sont-elles échangées, la bonne route est-elle sélectionnée et le trafic de données fonctionne-t-il ?

Vérifier Routes et Status

Sous Routing > Information > RIP > Routes, Firewall A doit afficher le réseau 10.20.20.0/24 avec le next hop 198.51.100.2 et une métrique plausible. Le peer B doit connaître 10.10.10.0/24 via 198.51.100.1.

Sous Routing > Information > RIP > Status, comparer :

les interfaces participantes
les versions RIP envoyées et reçues
les timers Update, Timeout et Garbage
les sources de routage et la redistribution
les champs From, Tag et Time de la route
filtres de mise à jour entrants et sortants, si configurés
le nom de la Key-chain, si elle est configurée
Bad Packets et Bad Routes

Une route RIP visible confirme l’échange de routes, mais pas que SFOS la sélectionne ni que le trafic de données l’emprunte. La vue Status ne permet pas d’établir quel secret est utilisé ; celui-ci doit être géré et vérifié de manière contrôlée sur les deux peers.

Tester Route Lookup et le trafic

Sur Firewall A, vérifier la destination 10.20.20.10 sous Diagnostics > Tools > Route lookup. Le next hop et l’interface doivent correspondre au chemin de transit.
Sur le peer B, vérifier la destination 10.10.10.10.
Depuis le client 10.10.10.10, établir une connexion réelle autorisée vers le serveur 10.20.20.10.
Dans Log viewer, vérifier la source, la destination, le service, Firewall Rule ID, Action et une éventuelle NAT Rule ID.
Sous Diagnostics > Packet capture, confirmer que la requête et la réponse traversent les interfaces attendues.

La procédure complète se trouve dans Tester une règle de pare-feu avec Log Viewer et Packet Capture.

Délimiter systématiquement les erreurs

Aucune route RIP n’apparaît

Tester d’abord l’accessibilité directe entre les adresses de transit. Ensuite, Dynamic Routing doit être activé dans la bonne zone du peer, un RIP Network doit correspondre à l’interface locale et les versions d’envoi et de réception doivent être compatibles. Si l’authentification est utilisée, la méthode et le secret doivent correspondre.

Si les compteurs Bad Packets ou Bad Routes augmentent sous Status, comparez la version, l’authentification, le sous-réseau et la configuration du pair. Si les compteurs restent inchangés et que les vues de diagnostic n’indiquent aucun trafic RIP provenant du pair, vérifiez d’abord l’attribution de l’interface et Local Service ACL. Ne modifier les valeurs globales de RIP qu’après ces vérifications.

La route apparaît sous RIP, mais n’est pas utilisée

L’échange de protocole fonctionne alors. Route Lookup montre quel chemin est réellement actif. La métrique RIP compare les chemins RIP ; en soi, elle ne décide pas entre toutes les sources de routage.

Ne pas supprimer la Route Precedence globale ni une route de production existante avant d’avoir documenté son effet sur les autres réseaux.

Le trafic ne fonctionne que dans un sens

Le peer a besoin de la route retour et les deux pare-feu de règles adaptées. Vérifier également NAT, les chemins asymétriques et la passerelle de l’hôte. L’existence du chemin aller ne prouve pas le chemin retour.

La route disparaît puis réapparaît

Si aucune mise à jour n’arrive avant l’expiration de la valeur Timeout configurée, la route devient invalide ; pendant la période Garbage, SFOS l’annonce avec la métrique 16, puis la supprime. Comparer l’accessibilité, l’état du peer et les valeurs Update, Timeout et Garbage des deux côtés avant de modifier un timer.

Des réseaux inattendus sont annoncés

Vérifiez RIP Networks, Default information originate et chaque option de redistribution individuellement. La redistribution peut inclure plus de routes Connected ou Static que les réseaux locaux prévus pour cet exemple. Laisser la redistribution désactivée tant que tous les préfixes à distribuer ne sont pas connus.

Annuler la modification en toute sécurité

Avant de supprimer RIP, un chemin alternatif ou une fenêtre de maintenance planifiée doit exister pour chaque réseau de destination appris.

Le retour commence par le chemin de remplacement, non par la suppression des routes RIP actives :

Activez la route statique ou dynamique alternative et validez-la avec Route Lookup, accès de gestion et trafic bidirectionnel réel.
Désactiver la redistribution nouvellement activée et Default information originate si elles faisaient délibérément partie du test; puis vérifier à nouveau les préfixes attendus.
Supprimer les RIP Networks locaux un par un, en vérifiant les chemins aller et retour après chaque étape.
Rétablissez l’état précédent documenté des Interface Overrides et des paramètres RIP globaux.
Supprimer en dernier Dynamic Routing de la zone de transit ou l’exception ACL, et seulement si aucun OSPF, BGP ou PIM voisin ne l’exige également.
Enfin, revérifiez Route Lookup, les règles, l’accès à la gestion et le trafic réel.

Ne pas supprimer RIP et le chemin de remplacement en même temps. Garder une session administrateur existante ouverte jusqu’à ce que le chemin retour soit confirmé.

Contrôle avant validation

Les deux pare-feu montrent les routes RIP attendues avec le prochain saut correct et une métrique plausible.
Route Lookup confirme les chemins d’accès et de retour prévus.
Aucun préfixe inattendu ou redistribution involontaire n’apparaît.
Des règles de pare-feu restrictives et journalisées s’appliquent sans SNAT involontaire.
Un service réel fonctionne dans les deux sens.
Le chemin de remplacement et la procédure de retour arrière sont documentés et exécutables.