Configurer et vérifier OSPF sur Sophos Firewall

OSPF échange automatiquement des routes IPv4 entre les routeurs. Cela s’avère utile lorsque plusieurs sites, des chemins redondants ou des réseaux fréquemment modifiés deviennent trop difficiles à maintenir avec des routes statiques. Pour un domaine de routage petit ou existant avec peu de routeurs, RIPv2 peut être plus simple ; OSPF offre en revanche une convergence plus rapide et un modèle de chemins plus évolutif.

Dans l’exemple suivant, deux pare-feu Sophos établissent une adjacence OSPF via un réseau de transit dédié. À la fin, le voisin est à l’état Full, Firewall A connaît le LAN derrière Firewall B et inversement. OSPFv3 est configuré séparément pour IPv6.

⚠️ Les adjacences OSPF ne doivent être établies que sur des interfaces de transit ou VPN dédiées et fiables. Dans l’exemple, le LAN est aussi enregistré comme OSPF Network afin que SFOS annonce son préfixe. SFOS active ainsi OSPF sur l’interface LAN et peut y envoyer des Hellos OSPF sortants. Dynamic Routing reste désactivé pour la zone LAN afin de ne pas autoriser les paquets OSPF entrants ; cela n’empêche pas les Hellos sortants. Ne pas activer Redistribute connected avant de savoir quels réseaux directement connectés seraient ainsi annoncés.

Aperçu du déroulement

Les étapes suivantes sont nécessaires pour établir une connexion OSPFv2 simple :

Adresser les interfaces de transit et vérifier l’accessibilité IP directe.
Sous Administration > Device access, autoriser Dynamic Routing pour une zone de transit dédiée ou avec une Local Service ACL Exception strictement limitée.
Sous Routing > OSPF, saisir un Router ID unique sur chaque firewall.
Créer Area 0.0.0.0 avec le type Normal.
Sous Networks, affecter le réseau de transit local à Area 0.0.0.0.
Entrer le LAN respectif comme deuxième réseau OSPF ou utiliser une redistribution vérifiée séparément.
Sous Routing > Information > OSPF, vérifier l’état Full du voisin et la route apprise.

Un Network OSPF n’est pas le réseau de destination distant. Cette entrée active OSPF sur les interfaces locales dont l’adresse IP appartient à ce réseau. Le LAN distant n’apparaît que lorsque le pair l’annonce via OSPF.

Ce que décide OSPF sur le firewall

OSPF est un protocole de routage interne à état de liens. Les routeurs voisins échangent des informations sur les réseaux et chemins qu’ils peuvent atteindre, construisent une Link-State Database à partir de ces informations et calculent le chemin le moins coûteux. Un Cost inférieur est préféré à un coût supérieur.

OSPF remplit donc une autre fonction que les règles de firewall et le SD-WAN :

OSPF apprend et distribue les réseaux de destination au sein du domaine de routage.
Une règle de firewall détermine toujours si le trafic utile peut passer entre les zones et les réseaux concernés.
NAT modifie les adresses si nécessaire, mais ne fait pas partie d’OSPF.
Une SD-WAN Route peut en outre prendre une décision selon la source, le service, l’application ou la qualité de la liaison.

Les routes OSPF apparaissent avec les autres routes unicast dans la table de routage. Le routage classique sélectionne d’abord le préfixe correspondant le plus long. Pour un même préfixe, SFOS compare l’Administrative Distance des différentes sources de routage ; entre des chemins OSPF comparables, la métrique OSPF est ensuite déterminante. Indépendamment de cela, la Route Precedence globale détermine si le routage classique, les SD-WAN Policy Routes ou les routes VPN sont évalués en premier. Avant toute modification globale, consigner l’ordre actuel avec system route_precedence show.

OSPFv2 traite IPv4. OSPFv3 remplit la même fonction pour IPv6, mais se configure séparément sur Sophos Firewall.

Planifier la topologie d’exemple

Les valeurs de l’exemple représentent deux sites :

Firewall A : Router ID 192.0.2.10, IP de transit 198.51.100.1/30, LAN local 10.10.10.0/24
Firewall B : Router ID 192.0.2.20, IP de transit 198.51.100.2/30, LAN local 10.20.20.0/24
Réseau de transit : 198.51.100.0/30
OSPF Area : 0.0.0.0

Les adresses 192.0.2.0/24 et 198.51.100.0/24 sont des réseaux de documentation. Elles doivent être remplacées par les valeurs réelles de l’environnement.

Le Router ID ressemble à une adresse IPv4, mais ne doit pas nécessairement être affecté à une interface. L’essentiel est qu’il reste unique et durablement stable dans le domaine OSPF. 0.0.0.0 n’est pas autorisé. Si aucune valeur n’est définie, SFOS utilise l’adresse d’interface la plus élevée ; un Router ID choisi délibérément évite que l’identité change de manière inattendue après une modification d’interface.

Pour cette architecture simple, l’Area backbone 0.0.0.0 suffit. Plusieurs Areas ne deviennent utiles que lorsqu’un domaine de routage plus vaste doit être délibérément structuré et agrégé. Chaque Area supplémentaire doit être reliée à Backbone Area.

