SFOS 22 : redistribute kernel ne redistribue plus les routes IPsec

Après une mise à niveau vers SFOS 22, le tunnel IPsec peut rester actif et le voisin OSPF ou BGP sembler toujours opérationnel. Pourtant, les réseaux situés derrière un tunnel IPsec policy-based peuvent soudainement disparaître des routeurs voisins.

Le déclencheur habituel est redistribute kernel : jusqu’à SFOS 21.5, les routes VPN policy-based utilisées dans cette procédure pouvaient être reprises depuis la table de routage du noyau. Avec SFOS 22.0 GA, le firewall traite ces routes en interne dans le backend VPN. redistribute kernel ne peut donc plus les trouver.

⚠️ Ne pas créer de route statique factice, null ou blackhole dans le seul but de faire réapparaître le préfixe dans OSPF ou BGP. Selon Route Precedence, une telle route peut prendre elle-même en charge le chemin de données et détourner le trafic de production du tunnel ou le rejeter.

Réponse rapide : que faire maintenant

Lorsqu’un réseau VPN précédemment annoncé manque après la mise à niveau, vérifier d’abord si tous les points suivants s’appliquent :

1. Le firewall a été mis à niveau de SFOS 21.5 ou d’une version antérieure vers SFOS 22.
2. Le tunnel concerné est policy-based.
3. OSPF ou BGP reprenait jusqu’ici les réseaux VPN via redistribute kernel.
4. Le voisin reste Full ou Established, mais le préfixe attendu manque du côté récepteur.

Si tel est le cas, une nouvelle entrée ipsec_route n’est pas la solution : sous SFOS 22, elle ne crée pas non plus de route ordinaire du noyau. Pour une architecture durable et explicite, il est recommandé d’utiliser un IPsec route-based Any-to-Any avec des interfaces XFRM adressées et une configuration OSPF ou BGP explicite.

Le contrôle avant mise à niveau vers SFOS 22 facilite la préparation. La configuration proprement dite du tunnel est décrite dans Configurer un VPN IPsec Site-to-Site.

Pourquoi la route disparaît après la mise à niveau

Une route du noyau est une entrée dans la table de routage normale du système d’exploitation. Les services de routage peuvent reprendre ces entrées comme source et, par exemple, les annoncer aux voisins avec redistribute kernel.

SFOS 22 traite IPsec policy-based différemment : le chemin des paquets est déterminé par un lookup interne du backend qui utilise des marquages, des zones et des indicateurs. Le tunnel peut ainsi transmettre correctement le trafic même si le réseau VPN associé n’apparaît pas comme une route ordinaire du noyau.

Cela explique les symptômes apparemment contradictoires :

• Le tunnel IPsec est actif.
• OSPF est Full ou BGP Established.
• Le trafic direct à travers le tunnel peut continuer à fonctionner.
• Le préfixe VPN distant n’est toutefois plus repris de la table de routage du noyau dans OSPF ou BGP.

Cette modification ne concerne pas OSPF ou BGP en général. Elle touche uniquement les architectures qui supposaient que les routes IPsec policy-based étaient disponibles comme routes du noyau.

Identifier la dépendance avant la mise à niveau

Avant une mise à niveau, il ne suffit pas de vérifier qu’un tunnel existant est vert. Il faut surtout savoir d’où OSPF ou BGP obtient le préfixe à annoncer.

Le réseau VPN distant 10.60.0.0/16 sert d’exemple. Il s’agit d’une valeur propre à l’environnement, à remplacer par le réseau réellement annoncé.

Enregistrer l’état du firewall et du VPN

Dans 4. Device Console, documenter d’abord Route Precedence et les routes IPsec manuelles :

system route_precedence show
system ipsec_route show

La sortie répond à deux questions distinctes : Route Precedence montre l’ordre global des classes de routage. system ipsec_route show affiche les associations manuelles avec les tunnels policy-based. Aucune des deux commandes ne prouve à elle seule qu’OSPF ou BGP annonce réellement le préfixe.

Sous SFOS 21.5, l’Advanced Shell permet également d’enregistrer si le réseau d’exemple apparaît dans la table de routage utilisée pour IPsec policy-based :

ip route show table 220 | grep '10.60.0.0/16'

La commande est en lecture seule ; remplacer le préfixe recherché par le réseau réel. Sous SFOS 22, l’absence de résultat pour IPsec policy-based est attendue et ne prouve pas que le tunnel lui-même est défectueux.

Documenter OSPF ou BGP séparément

Enregistrer la configuration en cours dans la CLI de routage concernée. Pour OSPF, les commandes en lecture seule suivantes sont également utiles :

show running-config
show ip ospf neighbor
show ip ospf route

Pour BGP, documenter la configuration avec les préfixes BGP connus :

show running-config
show ip bgp

Sur le routeur récepteur, enregistrer également si 10.60.0.0/16 est appris et quel Next Hop est utilisé. Ce relevé est indispensable pour déterminer après la mise à niveau si le problème touche le tunnel, l’adjacence de routage ou l’annonce du préfixe.

Configurer et vérifier OSPF et Configurer et vérifier BGP expliquent les procédures de contrôle complètes.

Choisir une architecture cible sûre

Routage dynamique via une interface XFRM

Lorsque les réseaux distants doivent être appris ou redistribués dynamiquement, IPsec route-based Any-to-Any constitue l’architecture cible la plus explicite :

