SFOS 22 : routes IPsec policy-based dans OSPF et BGP

Après une mise à niveau vers SFOS 22, un tunnel IPsec policy-based peut continuer à fonctionner alors qu’un préfixe VPN précédemment annoncé par OSPF ou BGP manque. L’adjacence de routage peut également rester Full ou Established.

Sophos documente que SFOS 22 ne crée plus les anciennes routes VPN d’IPsec policy-based et n’utilise plus ipsec0 sur le chemin d’émission. Si un préfixe OSPF ou BGP disparaît en même temps, le lien avec la redistribution doit être considéré comme une déduction opérationnelle observée : la KBA ne décrit ni redistribute kernel, ni OSPF, ni BGP. L’absence d’un préfixe ne signifie donc pas automatiquement que le tunnel est défaillant.

⚠️ Ne créez pas de route factice, null, blackhole ou autre route auxiliaire dans le seul but d’annoncer le préfixe. Elle peut modifier le chemin de données. Avant toute modification en production, clarifiez l’architecture concernée avec Sophos Support ou dans une fenêtre planifiée de conception et de maintenance.

Diagnostic rapide

Examinez ce scénario de mise à niveau vers SFOS 22 lorsque tous les points suivants s’appliquent :

1. Le problème a commencé avec la mise à niveau vers SFOS 22.
2. Le tunnel est policy-based.
3. OSPF ou BGP utilisait auparavant redistribute kernel pour le préfixe VPN.
4. Le tunnel et le voisin sont opérationnels, mais le préfixe manque sur le routeur récepteur.

Pour un tunnel route-based ou une adjacence défaillante, recherchez plutôt la panne de tunnel ou de routage correspondante.

Pourquoi les vues de routage habituelles ne suffisent pas

La KBA indique que SFOS 22 ne crée plus les anciennes routes VPN policy-based. Elle décrit séparément les routes ipsec_route comme appartenant à la classe de priorité vpn sous SFOS 22 et comme absentes de la table de routage. Elle n’indique pas comment la redistribution OSPF ou BGP traite l’un ou l’autre cas.

Évaluez séparément trois états :

• VPN : la connexion IPsec est-elle active et le trafic circule-t-il ?
• Protocole de routage : le voisin OSPF ou BGP est-il opérationnel ?
• Annonce : le routeur distant apprend-il exactement le préfixe attendu ?

Un VPN vert ne prouve pas l’annonce d’une route. Inversement, l’absence d’une route dans la vue de routage habituelle ne prouve pas qu’un tunnel policy-based est défaillant dans SFOS 22.

Identifier le flux VPN dans la sortie conntrack

SFOS 22 n’utilise plus ipsec0 sur le chemin d’émission et ne crée plus les anciennes routes VPN. Pour la connexion testée, utilisez plutôt les valeurs conntrack : le trafic vers le VPN présente mark=0x0, outzone=5 et le flag 74 ; le trafic depuis le VPN présente mark=0x0, inzone=5 et le flag 75. La zone 5 est la zone VPN, et le flag peut apparaître avec d’autres valeurs dans flagvalues.

Ces valeurs identifient le sens d’une connexion VPN observée ; elles ne prouvent pas une annonce OSPF ou BGP. Sous SFOS 22, il est également normal que Packet Capture n’affiche pas ipsec0 sur le chemin d’émission et que Route Lookup sous Diagnostics > Tools puisse afficher l’interface WAN. Corrélez un flux de test bien délimité dans conntrack et Packet Capture au lieu de considérer un seul affichage comme une panne.

Effectuer des contrôles sûrs et en lecture seule

Relever les informations du firewall et du VPN

1. Relevez la version et le build de SFOS.
2. Sous Site-to-site VPN > IPsec, relevez l’état de la connexion, le type de tunnel et les sous-réseaux locaux et distants configurés.
3. Sous Routing > Routing information, exécutez Route Lookup pour une destination précise en tenant compte de la limitation d’affichage des routes VPN policy-based et ipsec_route.
4. Dans 4. Device Console, affichez la configuration documentée :

system route_precedence show
system ipsec_route show

Ces commandes n’apportent aucune modification. Route Precedence affiche l’ordre global des classes de route ; system ipsec_route show répertorie les routes IPsec manuelles. Aucune des deux commandes ne prouve à elle seule qu’OSPF ou BGP annonce un préfixe.

Avec un accès en lecture seule à l’Advanced Shell, relevez également les vues de routes et de connexions utilisées par la KBA :

route -n
ip route show
conntrack -L

Limitez l’analyse conntrack aux extrémités et à la fenêtre temporelle du test. Ces sorties peuvent confirmer l’absence de l’ancienne route ou d’ipsec0 et identifier le flux VPN testé ; elles ne prouvent ni la redistribution ni l’annonce.