Préparer OSPF en toute sécurité

Les conditions suivantes doivent être remplies avant la configuration d’OSPF :

Le firewall fonctionne en Gateway Mode. OSPF n’est pas disponible en Transparent Mode.
Les deux IP de transit se trouvent dans le même réseau et peuvent communiquer directement, par exemple avec Ping.
L’interface, le masque de sous-réseau, la MTU et la zone sont documentés.
Router ID, Area, l’authentification, Hello interval et Dead interval sont coordonnés des deux côtés.
Une sauvegarde de la configuration et un accès d’administration indépendant sont disponibles.
Des règles de firewall et des chemins de retour adaptés sont prévus pour les deux LAN.

Un VLAN de transit et une zone de transit dédiés facilitent la sécurisation. Configurer les zones et les interfaces de Sophos Firewall en explique les bases.

Autoriser Dynamic Routing de manière ciblée

Sous Administration > Device access, Dynamic Routing est désactivé par défaut pour toutes les zones. Pour cet exemple, le service est activé uniquement dans la zone de transit dédiée à laquelle le réseau 198.51.100.0/30 est lié.

La case de la matrice Device Access s’applique à toute la zone, et non à une seule interface. Une zone de transit dédiée est donc la solution la plus claire. Si l’interface de transit partage sa zone avec d’autres réseaux, une Local service ACL exception rule peut restreindre l’accès selon IP version, Source zone, Source networks and hosts, Destination host, le service Dynamic Routing, Action et la position de la règle. Toutefois, OSPFv2 utilise les destinations multicast 224.0.0.5 et 224.0.0.6 ; l’adresse de transit locale n’est donc pas nécessairement un Destination host fonctionnel. Avant d’utiliser une telle exception, confirmer la prise en charge du multicast sur le build SFOS installé. Sans cette confirmation, la zone de transit dédiée reste le choix sûr.

Cette autorisation concerne les paquets OSPF destinés au firewall lui-même. Aucune règle de firewall normale n’est nécessaire à cet effet. Le trafic réel entre 10.10.10.0/24 et 10.20.20.0/24 nécessite malgré tout des règles de firewall IPv4 appropriées. Sécuriser Device Access sur Sophos Firewall explique la séparation entre les services locaux et le trafic transféré.

Configurer OSPFv2 dans WebAdmin

Les étapes suivantes sont effectuées sur les deux firewalls. Seuls Router ID, l’IP de transit et le LAN local diffèrent.

1. Définir les paramètres globaux

⚠️ Les valeurs d’exemple concernent une première configuration. Ne pas remplacer sans précaution le Router ID d’un routeur existant : l’aide SFOS 23 avertit qu’une modification réinitialise toutes les sessions OSPF. Cela ne signifie pas que les versions antérieures en seraient exemptées. Avant la modification, sauvegarder la configuration, garantir un accès d’administration indépendant, relever les voisins et les routes, puis prévoir une fenêtre de maintenance. Ensuite, les adjacences attendues doivent revenir à Full, les préfixes souhaités être présents, les préfixes indésirables absents, et les connexions réelles ainsi que leurs chemins de retour fonctionner.

Sous Routing > OSPF, définir les valeurs globales :

Router ID : 192.0.2.10 sur Firewall A, 192.0.2.20 sur Firewall B
Default metric : conserver 20, sauf si une valeur spécifique est prévue pour les routes redistribuées
ABR type : Standard pour une nouvelle architecture standard
Auto-cost reference-bandwidth : conserver la valeur par défaut 100000 Mbps tant que la planification des coûts n’exige pas une autre valeur de référence commune
Default-information originate : Never, tant que le firewall ne doit pas distribuer expressément une Default Route à tous les voisins OSPF
Redistribute connected, static, RIP et BGP : laisser désactivés dans un premier temps

Appliquer ensuite la configuration globale avec Apply.

Default metric est la valeur de repli pour les routes redistribuées lorsqu’aucune métrique propre à leur type de route n’est définie. Un Area Border Router (ABR) relie les autres Areas au backbone et conserve une base de données de topologie et des informations de routage distinctes pour chaque Area connectée. OSPFv2 propose Standard, Cisco, IBM et Shortcut sous ABR type pour assurer la compatibilité avec le domaine existant ; le choix doit correspondre à l’architecture convenue.

Lors d’une migration depuis une ancienne version vers SFOS 19.5 ou ultérieur, l’ancienne valeur par défaut de Reference Bandwidth, 100, devient 100000 Mbps. Une valeur personnalisée est conservée sans modification. Après une mise à niveau, comparer la valeur effective et les coûts calculés à la planification des coûts.

Un Autonomous System Boundary Router (ASBR) introduit dans OSPF des routes provenant d’autres sources de routage. Les métriques externes suivantes se rapportent à ce routeur.

La métrique par défaut concerne les routes importées dans OSPF depuis d’autres sources. Pour les routes redistribuées et la Default Route annoncée, il est également possible de choisir Metric type. External type 1 additionne le coût interne jusqu’à l’ASBR et le coût externe. Avec External type 2, la métrique externe est comparée en premier ; en cas d’égalité, le chemin interne jusqu’à l’ASBR sert aussi de critère de départage. Le coût de l’interface détermine en revanche le choix du chemin au sein de la topologie OSPF. Un coût inférieur l’emporte.

