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 :

1. Documenter le réseau de transit, les LAN locaux, le peer, les préfixes attendus et le chemin retour.
2. Préparer une sauvegarde de la configuration et un accès de gestion indépendant.
3. Tester l’accessibilité IP directe entre les adresses de transit.
4. Sous Administration > Device access, autoriser Dynamic Routing uniquement pour la zone du peer ou au moyen d’une exception restrictive.
5. Sous Routing > RIP, sélectionner RIPv2 et laisser d’abord les timers globaux inchangés.
6. Ajouter le réseau de transit et les LAN locaux sous RIP Networks.
7. Mettre les interfaces LAN en Passive mode à l’aide de Override interface configuration.
8. Faire correspondre la version et l’authentification de l’interface de transit avec celles du peer.
9. Sous Routing > Information > RIP, vérifier le statut et les routes apprises.
10. 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 de manière inattendue des routes de gestion, de transit, blackhole ou d’autres routes internes dans tout le domaine 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.

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.

SFOS propose notamment les choix globaux suivants :

• 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 faciliter une transition contrôlée, mais élargit les entrées acceptées. Dès que tous les peers utilisent RIPv2, l’envoi et la réception sont limités à 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.

La Default metric globale constitue la métrique de départ des routes redistribuées. Sa valeur par défaut est 1. Administrative distance détermine le choix entre des sources de routage concurrentes ; Sophos utilise par défaut 120 pour RIP. Ces valeurs ne sont pas modifiées sans raison documentée.

Les timers par défaut sont les suivants :

• Update: 30 secondes
• Timeout: 180 secondes
• Garbage: 120 secondes

Les timers sont coordonnés sur tous les peers. Des valeurs réduites de manière agressive peuvent entraîner la suppression et le réapprentissage inutiles des routes lors d’une perte de paquets ou d’une charge élevée.

Planifier la topologie d’exemple

L’exemple continu relie deux LAN :

• Firewall A: IP de transit 198.51.100.1/30, LAN local 10.10.10.0/24
• Routeur ou 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. Dans un environnement réel, les adresses de transit, les interfaces, les zones et les préfixes LAN sont remplacés ensemble. 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 de configuration actuelle et un chemin de gestion indépendant du nouveau routage facilitent la récupération.

Autoriser Dynamic Routing de manière restrictive

Sous Administration > Device access, Dynamic Routing est désactivé par défaut pour toutes les zones. Dans l’exemple, il est uniquement autorisé dans la zone de l’interface de transit.

La matrice Device Access s’applique à toute la zone. Si d’autres interfaces non fiables partagent cette zone, une Local Service ACL Exception restrictive pour le réseau de transit et le peer prévu est préférable. Device Access et Local Service ACL explique cette séparation.

Cette autorisation concerne les paquets RIP destinés au pare-feu. Le flux de données entre 10.10.10.0/24 et 10.20.20.0/24 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.

Configurer RIPv2 dans WebAdmin

La configuration est reproduite sur les deux peers. Seuls l’IP de transit et le LAN local diffèrent.

1. Définir les valeurs globales

Ouvrir les paramètres globaux sous Routing > RIP :

1. Définir RIP version sur V2.
2. Laisser Default metric sur sa valeur par défaut existante 1.
3. Laisser Administrative distance sur sa valeur par défaut existante 120.
4. Laisser d’abord Update, Timeout et Garbage sur 30, 180 et 120 secondes.
5. Laisser Default information originate désactivé.
6. Ne pas activer la redistribution.
7. Enregistrer les modifications.

Default information originate annonce une route par défaut dans le domaine RIP. 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.

2. Ajouter les RIP Networks

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

1. 198.51.100.0 avec le masque de sous-réseau 255.255.255.252
2. 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, sélectionner les interfaces participantes.

Pour l’interface de transit :

• Send version: V2
• Receive version: V2
• Passive mode: désactivé
• Split horizon: adapté au design peer et hub
• Authentication: identique des deux côtés si elle est utilisée

Pour l’interface LAN :

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

RIPv2 prend en charge l’authentification en texte clair et MD5. Le texte clair ne protège pas le mot de passe. MD5 authentifie les mises à jour de routage, mais ne chiffre ni les préfixes ni les métriques. Les segments de transit restent donc limités aux routeurs prévus. Pour les nouveaux designs, les environnements nécessitant une protection plus forte ou les réseaux plus grands, un protocole de routage plus moderne sur un transport contrôlé est généralement préférable.

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 le Routeur ou 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 vers le LAN récepteur.

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.

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 de sites routé normalement, 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.

Une route RIP apprise ne gagne pas nécessairement automatiquement. Les préfixes plus longs sont prioritaires ; la source de routage, Administrative Distance et la Route Precedence globale jouent ensuite également un rôle. Lorsqu’une route statique, SD-WAN ou VPN est en concurrence, Diagnostics > Tools > Route lookup indique le chemin réellement sélectionné. Route Precedence n’est pas modifiée globalement pour un seul test RIP.

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