1. Les deux extrémités du tunnel utilisent Route-based (Tunnel interface) avec des sous-réseaux Any-to-Any.
2. Les interfaces XFRM créées automatiquement reçoivent des adresses IP uniques provenant d’un réseau de transit dédié.
3. OSPF ou BGP établit l’adjacence via ces adresses de transit.
4. Les réseaux prévus sont annoncés explicitement dans le protocole de routage ou redistribués depuis une route réellement présente et soumise à un filtrage strict.
5. Des règles de firewall autorisent le trafic utile entre les zones LAN et VPN.

La route n’est alors plus un effet secondaire du tunnel policy-based. XFRM, le protocole de routage et les préfixes annoncés peuvent être contrôlés et modifiés séparément.

Préparer la migration dans une fenêtre de maintenance. Des connexions policy-based et route-based portant les mêmes préfixes ne doivent pas rester actives simultanément sans contrôle, car le chevauchement des sélecteurs et des routes peut fausser le test.

Conserver provisoirement IPsec policy-based

Toutes les connexions existantes ne doivent pas nécessairement être migrées immédiatement. Si le tunnel reste policy-based, l’annonce des préfixes exige toutefois une architecture propre à la topologie et planifiée consciemment. Les procédures SFOS 22 publiquement documentées ne proposent aucune commande de remplacement générale qui réexpose les routes VPN du backend comme routes du noyau pour OSPF ou BGP.

redistribute static n’est pertinent que si la route statique constitue elle-même le chemin de données souhaité et si une ACL ou une Route Map limite la redistribution aux préfixes prévus. Une route supplémentaire créée uniquement comme source de redistribution n’est pas une méthode standard sûre.

Une modification de system route_precedence ne rétablit pas non plus la route du noyau manquante. L’ordre est global et peut modifier d’autres chemins statiques, SD-WAN et VPN. Si un conflit de routage concret impose une modification, Modifier Route Precedence en toute sécurité explique les vérifications et le retour arrière.

Valider la migration et l’exploitation

Un test concluant couvre plusieurs niveaux distincts :

1. L’interface XFRM est active et porte l’adresse IP de transit prévue.
2. OSPF atteint Full ou BGP Established.
3. Seuls les préfixes prévus sont annoncés et appris du côté distant.
4. Route Lookup et Routing Information affichent le chemin planifié pour une destination concrète.
5. Log Viewer et Packet Capture montrent la règle de firewall attendue ainsi que les interfaces d’entrée et de sortie.
6. Un service réel fonctionne dans les deux sens et utilise le bon chemin de retour.
7. Avec des liaisons WAN redondantes ou HA, tester séparément un basculement contrôlé.

Route Lookup contrôle le chemin de transfert local, mais pas l’annonce du préfixe à un voisin OSPF ou BGP. Il faut donc évaluer ensemble Route Lookup, le préfixe reçu, le voisin de routage, le flux de paquets et un test applicatif réel.

Isoler les erreurs de manière systématique

Le voisin est opérationnel, mais le préfixe VPN manque

Vérifier d’abord dans show running-config si le réseau n’arrivait auparavant dans OSPF ou BGP que par redistribute kernel. Identifier ensuite le type de tunnel et le build SFOS. S’il s’agit d’IPsec policy-based sous SFOS 22, l’absence d’entrée depuis le noyau est l’explication la plus probable ; le voisin peut rester opérationnel.

Le préfixe est annoncé, mais le trafic ne fonctionne pas

L’absence de redistribution du noyau n’est alors plus la cause immédiate. Contrôler séparément Route Lookup, les règles de firewall, le NAT, le chemin de retour, l’adresse XFRM et les Traffic Selectors. Un préfixe annoncé ne prouve pas que les chemins aller et retour sont corrects.

ipsec_route existe, mais OSPF ou BGP ne reprend pas le réseau

Ce comportement est attendu sous SFOS 22. system ipsec_route show affiche l’association manuelle au tunnel qui a été configurée, mais ne confirme ni une route ordinaire du noyau ni un chemin de données fonctionnel. Une autre ipsec_route pour le même réseau ne rétablit donc pas redistribute kernel. Créer une route IPsec sur Sophos Firewall explique le classement exact et la syntaxe Add/Delete sûre.

Le trafic tombe après l’ajout d’une route statique de remplacement

La nouvelle route peut prendre le pas sur le chemin VPN réel. Annuler la modification à l’aide de la commande et du plan de maintenance précédemment documentés, contrôler Route Precedence et répéter le dernier test concluant. Ne pas modifier simultanément d’autres paramètres de routage, de NAT et de VPN.

Revenir en arrière en toute sécurité

Avant la migration, enregistrer la connexion policy-based, la configuration de routage, Route Precedence, les règles et les préfixes reçus. Lors du retour arrière, annuler uniquement le chemin qui a été modifié :

• supprimer de manière contrôlée les nouvelles annonces et les nouveaux filtres OSPF ou BGP,
• supprimer les routes XFRM uniquement lorsque l’ancien chemin de données est de nouveau actif et vérifié,
• rétablir exactement la Route Precedence d’origine si elle a été modifiée,
• supprimer complètement les routes auxiliaires artificielles,
• vérifier de nouveau le tunnel, l’état du voisin, les préfixes et le trafic réel.

Le retour arrière n’est terminé que lorsque l’accès de management et les connexions de production fonctionnent de nouveau par le chemin d’origine documenté.

FAQ