Default-information originate: Always ne doit pas servir de commutateur rapide pour le basculement Internet. Le firewall annoncerait alors une Default Route même s’il n’en possède aucune. Regular ne l’annonce que lorsqu’une Default Route est présente dans la table de routage.

2. Créer Backbone Area

Dans la section Areas, cliquer sur Add et définir les valeurs suivantes :

Area : 0.0.0.0
Type : Normal

Area cost ne peut être défini que pour les types d’Area autres que Normal ; ce champ n’est pas disponible pour l’Area backbone de cet exemple. Pour une Area Normal, Virtual links > Add permet d’ajouter un lien virtuel afin de relier au backbone une Area sans connexion physique à celui-ci. Il s’agit d’une modification multi-area planifiée, pas d’un substitut à la vérification de la topologie physique.

Pour Area, sélectionner Authentication Type Text ou MD5. Si le pair prend en charge MD5, cette option est préférable au texte en clair. La Key ID correspondante et la clé seront renseignées ultérieurement sur l’interface de transit. MD5 authentifie les paquets OSPF, mais ne chiffre pas les informations de routage échangées.

Enregistrer ensuite Area avec Save.

Pour cette architecture simple, Area 0.0.0.0 reste de type Normal. Une Stub Area ne reçoit pas les routes externes à l’AS, tandis que Stub no-summary supprime également les routes de résumé normales, à l’exception de la route par défaut. Une NSSA peut introduire ses propres routes externes dans le domaine OSPF sous forme de LSA de type 7 ; NSSA no-summary combine cette fonction avec une restriction plus stricte des résumés. Un Virtual Link n’est disponible que pour une Normal Area. Ne pas changer le type d’Area comme solution de dépannage rapide, car les deux extrémités et l’ensemble de l’architecture de l’Area doivent correspondre.

3. Ajouter le réseau de transit

Dans la section Networks, cliquer sur Add :

IPv4/Netmask : 198.51.100.0/30
Area : 0.0.0.0

Sur Firewall A, l’adresse 198.51.100.1 correspond à ce Network ; sur Firewall B, il s’agit de 198.51.100.2. OSPF s’exécute ainsi sur les interfaces de transit respectives et les deux firewalls peuvent établir une adjacence.

Enregistrer l’entrée Network avec Save.

Un réseau OSPF désigne toujours un réseau local : SFOS active OSPF sur chaque interface dont l’adresse correspond à l’entrée et annonce son préfixe. Pour le LAN, cet exemple utilise également une entrée de réseau à l’étape 5, car cela permet de sélectionner et de retirer exactement le préfixe souhaité dans le WebAdmin. L’inconvénient est que l’interface LAN devient ainsi également partie d’OSPF. Une redistribution filtrée évite cela, mais nécessite sous SFOS 22 une configuration CLI vérifiée séparément ainsi qu’une procédure de retour arrière vérifiée.

4. Remplacer les valeurs d’interface uniquement de manière délibérée

L’interface de transit peut être sélectionnée sous Override interface configuration. Les valeurs par défaut conviennent à de nombreuses connexions Ethernet :

Hello interval : 10 secondes
Dead interval : 40 secondes
Retransmit interval : 5 secondes
Transmit delay : 1 seconde
Interface cost : Auto
Router priority : 1

Hello interval définit l’intervalle entre les paquets Hello utilisés pour découvrir les voisins. Dead interval définit le délai sans Hello au-delà duquel un voisin est déclaré indisponible. SFOS règle automatiquement Dead sur quatre fois Hello ; après une modification de Hello, vérifier que la valeur calculée respecte la plage autorisée et correspond à celle des voisins. Dead peut aussi être modifié manuellement. Retransmit interval règle la retransmission des Link-State Advertisements (LSA) ; Transmit delay tient compte des délais de transmission et de propagation d’une mise à jour d’état de liens.

DR signifie Designated Router et BDR, Backup Designated Router. L’élection privilégie la Router Priority la plus élevée ; à priorité égale, le Router ID le plus élevé l’emporte.

Hello et Dead doivent être identiques sur tous les routeurs du segment. Retransmit Interval et Transmit Delay sont définis localement. Cost et Router Priority peuvent volontairement différer : Cost détermine le chemin de données privilégié, tandis que Priority influence l’élection du DR et du BDR sur les réseaux de diffusion. Une Priority de 0 exclut l’interface de cette élection.

À Priority égale, Router ID est déterminant, mais une élection DR en cours n’est pas préemptive. Un Cost défini manuellement est utile lorsqu’un chemin doit être privilégié parmi plusieurs. Avec Auto, SFOS calcule le Cost à partir de la Reference Bandwidth globale et de la vitesse d’interface configurée. Si la vitesse de la liaison est modifiée sous Network > Interfaces, OSPF n’applique le nouvel Auto Cost qu’après un redémarrage du firewall.

Pour l’authentification MD5, sélectionner Authentication Type MD5 dans Area. Saisir ensuite la même Key ID, comprise entre 0 et 255, et la même clé sur l’interface de transit des deux côtés.