La validation sépare l’échange de routage, la route sélectionnée et le flux de données.

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
• Bad Packets et Bad Routes
• l’authentification ou la Key Chain utilisée

Une entrée visible confirme l’échange RIP, mais ne prouve pas encore que cette route est sélectionnée ou que le trafic de données passe.

Tester Route Lookup et le trafic

1. 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.
2. Sur le peer B, vérifier la destination 10.10.10.10.
3. Depuis le client 10.10.10.10, établir une connexion réelle autorisée vers le serveur 10.20.20.10.
4. Dans Log viewer, vérifier la source, la destination, le service, Firewall Rule ID, Action et une éventuelle NAT Rule ID.
5. 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.

Pour un test en lecture seule du control plane, filtrer brièvement les paquets RIP dans Device Console :

tcpdump 'udp port 520'

Arrêter la sortie avec Ctrl+C. Des mises à jour sont attendues entre les deux adresses de transit. En revanche, des paquets RIP provenant d’un LAN client indiquent dans cet exemple une limite d’interface ou de Device Access incorrecte.

Dans Advanced Shell, les logs fournissent un contexte supplémentaire :

cd /log
tail -f ripd.log

ripd.log affiche les événements propres au protocole. zebra.log aide à déterminer si une route apprise dynamiquement a été installée dans le stack de routage. Arrêter la sortie en direct avec Ctrl+C ; tail -f zebra.log peut ensuite être utilisé. Fichiers de service et de log de Sophos Firewall classe les autres fichiers.

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.

tcpdump 'udp port 520' distingue les paquets absents des mises à jour rejetées ou inutilisables. Si les compteurs Bad Packets ou Bad Routes augmentent sous Status, comparer la version, l’authentification, le sous-réseau et la configuration du peer.

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

L’échange du protocole fonctionne alors. Route Lookup montre si un préfixe plus spécifique, une route statique, SD-WAN, VPN ou une autre Administrative Distance l’emporte. La métrique RIP seule ne permet pas de choisir 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

Une liaison de transit instable, une perte de paquets, des redémarrages du peer, des timers différents ou des erreurs d’authentification peuvent déclencher le timeout. Comparer les valeurs Update, Timeout et Garbage des deux côtés. Ne pas réduire les timers sur une simple supposition ; confirmer d’abord le chemin des paquets et l’état du peer.

Des réseaux inattendus sont annoncés

Vérifier séparément RIP Networks, Default information originate et chaque option de redistribution. Redistribute connected peut inclure davantage d’interfaces que le LAN prévu. Redistribute static peut également distribuer des routes blackhole ou de gestion. La fonction reste désactivée jusqu’à ce qu’une liste complète des préfixes et une stratégie de filtrage soient disponibles.

Tester HA et le failover de manière contrôlée

Dans un cluster HA, après un failover planifié, vérifier à nouveau sur le Primary actuel :

• RIP Status et les interfaces participantes
• les routes apprises et leur âge
• Route Lookup pour les deux LAN
• ripd.log et zebra.log sur le nœud qui a traité l’événement
• une nouvelle connexion de test bidirectionnelle

Effectuer le test dans une fenêtre de maintenance. Cet article ne promet ni une convergence RIP sans interruption ni la conservation des sessions existantes. Les logs sont stockés par nœud de traitement et sont donc collectés sur les deux appliances si nécessaire.

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.

L’annulation s’effectue dans l’ordre inverse :

1. Désactiver la redistribution récemment activée et Default information originate s’ils faisaient délibérément partie du test.
2. Supprimer les RIP Networks locaux.
3. Rétablir l’état précédent documenté des Interface Overrides.
4. Annuler les paramètres RIP globaux.
5. Supprimer Dynamic Routing de la zone de transit ou l’exception ACL uniquement si aucun voisin OSPF, BGP ou PIM n’en a également besoin.
6. Activer de manière contrôlée la route statique ou dynamique de remplacement.
7. Vérifier à nouveau Route Lookup, les règles, l’accès de 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é.

Liste de contrôle

• Gateway Mode, les interfaces, les zones et les adresses de transit sont documentés.
• Une sauvegarde et un accès de gestion indépendant sont disponibles.
• Les deux IP de transit peuvent s’atteindre directement.
• Dynamic Routing est uniquement autorisé pour la zone du peer ou une exception restrictive.
• Les deux côtés utilisent des valeurs RIPv2 et d’authentification compatibles.
• Les RIP Networks correspondent uniquement aux interfaces locales prévues.
• Les interfaces LAN clientes utilisent Passive Mode.
• Default Route Origination et la redistribution ne sont activés que de manière délibérée.
• Routes et Status affichent les préfixes, next hops et timers attendus.
• Route Lookup confirme les chemins aller et retour sélectionnés.
• Les règles de pare-feu sont restrictives, journalisées et sans SNAT involontaire.
• Un service réel fonctionne dans les deux sens.
• Le rollback et le test HA sont documentés.

FAQ