Vérifier la priorité de ipsec_route avant toute modification

Sous SFOS 21.5, une route ajoutée avec ipsec_route appartenait à la classe static ; sous SFOS 22, elle appartient à la classe vpn. Avec static sdwan_policyroute vpn, une route de politique SD-WAN correspondant aux sélecteurs VPN peut donc capter le trafic après la mise à niveau. Si le design validé exige la priorité du VPN, Sophos documente static vpn sdwan_policyroute comme ordre cible et system route_precedence set static vpn sdwan_policyroute comme commande de modification.

N’appliquez pas cette commande sur la seule base de ce diagnostic : Route Precedence est globale et peut affecter d’autres trafics. Relevez d’abord system route_precedence show, les politiques SD-WAN correspondantes, les chemins aller et retour et un point de restauration. Utilisez ensuite Modifier Route Precedence en toute sécurité pour les contrôles préalables, la modification encadrée, la validation et le rollback.

Contrôler OSPF ou BGP séparément

Utilisez les commandes d’affichage documentées par Sophos dans la CLI de routage appropriée :

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

Exécutez uniquement les commandes du protocole utilisé. Relevez également le préfixe et le Next Hop sur le routeur récepteur. Consultez Configurer et vérifier OSPF et Configurer et vérifier BGP pour les contrôles complets.

Prendre la décision d’architecture

Le routage dynamique est nécessaire

Pour le routage dynamique, Sophos documente l’IPsec route-based Any-to-Any. Cette architecture crée des interfaces XFRM qui peuvent être adressées et utilisées pour OSPF ou BGP. L’adjacence et les préfixes annoncés deviennent alors des éléments explicites de l’architecture plutôt que des effets secondaires d’une route VPN policy-based.

Il s’agit d’une orientation d’architecture, pas d’une procédure de migration universelle. L’adressage, les filtres de routage, les règles de firewall, le NAT, le chemin de retour, la redondance et le pair dépendent de la topologie. Planifiez la modification avec Sophos Support ou dans une fenêtre de conception et de maintenance avant de toucher à la production. Les principes du tunnel sont présentés dans Configurer un VPN IPsec Site-to-Site.

IPsec policy-based doit être conservé

La KBA ne documente ni la redistribution OSPF ou BGP, ni une commande mettant l’ancienne route VPN à la disposition de l’un de ces protocoles. Une autre ipsec_route, une modification de Route Precedence ou une route statique artificielle ne remplace pas une architecture de routage validée.

Si IPsec policy-based doit être conservé, concevez le chemin d’annonce propre à la topologie avec Sophos Support. Le contrôle avant mise à niveau vers SFOS 22 et Créer une route IPsec sur Sophos Firewall fournissent un contexte utile.

Avant une modification en production

Fournissez au minimum les informations suivantes pour une session de support ou de conception :

• version et build de SFOS, type de tunnel et état HA ;
• préfixes locaux et distants anonymisés ;
• configuration OSPF ou BGP précédente et état du voisin ;
• préfixes attendus et reçus avec leurs Next Hops ;
• résultats pertinents de Route Lookup, Log Viewer et Packet Capture ;
• exigences de chemin de retour, NAT, failover et fenêtre de maintenance.

Ne modifiez pas simultanément le VPN, le routage, le NAT et les règles de firewall sans points de test et de restauration définis. Après validation de l’architecture, vérifiez séparément chaque niveau prévu : tunnel/XFRM, voisin, préfixes annoncés, chemins aller et retour, et un service réel.

Distinguer les symptômes

Voisin opérationnel, préfixe manquant

Comparez le type de tunnel, le build de SFOS et show running-config. L’absence de l’ancienne route VPN, une adjacence active et l’absence d’un préfixe reçu sont des observations distinctes. Vérifiez dans la configuration de routage et sur le routeur récepteur si la redistribution dépendait de cette route.

Préfixe présent, trafic perturbé

L’absence de redistribution n’est alors pas la cause immédiate. Examinez séparément Route Lookup, les règles, le NAT et le chemin de retour.

ipsec_route présente, préfixe manquant

system ipsec_route show confirme uniquement l’association manuelle. Cette commande ne confirme ni une route ordinaire du noyau ni une annonce OSPF ou BGP.

Aucune séquence de retour arrière universelle

Sans la topologie précise, aucune séquence sûre ne peut être donnée pour la coexistence, la bascule, le retrait ou le failover. Ces étapes doivent figurer dans le plan de changement convenu avec Sophos Support ; cet article ne fournit délibérément aucune séquence de commandes.

FAQ