Si Text est choisi pour OSPFv2, renseigner un mot de passe d’authentification sur l’interface et le coordonner avec le pair. Cela ne concerne pas OSPFv3, qui ne prend pas en charge l’authentification.

Appliquer les valeurs d’interface modifiées avec Save.

5. Annoncer uniquement les LAN nécessaires

Dans cet exemple, Firewall A doit annoncer 10.10.10.0/24 et Firewall B, 10.20.20.0/24. Il existe deux méthodes fondamentalement différentes :

Un OSPF Network intègre l’interface locale correspondante à OSPF et annonce son préfixe.
Redistribution reprend des routes provenant d’une autre source de routage dans OSPF.

Sous Routing > OSPF > Networks, cliquer sur Add et affecter le LAN concerné à l’Area 0.0.0.0 : sur le pare-feu A 10.10.10.0/24, sur le pare-feu B 10.20.20.0/24. Enregistrer l’entrée avec Save. Dynamic Routing reste désactivé pour la zone LAN ; le service n’est autorisé que pour la zone de transit ou l’exception ACL Local Service étroite. Le pair doit alors apprendre exactement ce LAN. Un réseau local indésirable sert de contrôle négatif et ne doit pas apparaître dans sa table de routage OSPF.

Cette variante convient tant que l’intégration des interfaces LAN à OSPF est intentionnelle. Si OSPF ne doit pas être activé sur ces interfaces ou si les préfixes à distribuer proviennent de Static, RIP ou BGP, la redistribution est plus appropriée. L’option Redistribute connected dans WebAdmin reprend cependant tous les réseaux directement connectés. Sur un pare-feu en production, cela peut également inclure les réseaux WAN, de gestion, DMZ, VPN et d’autres réseaux VLAN. C’est pourquoi la case à cocher ne doit pas être activée sans discernement.

Pour le Remote Access SSL VPN, Redistribute connected importe uniquement le sous-réseau dynamique des clients. Un sous-réseau SSL VPN attribué statiquement n’est pas injecté automatiquement et, s’il est réellement nécessaire, doit être configuré comme OSPF Network distinct et testé séparément.

WebAdmin ne peut pas filtrer les routes connectées par préfixe individuel. L’aide en ligne de commande de SFOS 22 présente bien une ACL avec une Route Map à cet effet, mais elle ne documente qu’un exemple d’exclusion, sans procédure complète de retour arrière pour une allowlist en production. Sans procédure de retour vérifiée sur la version de SFOS utilisée, il est impossible d’en tirer une recette sûre à copier-coller. Toute redistribution sélective doit donc être planifiée comme une modification de routage à part entière : faire confirmer la syntaxe et le retour arrière pour le build installé, puis vérifier sur le pair aussi bien le préfixe souhaité qu’au moins un réseau qui ne doit expressément pas être annoncé.

L’option WebAdmin globale Redistribute connected reste désactivée pour une variante filtrée par CLI. Après des modifications ultérieures de la configuration OSPF globale, show running-config doit être vérifié à nouveau, car WebAdmin peut supprimer des paramètres CLI avancés contradictoires et des modifications sur log-adjacency-changes. De plus, Redistribute static ne sera activé qu’après un inventaire complet des routes statiques existantes.

Configurer et annuler OSPF dans l’interface en ligne de commande

À partir de SFOS 23.0 : les noms des Access Lists, Prefix Lists et Route Maps doivent être uniques pour l’ensemble des protocoles de routage dynamique, car ils partagent une configuration intégrée. Lors d’une mise à niveau depuis une version antérieure vers SFOS 23.0 ou ultérieur, Sophos Firewall ajoute automatiquement des préfixes de protocole aux noms des Route Maps, Prefix Lists et Access Lists en cas de conflit de noms et met à jour toutes les références aux configurations renommées. Avant une redistribution sélective ou un retour arrière, comparer les noms d’objets et les références sauvegardés avant la mise à niveau avec la configuration actuelle ; ne pas supposer qu’un ancien nom désigne toujours l’association actuelle. Après la modification ou le retour arrière, vérifier sur le pair que les préfixes souhaités sont présents et que ceux expressément interdits sont absents. Avant de choisir les noms ou de planifier le retour arrière, inventorier les noms et références de tous les protocoles. Retirer uniquement les références liées à la modification ; ne pas supprimer globalement les objets partagés. Les autres protocoles doivent conserver leurs voisins et routes attendus. Aucune recette de filtrage exécutable n’est proposée sans confirmation de la syntaxe et du retour arrière.

SFOS 22, OSPFv2/IPv4 uniquement : l’interface OSPF se trouve sous 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF. La configuration minimale suivante pour le pare-feu A reproduit le réseau de transit et l’annonce LAN de l’exemple WebAdmin. La séquence SFOS 22 documentée avec exit et write dans le contexte global ospf(config)# est conservée.

⚠️ Avant ospf router-id sur un routeur existant, effectuer les mêmes contrôles préalables que dans WebAdmin : selon l’aide SFOS 23, modifier le Router ID existant réinitialise toutes les sessions OSPF. Ne pas le remplacer par la valeur d’exemple. Garantir sauvegarde et accès d’administration indépendant, relever voisins et routes et intervenir dans une fenêtre de maintenance ; vérifier ensuite les adjacences Full, les préfixes souhaités/indésirables et le trafic réel.

enable
configure terminal
router ospf
ospf router-id 192.0.2.10
network 198.51.100.0/30 area 0
network 10.10.10.0/24 area 0
log-adjacency-changes
exit
write
show running-config
end

SFOS 23, OSPFv2/IPv4 uniquement : 3. Route Configuration > 1. Configure Unicast Routing ouvre la console de routage commune à router# (EXEC). configure terminal mène à router(config)# (configuration globale), puis router ospf à router(config-ospf)#. À partir de router#, saisir les commandes suivantes sans les invites affichées :

router# configure terminal
router(config)# router ospf
router(config-ospf)# ospf router-id 192.0.2.10
router(config-ospf)# network 198.51.100.0/30 area 0
router(config-ospf)# network 10.10.10.0/24 area 0
router(config-ospf)# log-adjacency-changes
router(config-ospf)# end
router# show running-config
router# write

end revient directement à EXEC. L’aide de configuration SFOS 23 y montre show running-config et write, tandis que sa note exige généralement do write. L’exemple de filtrage montre précisément router(config)# do write après exit depuis OSPF. Cette tension documentaire ne prouve pas qu’EXEC write ne sauvegarde pas : ici, on suit l’exemple de configuration avec ses modes explicites, et non un simple write en mode de configuration SFOS 23.

show running-config affiche l’état en cours, pas une preuve de sauvegarde. Après write sous SFOS 23, vérifier la confirmation pour le fichier intégré /conf/routing/frr.conf ; l’exemple de filtrage SFOS 22 cite encore /conf/routing/ospfd.conf. Ne pas modifier ce fichier manuellement. Selon Sophos, les modifications CLI doivent être enregistrées pour apparaître dans WebAdmin et survivre au redémarrage du firewall ou du démon. Vérifier la confirmation et les valeurs WebAdmin attendues ; aucun redémarrage n’est exigé ici ni n’a été effectué pour cet article. Sans confirmation, consulter Sophos avant d’autres modifications. Vérifier ensuite voisins, routes et trafic.

Sur le pare-feu B, l’ID de routeur 192.0.2.20 et le réseau LAN 10.20.20.0/24 sont utilisés à la place.

L’ID du routeur doit être unique, ne doit pas être 0.0.0.0 et n’a pas besoin d’être une adresse IP réellement attribuée. Sans spécification manuelle, SFOS utilise l’IP la plus élevée de l’interface. L’Area ID peut être saisie sous forme de nombre de 0 à 4294967295 ou au format IPv4. SFOS enregistre le réseau conformément au masque de manière normalisée ; c’est pourquoi 198.51.100.1/30 devient 198.51.100.0/30. C’est exactement cette valeur enregistrée qui est ensuite déterminante pour la vérification et la suppression. log-adjacency-changes enregistre les changements de voisins sans mode debug et est défini par défaut lors d’une configuration WebAdmin.

Distinguer un Network, le processus OSPF et la Default Route

SFOS 22, OSPFv2/IPv4 : pour retirer uniquement un Network, appliquer no à sa ligne normalisée dans show running-config, sous router ospf. Avant de retirer le réseau de transit, garantir routes alternatives, sauvegarde et accès d’administration indépendant et prévoir une fenêtre de maintenance : l’adjacence de ce segment disparaîtra.

enable
configure terminal
router ospf
no network 198.51.100.0/30 area 0
exit
write
show running-config
end

Cela met fin à OSPF sur les interfaces correspondantes et les annonces concernées disparaissent. no router ospf, en revanche, supprime la configuration de routage OSPFv2. Avant cette étape destructive, la configuration en cours complète, une sauvegarde et des routes alternatives sont enregistrées ; la commande devrait être exécutée pendant une fenêtre de maintenance et n’est pas un simple interrupteur marche/arrêt temporaire.

SFOS 23, OSPFv2/IPv4 : commencer le même retrait de Network à router# dans la console commune. L’aperçu SFOS 23 documente no network à router(config-ospf)# ; utiliser ensuite le même contrôle et la même sauvegarde en EXEC que ci-dessus :

router# configure terminal
router(config)# router ospf
router(config-ospf)# no network 198.51.100.0/30 area 0
router(config-ospf)# end
router# show running-config
router# write

Après le retrait, seuls l’entrée Network visée et son annonce doivent manquer ; les voisins restants, routes alternatives, accès d’administration et trafic doivent fonctionner comme prévu. Vérifier aussi la confirmation de sauvegarde. Pour annuler précisément cette modification, rétablir l’entrée network … area … relevée au préalable dans le contexte OSPF de la version utilisée, sauvegarder et vérifier de nouveau.

Pour supprimer entièrement le processus, SFOS 22 indique ospf(config)# no router ospf, tandis que l’aperçu SFOS 23 donne router(config-ospf)# no router ospf. Il s’agit d’un changement d’invite documenté, pas d’un échec de commande prouvé. Ce contexte SFOS 23 n’a pas été confirmé sur un appareil ici. Aucune procédure exécutable de suppression du processus SFOS 23 n’est donc proposée tant que Sophos n’a pas confirmé le contexte et la restauration pour le build installé ; ne pas deviner un autre mode. Ne pas supprimer globalement les ACL, Prefix Lists ou Route Maps partagées.

ospf push-default-route-to-kernel résout une troisième tâche distincte : une route par défaut apprise via OSPF est intégrée dans la table de routage du noyau. La commande n’annonce pas de route par défaut aux voisins et n’est donc pas la même que Default-information originate. Auparavant, les routes par défaut existantes, la priorité des routes, le chemin de retour de gestion et la recherche de route sont sauvegardés. La suppression officiellement documentée s’effectue à l’invite OSPF avec no ospf push-default-route-to-kernel ; ensuite, la table de routage, la recherche de route, l’accès de gestion et le trafic réel sont de nouveau vérifiés.

Les modifications globales dans WebAdmin peuvent supprimer les paramètres CLI contradictoires. Après chaque modification, vérifier à nouveau show running-config, les Neighbors, les routes apprises et la configuration enregistrée.

Vérifier et valider OSPF

Une adjacence seule ne prouve pas que le LAN souhaité est accessible. La validation s’effectue donc depuis la couche OSPF jusqu’au flux de paquets réel.

Sous Routing > Information > OSPF > Neighbors, le pair doit apparaître avec son Router ID. Full indique que les informations d’état de liens pertinentes ont été intégralement échangées.
Sous Routes, le pare-feu A doit voir 10.20.20.0/24 via 198.51.100.2. Le pare-feu B attend 10.10.10.0/24 via 198.51.100.1. Un préfixe de test non autorisé ne doit en revanche pas apparaître.
Sous Interface, on contrôle l’Area, l’ID du routeur, le coût, le timer, le type de réseau et le MTU. Database affiche la base de données Link-State ; Border routers aide à vérifier les entrées ABR et ASBR dans les conceptions multi-area.
Sous Diagnostics > Tools > Route lookup, vérifier une destination concrète, par exemple 10.20.20.10 sur Firewall A.
Tester ensuite une connexion réelle entre un hôte de chaque LAN. Log Viewer et Packet Capture doivent afficher la règle de firewall attendue, l’interface de transit et le trafic de retour.

Pour les deux dernières étapes, consulter Tester une règle Sophos Firewall avec Log Viewer et Packet Capture.

Pour un contrôle SSH supplémentaire, SFOS 22 utilise 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF ; SFOS 23 utilise 3. Route Configuration > 1. Configure Unicast Routing pour la console commune. Sous SFOS 23, revenir à router# avec end et y exécuter show running-config. Cette commande affiche la configuration en cours, pas la preuve de sa sauvegarde ; la confirmation distincte est expliquée ci-dessus. Les voisins, la base de données, les interfaces et les routes calculées sont vérifiés de manière fiable dans SFOS 22 sous Routing > Information > OSPF ; cet article ne mentionne donc pas de commandes de démon de routage non documentées.

Dans Advanced Shell, les journaux OSPF et du noyau fournissent un contexte supplémentaire. L’accès s’effectue via 5. Device Management > 3. Advanced Shell :

cd /log
tail -f ospfd.log

Arrêter la sortie en continu avec Ctrl+C. Le second journal peut ensuite être vérifié :

tail -f zebra.log

ospfd.log affiche les événements OSPF. zebra.log aide à vérifier si une route apprise dynamiquement a été ajoutée au noyau. Pour ne pas suivre le journal en direct, utiliser par exemple less /log/ospfd.log. Fichiers de service et journaux de Sophos Firewall associe les autres fichiers aux services correspondants.

Délimiter systématiquement les erreurs

Aucun voisin n’apparaît

Vérifier d’abord l’accessibilité directe des IP de transit. L’interface de transit doit ensuite être active, OSPF Network doit correspondre à l’IP de l’interface locale et Dynamic Routing doit être activé dans la zone appropriée. Area, le masque de sous-réseau, Authentication Type, Key ID, la clé, Hello et Dead doivent correspondre des deux côtés. Des Router ID en double empêchent également l’établissement correct d’une adjacence.

Le voisin reste à l’état Init ou 2-Way

Init signifie que des paquets Hello arrivent, mais que la communication n’est pas encore confirmée dans les deux directions. Device Access, les filtres asymétriques, l’affectation d’interface et le chemin de retour sont alors les premiers points à vérifier.

2-Way est normal entre deux routeurs d’un réseau de diffusion lorsque ni l’un ni l’autre n’est DR ou BDR. Dans l’exemple, avec exactement deux routeurs OSPF et Priority 1, les deux participants deviennent DR et BDR ; leur adjacence doit donc atteindre l’état Full. Si elle reste à l’état 2-Way, vérifier Router Priority, Network Type et le pair.

Le voisin reste à l’état ExStart, Exchange ou Loading

Dans ces états, la synchronisation de la Link-State Database a commencé, mais ne se termine pas. Des valeurs MTU différentes, des Network Types incompatibles, des Router ID en double ou des connexions instables en sont des causes fréquentes. Sous Routing > Information > OSPF > Interface, les valeurs MTU, MTU Mismatch Detection, Network Type et les temporisateurs sont disponibles à des fins de comparaison.

Le voisin est Full, mais le LAN distant est absent

Alors le voisinage fonctionne, mais le LAN n’est pas annoncé. Avec la méthode de réseau utilisée dans cet exemple, la route connectée doit être présente sur le pare-feu source et l’entrée network … area … correspondante doit apparaître sous router ospf. show running-config montre la valeur normalisée dans la configuration en cours, pas son état de sauvegarde.

Si la redistribution est utilisée à la place, la source de routage choisie ainsi que, le cas échéant, l’ACL, la Route Map et redistribute … route-map doivent correspondre au préfixe souhaité. Pour Redistribute connected, il est en outre nécessaire de vérifier la liste complète de toutes les routes connectées annoncées.

Si un réseau derrière un tunnel IPsec policy-based disparaît après une mise à niveau vers SFOS 22, la dépendance à redistribute kernel peut en être la cause. Le tunnel et le voisin OSPF peuvent néanmoins sembler toujours opérationnels ; SFOS 22 : routes IPsec et redistribute kernel explique les vérifications et l’architecture cible XFRM route-based.

La route existe, mais le trafic ne fonctionne pas

OSPF a rempli sa fonction lorsque la route avec le bon Next Hop est présente. Les erreurs se situent ensuite généralement au niveau de la règle de firewall, de NAT, de Route Precedence, du chemin de retour ou du système de destination. Pour des réseaux de sites normalement routés, SNAT n’est généralement pas nécessaire, car les deux firewalls doivent connaître les LAN via OSPF.

OSPF via IPsec route-based

OSPF peut également passer par une interface XFRM d’un tunnel IPsec site-à-site basé sur la route. Pour que SFOS crée les interfaces XFRM, le sous-réseau local et distant doit être Any des deux côtés. Le réglage IPv4, IPv6 ou Dual détermine ensuite les versions IP utilisées ; en mode Dual, des règles de pare-feu IPv4 et IPv6 séparées sont créées manuellement. Avec des sélecteurs de trafic spécifiques, aucune interface XFRM adressable ne se crée, à laquelle des adresses IP ou des routes pourraient être attribuées.

Les exigences supplémentaires suivantes s’appliquent à cette variante :

Dynamic Routing est autorisé pour la zone VPN sous Administration > Device access.
Le réseau de transit XFRM est saisi comme OSPF Network.
Le trafic utile nécessite des règles de firewall IPv4 ou IPv6 adaptées à la zone VPN.
Hello, Dead, l’authentification et la MTU doivent correspondre au pair.
Le type de réseau OSPF affiché est comparé des deux côtés. Une divergence peut empêcher l’établissement du voisinage et doit être clarifiée dans la conception des deux points de terminaison.

Un tunnel IPsec vert et un voisin OSPF à l’état Full sont deux points de contrôle distincts. Seuls la route apprise et un flux de paquets réel confirment l’ensemble de la configuration.

La documentation HA officielle ne garantit pas la conservation de l’état de l’adjacence OSPF. Dans un cluster HA, un basculement planifié fait donc partie du test d’acceptation de la topologie concrète. Ensuite, sur le nœud actif, il est vérifié si les voisins, les routes ainsi que ospfd.log et zebra.log affichent à nouveau l’état attendu.

OSPFv3 pour IPv6

Limite de l’aide CLI SFOS 23 : l’aide de configuration ajoute router ospf6 et affirme que les mêmes étapes s’appliquent à OSPFv3, mais poursuit avec les commandes Router ID et Network d’OSPF IPv4. L’aide de filtrage ajoute des ACL IPv6, tout en conservant match ip address et router ospf dans la suite. Cela ne démontre pas une procédure IPv6 complète et fiable pour le matching, la redistribution et le retour arrière. Les exemples CLI ci-dessus concernent uniquement OSPFv2/IPv4. Pour IPv6, conserver le chemin WebAdmin basé sur les interfaces ci-dessous ; ne recourir à une procédure CLI IPv6 qu’après confirmation par Sophos pour le build installé. Ne pas remplacer des tokens de commandes IPv4 ni considérer les commandes FRR upstream comme preuve de prise en charge par Sophos.

Sous Routing > OSPFv3, le routage IPv6 est configuré indépendamment d’OSPFv2. Le Router ID reste une valeur unique en notation IPv4. SFOS affiche 0 pour Default metric, mais utilise la valeur non modifiable 20 ; ABR type est fixé à Standard. Auto-cost reference-bandwidth vaut par défaut 100000 Mbps. Pour Default-information originate, les options sont, comme pour OSPFv2, Never, Regular et Always ; WebAdmin permet de redistribuer les routes IPv6 connectées et les routes BGP IPv6.

Contrairement à OSPFv2, aucun Network n’est d’abord ajouté. Sous Interfaces, on sélectionne l’interface compatible IPv6 et on l’affecte à une Area. Pour une configuration simple, on utilise également ici l’Area 0.0.0.0. Les paramètres Hello et Dead doivent correspondre sur le segment ; Cost, Retransmit, Transmit Delay et Router Priority sont définis en fonction de la topologie. SFOS ne prend en charge qu’une seule instance OSPFv3 par interface. L’Instance ID est configurable ; sa valeur par défaut est 0.

D’abord, sous Routing > OSPFv3 > Interfaces and areas > Areas, cliquer sur Add, saisir Area en notation IPv4, choisir Type selon l’architecture et enregistrer avec Save. Pour l’exemple simple, l’Area est 0.0.0.0. Ensuite, sous Routing > OSPFv3 > Interfaces and areas > Interfaces, cliquer sur Add, sélectionner Interface et saisir la même Area, également en notation IPv4.

Les valeurs par défaut d’OSPFv3 sont Hello 10, Dead 40, Retransmit 5 et Transmit delay 1 seconde, ainsi que Router priority 1. Les fonctions des champs, le calcul automatique de Dead et la vérification de la plage autorisée s’appliquent comme dans l’étape d’interface OSPFv2. L’élection DR/BDR privilégie aussi la priorité la plus élevée, puis le Router ID le plus élevé en cas d’égalité ; 0 exclut l’interface de l’élection. Interface cost peut rester sur Auto ou être défini manuellement en décochant la case ; les valeurs inférieures sont préférées. Auto utilise Reference Bandwidth et la vitesse configurée de l’interface. Après une modification de la vitesse configurée du lien, le nouvel Auto Cost ne s’applique également qu’après un redémarrage du firewall. Enregistrer enfin la configuration d’interface avec Save.

Des Areas OSPFv3 supplémentaires peuvent être créées comme Stub, Stub no-summary, NSSA ou NSSA no-summary. Ces variantes diffèrent par les LSA externes et de résumé qu’elles transportent ; une NSSA peut en outre transmettre à l’ABR des LSA de type 7 issus de sa propre redistribution. Ces types d’Area relèvent d’une architecture multi-area coordonnée, et non d’une tentative de réparation improvisée.

Stub ne transporte pas de LSA de type 4 ou 5 et n’autorise pas les liens virtuels. Stub no-summary supprime aussi les LSA de type 3, sauf la route de résumé par défaut, et n’autorise pas non plus les liens virtuels. NSSA ne reçoit pas de LSA externes de type 5 d’autres Areas ; ses propres LSA de type 7 circulent dans la NSSA et sont convertis par l’ABR en LSA de type 5 pour le backbone. NSSA no-summary supprime les types 4 et 5 ainsi que le type 3 sauf la route de résumé par défaut, mais conserve le type 7 et sa conversion par l’ABR. Ces propriétés ne signifient pas que SFOS propose la redistribution RIP ou statique dans WebAdmin pour OSPFv3.

Pour la configuration globale OSPFv3, sélectionner uniquement les annonces nécessaires et définir la métrique et Metric type correspondants. La signification d’E1/E2 et les effets de Never, Regular et Always sont expliqués dans l’étape globale OSPFv2 ; l’avertissement concernant Always s’applique aussi ici. Valider avec Apply. Cela peut supprimer les modifications personnalisées de log-adjacency-changes ; vérifier ensuite à nouveau la configuration en cours et enregistrée, les voisins, les préfixes IPv6 souhaités et indésirables sous Routing > Information > OSPFv3 ainsi que le trafic IPv6 réel.

Sophos Firewall ne prend actuellement pas en charge l’authentification pour OSPFv3. Les échanges doivent donc avoir lieu uniquement sur des liaisons fiables ou déjà protégées. Une configuration OSPFv2 existante n’annonce aucun réseau IPv6, et des règles de firewall IPv6 distinctes sont nécessaires pour le trafic utile IPv6.

Redistribute connected prend également en compte tous les réseaux IPv6 directement connectés avec OSPFv3 et ne devrait donc pas être activé de manière générale. Selon Sophos, dans le VPN SSL d’accès à distance, seul le sous-réseau dynamique est injecté, pas le sous-réseau statique. L’aide SFOS-22 mentionne pour le sous-réseau statique un “réseau OSPF”, bien qu’OSPFv3 soit configuré dans le WebAdmin via des interfaces plutôt que via une liste de réseaux. Aucune procédure sûre ne peut être déduite de cette contradiction ; l’annonce d’un préfixe IPv6 statique pour le VPN SSL doit être clarifiée auprès de Sophos pour le build installé.

La validation s’effectue sous Routing > Information > OSPFv3 ; en cas d’erreur, ospf6d.log fournit le contexte propre au protocole.

Annuler la modification en toute sécurité

Avant de supprimer OSPF, il doit y avoir pour chaque réseau cible appris un chemin alternatif ou une fenêtre de maintenance planifiée. Dans l’exemple, l’entrée du réseau LAN est d’abord supprimée, puis le réseau de transit, et enfin Dynamic Routing est désactivé pour la zone de transit. Si le LAN est redistribué à la place, cette redistribution est d’abord annulée. Ensuite, la recherche de routes, la table de routage et l’accès de gestion sont à nouveau vérifiés.

Pour annuler uniquement un Cost, un temporisateur ou un filtre incorrect, modifier toujours un seul paramètre à la fois. Il reste ainsi possible de déterminer si l’adjacence OSPF, l’annonce de routes ou seulement le trafic utile a été affecté.