Configurer et vérifier BGP sur Sophos Firewall

BGP échange des routes sélectionnées entre des routeurs. Sur Sophos Firewall, il est particulièrement utile pour plusieurs sites, des liaisons redondantes ainsi que des VPN AWS ou Azure. Pour un seul réseau de destination avec un Next Hop fixe, une route statique reste généralement plus simple.

Dans l’exemple suivant, deux Sophos Firewalls établissent une session eBGP via un réseau de transit. À la fin, le Neighbor est Established, Firewall A connaît le LAN derrière Firewall B et inversement.

⚠️ Dynamic Routing ne doit être joignable que par le peer prévu. Une modification du Router ID interrompt toutes les sessions BGP ; une modification du Local AS supprime également tous les Neighbors et Networks configurés. Ces deux changements doivent donc être réalisés dans une fenêtre de maintenance planifiée avec un backup récent.

BGP en sept étapes

Les étapes suivantes sont nécessaires pour une configuration IPv4 simple :

Définir les IP de transit, les ASN local et distant ainsi que les réseaux à annoncer.
Vérifier la joignabilité IP directe entre les deux peers BGP.
Sous Administration > Device access, autoriser Dynamic Routing uniquement pour la zone du peer ou via une Local Service ACL Exception restrictive ; vérifier séparément les règles firewall requises par le design.
Définir Router ID et Local AS sous Routing > BGP.
Ajouter l’IP du peer comme Neighbor avec le Remote AS.
Saisir uniquement les préfixes locaux nécessaires sous Networks.
Sous Routing > Information > BGP-IPv4, vérifier l’état Established, la route apprise puis le trafic réel.

Ce que BGP décide sur le firewall

BGP répond à la question de savoir quels réseaux sont joignables via quel routeur. Chaque participant a besoin de plusieurs valeurs clairement distinctes :

Le Local AS désigne le système autonome local. Deux ASN différents forment une connexion eBGP ; le même ASN des deux côtés correspondrait à iBGP.
Le Remote AS est l’ASN du peer.
Le Router ID identifie le routeur BGP au sein de la topologie BGP. Il ressemble à une adresse IPv4, mais ne doit pas nécessairement être une adresse d’interface et doit rester unique et stable.
Un Neighbor est l’adresse IPv4 ou IPv6 de la contrepartie vers laquelle la session BGP est établie. Dans cet exemple, il s’agit de l’IP de transit.
Un Network est un préfixe local que le firewall doit annoncer au peer.

BGP n’autorise pas le trafic de données et ne le chiffre pas. Dynamic Routing sous Device Access ou une Local Service ACL contrôle le service BGP local. Le trafic acheminé via les routes apprises exige en plus des règles firewall adaptées, un chemin retour et, selon le design, une configuration NAT délibérée.

Pour le routage dynamique au sein d’un même domaine de routage interne, OSPF est souvent plus naturel. BGP convient mieux entre différents systèmes autonomes, avec des fournisseurs cloud ou lorsque les routes doivent être influencées de manière ciblée par des politiques.

Planifier la topologie d’exemple

L’exemple utilise deux sites :

Firewall A : Local AS 65010, Router ID 192.0.2.10, IP de transit 198.51.100.1/30, LAN 10.10.10.0/24
Firewall B : Local AS 65020, Router ID 192.0.2.20, IP de transit 198.51.100.2/30, LAN 10.20.20.0/24
Réseau de transit : 198.51.100.0/30

Les plages 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. Les deux ASN privés conviennent à un exemple interne ; pour une connexion à AWS, Azure ou un fournisseur, utiliser les valeurs ASN et peer imposées par la partie distante.

Le Router ID doit être choisi volontairement, rester unique et stable. Avec Automatic, SFOS utilise l’IP d’interface la plus élevée. Si cette adresse change ultérieurement, l’identité du routeur peut également changer de manière inattendue. Une valeur manuelle évite cette dépendance.

Préparer BGP en toute sécurité

Avant la configuration, les conditions suivantes doivent être remplies :

Le firewall fonctionne en Gateway Mode. BGP n’est pas disponible en Transparent Mode.
Les deux IP de transit se joignent directement. Pour un tunnel XFRM, l’interface de tunnel doit également être up.
Local AS, Remote AS, IP des peers et préfixes autorisés ont été convenus avec la partie distante.
La table de routage locale et les Networks prévus sont documentés afin de pouvoir vérifier précisément chaque annonce après la configuration.
Un backup de configuration récent et un accès de gestion indépendant sont disponibles.
Les règles firewall et les chemins retour du futur trafic de données sont planifiés.

Configurer les zones et interfaces sur Sophos Firewall explique les bases de l’interface de transit et de la zone. Avant toute modification d’un environnement de routage en production, un backup récent du firewall doit également être disponible en dehors de l’appliance.

Autoriser Dynamic Routing de manière ciblée

Sous Administration > Device access, Dynamic Routing est désactivé par défaut pour toutes les zones. Le service peut être activé dans la zone d’un réseau dédié exclusivement au transit.

Si l’interface du peer partage sa zone LAN ou WAN avec d’autres réseaux, une Local Service ACL Exception pour l’IP précise du peer ou le réseau de transit est plus restrictive qu’une autorisation étendue à toute la zone. Sous Administration > Device access > Local service ACL exception rule > Add, créer une règle Accept avec les valeurs appropriées pour IP version, Source zone, Source networks and hosts, Destination hosts, le service Dynamic Routing et Rule position. Tester ensuite l’accès depuis l’IP autorisée du peer et depuis une source non autorisée.

L’aide BGP de Sophos exige aussi des règles firewall pour le trafic BGP entrant et sortant, tandis que l’aide Device Access indique que les services locaux ne sont pas contrôlés par ces règles. Ces formulations ne sont pas parfaitement cohérentes. Il faut donc séparer la Local Service ACL du service BGP local, les règles imposées par le design du tunnel ou du fournisseur et les règles normales du trafic de données routé. Cela ne justifie pas une règle Any-to-Any générale pour TCP 179. Sécuriser Device Access sur Sophos Firewall détaille cette couche.

Configurer BGP dans WebAdmin

Les étapes suivantes sont effectuées sur les deux firewalls. Seules les valeurs locales et distantes sont inversées.

1. Définir Router ID et Local AS

Sous Routing > BGP, saisir les valeurs suivantes dans Global configuration sur Firewall A :

Si une configuration BGP existe déjà, documenter l’état actuel avant d’appliquer les modifications : un changement du Router ID réinitialise toutes les sessions BGP ; un changement du Local AS supprime tous les Neighbors et Networks. Ces modifications ne sont appliquées que dans une fenêtre de maintenance planifiée.

Router ID assignment : Manual
Router ID : 192.0.2.10
Local AS : 65010

Sur Firewall B, utiliser également Manual, avec 192.0.2.20 et 65020. Appliquer ensuite la configuration globale.

Local AS accepte des valeurs de 1 à 4294967295. Pour les environnements internes sans ASN public, Sophos indique la plage privée de 64512 à 65535.

2. Ajouter le peer comme Neighbor

Sous Routing > BGP > Neighbors, cliquer sur Add et saisir sur Firewall A :

IP version : IPv4
IP address : 198.51.100.2
Remote AS : 65020

Firewall B utilise 198.51.100.1 comme Neighbor et 65010 comme Remote AS. Enregistrer chaque entrée avec Save.

L’adresse du Neighbor n’est ni le LAN distant ni le Router ID, mais l’IP de transit directement joignable du peer. Si cette IP n’est pas joignable ou si les ASN sont inversés, la session ne peut pas atteindre Established.

3. Annoncer le LAN local

Sous Routing > BGP > Networks, cliquer sur Add. Firewall A annonce :

IP version : IPv4
IP address : 10.10.10.0
Subnet mask : 255.255.255.0 (/24)

Sur Firewall B, saisir à la place 10.20.20.0 et 255.255.255.0 (/24).

L’entrée Network définit le préfixe que BGP doit annoncer ; elle ne remplace ni la route locale ni une règle firewall. Après l’enregistrement, vérifier le préfixe annoncé et celui reçu par la contrepartie. Seuls les préfixes nécessaires doivent figurer ici.

Comprendre les Neighbors et réseaux IPv6

SFOS prend également en charge IPv6 sous Neighbors et Networks. L’exemple précédent reste volontairement en IPv4 ; pour IPv6, saisir séparément la version IP, une adresse IPv6 de peer directement joignable et le préfixe IPv6.

WebAdmin ajoute automatiquement la séparation nécessaire. Dans une configuration exclusivement CLI, les defaults sont asymétriques : les Networks IPv4 sont initialement activés pour tous les Neighbors, y compris IPv6. Les Networks IPv6 ne sont activés pour aucun Neighbor. Pour un Neighbor IPv6, définir explicitement ces états :

address-family ipv4 unicast
no neighbor <ipv6-neighbor> activate
exit
address-family ipv6 unicast
neighbor <ipv6-neighbor> activate

Pour reproduire les defaults WebAdmin en CLI, Sophos indique aussi no bgp ebgp-requires-policy et bgp log-neighbor-changes. show running-config n’affiche que les valeurs différentes des defaults ; une Router ID automatique et, par exemple, maximum-paths ibgp 16 peuvent ne pas apparaître. Valider IPv4 et IPv6 séparément sous Routing > Information > BGP-IPv4 et BGP-IPv6, avec leurs règles IPv6 et chemins retour.

Vérifier et valider BGP

Une session établie ne confirme pas à elle seule que le flux de paquets fonctionne. La validation s’effectue donc à plusieurs niveaux :

Sous Routing > Information > BGP-IPv4 > Neighbors, le peer doit apparaître dans l’état Established.
Sous Routes, Firewall A doit afficher le préfixe 10.20.20.0/24 ; Firewall B doit afficher 10.10.10.0/24.
Sous Summary, vérifier la session et le nombre de préfixes reçus.
Sous Diagnostics > Tools > Route lookup, vérifier par exemple la destination 10.20.20.10 sur Firewall A.
Tester ensuite un service réel entre un hôte de chaque LAN. Log Viewer et Packet Capture doivent montrer la règle attendue, la bonne interface de transit et le trafic retour.

Un Neighbor Established prouve uniquement que l’échange BGP fonctionne. La route apprise, un Route Lookup correct et une connexion réelle sont nécessaires pour valider l’ensemble de la configuration. Tester une règle Sophos Firewall avec Log Viewer et Packet Capture aide à vérifier le flux de paquets.

Le même exemple via la CLI

Comme alternative à WebAdmin, la même configuration de base peut être saisie dans la CLI de routage après la connexion SSH. Ne pas exécuter les commandes suivantes sur un environnement d’exemple déjà configuré. Sauvegarder l’état actuel avant toute modification ; un changement d’ASN supprime Neighbors et Networks et exige un backup et une fenêtre de maintenance. L’accès dépend de la version SFOS.

SFOS 22 : le chemin de menu suivant ouvre bgp>. Seul cet accès commence par enable :

3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP

Sur Firewall A sans ASN encore attribué :

enable
configure terminal
router bgp 65010

SFOS 23 : 3. Route Configuration > 1. Configure Unicast Routing ouvre directement router# ; ni le troisième choix de menu ni enable ne font partie de cet accès. Pour la première attribution de l’ASN sur Firewall A :

configure terminal
router bgp 65010

Si l’ASN est déjà attribué dans SFOS 23, utiliser plutôt router bgp sans ASN après configure terminal pour sélectionner la configuration existante. router bgp 65010 sert à l’attribution initiale ou à un changement d’ASN planifié, pas à une réattribution incontrôlée.

Après une seule de ces séquences d’accès, poursuivre en mode de configuration BGP :

no bgp ebgp-requires-policy
bgp log-neighbor-changes
bgp router-id 192.0.2.10
neighbor 198.51.100.2 remote-as 65020
address-family ipv4 unicast
network 10.10.10.0/24
exit
end
show running-config
write

Sur Firewall B, remplacer Local AS, Router ID, Neighbor, Remote AS et Network respectivement par 65020, 192.0.2.20, 198.51.100.1, 65010 et 10.20.20.0/24.

show running-config sert au contrôle. write enregistre durablement la configuration CLI, rend les entrées visibles dans WebAdmin et les conserve après un redémarrage. Sans write, la modification n’est pas complètement terminée.

end quitte le mode de configuration avant ces deux commandes. Pour SFOS 23, Sophos documente la confirmation d’enregistrement attendue Integrated configuration saved to /conf/routing/frr.conf ; il ne s’agit pas d’une sortie observée ici sur une appliance. Comparer ensuite la configuration et les entrées WebAdmin aux valeurs prévues.

Le contrôle supplémentaire officiellement documenté est :

show ip bgp

Il affiche les préfixes BGP connus et les informations de chemin associées. L’état du Neighbor et le Summary se vérifient de manière fiable sous Routing > Information > BGP-IPv4.

⚠️ Ne pas mélanger sans contrôle la configuration CLI avancée et WebAdmin. La modification d’un Neighbor dans WebAdmin peut supprimer des valeurs CLI supplémentaires telles qu’un mot de passe de Neighbor ou une Route Map. Dès que de tels réglages sont utilisés, sauvegarder d’abord show running-config et continuer à gérer la configuration BGP via la CLI.

SFOS 23.0 : BFD expérimental pour BGP

Bidirectional Forwarding Detection (BFD) surveille la joignabilité d’un Neighbor BGP au moyen de ses propres paquets de contrôle. Le firewall peut ainsi détecter une panne plus tôt qu’avec les seuls timers BGP. Cette procédure optionnelle ne fait pas partie de la configuration BGP de base précédente et ne s’applique pas aux versions antérieures de SFOS.

⚠️ Dans SFOS 23.0, BFD est expérimental. L’utilisation documentée concerne BGP dans des déploiements standalone ; cela ne constitue pas une validation pour les clusters HA ou d’autres protocoles de routage. Pour les autres protocoles, il faut faire appel à Sophos Support. Avanet recommande de commencer dans un environnement de test isolé. BFD ne doit pas être activé en production sans procédure de retour arrière confirmée pour le build installé.

Périmètre et préparation

Sophos cite les Neighbors BGP-IPv4 et BGP-IPv6, ainsi que les Neighbors eBGP, iBGP, eBGP multihop et Route Reflector, comme cas d’utilisation de BFD. L’exemple suivant reste limité au Neighbor IPv4 198.51.100.2 déjà configuré sur Firewall A. Il ne constitue pas une garantie supplémentaire pour un service VPN cloud particulier ou une topologie multihop précise.

Avant de commencer, la session BGP, les préfixes attendus et le trafic applicatif doivent fonctionner sans BFD. La contrepartie doit être préparée pour BFD ; les adresses des peers, leur joignabilité et les timers doivent être convenus avec son administrateur. Consigner le build SFOS actuel, sauvegarder show running-config, l’état du Neighbor et le résultat du Route Lookup, puis prévoir un backup, une fenêtre de maintenance et un accès de gestion indépendant. Avant toute modification, confirmer avec Sophos Support, pour ce build, la procédure de suppression de l’association BFD au Neighbor, d’un éventuel profil de peer supplémentaire et du service. Le guide BFD ne documente pas de commandes complètes de suppression ou d’arrêt pour ces opérations.

Si le Neighbor surveillé devient injoignable, le firewall retire immédiatement de la table de routage toutes les routes apprises de ce Neighbor. Le trafic ne peut basculer vers un autre chemin que si celui-ci existe ; sans chemin alternatif, les réseaux concernés perdent leur route. Au retour du Neighbor, Sophos décrit le rétablissement des routes et le retour au chemin initial. Il faut donc vérifier à la fois la panne et le rétablissement, y compris la route effectivement sélectionnée.

Démarrer le service et surveiller le Neighbor

Le service BFD est désactivé par défaut. Les commandes suivantes modifient le fonctionnement du routage ; avant de les exécuter, l’état initial sauvegardé et la procédure de retour arrière confirmée doivent être disponibles. Dans la CLI, accéder à 5. Device Management > 3. Advanced shell, puis y démarrer le service :

service -ds nosync bfdd:start

Ensuite, dans la même Advanced Shell, passer à la CLI de routage avec vtysh :

vtysh

Dans la CLI de routage, ajouter l’association BFD au Neighbor déjà existant sur Firewall A. Router ID, Local AS, Remote AS et Networks restent inchangés :

configure terminal
router bgp
neighbor 198.51.100.2 bfd
end
write

Remplacer 198.51.100.2 par l’adresse réelle du Neighbor, et non par son LAN ou son Router ID. Sur Firewall B, l’adresse correspondante dans l’exemple est 198.51.100.1. La contrepartie est configurée conformément à la documentation de son propre produit. Si le Neighbor BGP n’existe pas encore, terminer d’abord la configuration BGP de base de cet article ; BFD ne la remplace pas. write enregistre la configuration de routage, mais ne prouve ni qu’une session BFD fonctionne ni que le service démarrera automatiquement après un redémarrage.

Ne modifier les timers qu’en cas de besoin justifié

Pour le premier test, Avanet recommande les valeurs par défaut documentées : Detect multiplier 3, Transmit interval 300 ms et Receive interval 300 ms. Des intervalles très courts ou un multiplicateur trop sensible peuvent augmenter la charge de traitement. Ces valeurs ne garantissent pas un délai de basculement fixe.

Les timers sont définis dans la configuration BFD, et non dans la commande du Neighbor BGP. Si un profil de peer explicite est nécessaire, ce bloc dans la CLI de routage présente les valeurs par défaut documentées pour le même peer d’exemple :

configure terminal
bfd
peer 198.51.100.2
 detect-multiplier 3
 transmit-interval 300
 receive-interval 300
end
write

peer démarre la surveillance du peer avec les timers par défaut ; ce bloc supplémentaire n’est pas nécessaire pour configurer uniquement l’association BGP. Pour detect-multiplier, Sophos documente la plage 1–155 ; pour les deux intervalles, la plage est 10–4294967 ms. La valeur Transmit désigne l’intervalle minimal d’émission sans jitter, tandis que la valeur Receive désigne l’intervalle minimal de réception attendu. La contrepartie calcule son délai de détection à partir du multiplicateur local et de la plus grande des deux valeurs suivantes : l’intervalle d’émission local et l’intervalle de réception distant. Il faut donc coordonner les deux côtés plutôt que de choisir uniquement la valeur locale la plus faible possible. Ajouter des timers directement après neighbor … bfd n’est pas une syntaxe valide.

Valider ensemble BFD, les routes et l’application

Dans la CLI de routage, ces deux commandes de vérification sont en lecture seule :

show bfd peers
show bfd peers brief

Pour le peer prévu, l’état attendu est Status: up. La sortie détaillée doit afficher des timers locaux et distants cohérents, ainsi que Diagnostics: ok et Remote diagnostics: ok ; la vue abrégée associe l’adresse du peer à son état. Vérifier ensuite à nouveau la session BGP sous Routing > Information > BGP-IPv4 ou BGP-IPv6, les préfixes attendus, le Route Lookup et le trafic applicatif réel. BFD up ne confirme à lui seul ni la bonne route BGP ni le chemin de données.

Ne réaliser un test de panne que dans un environnement de test approuvé ou pendant une fenêtre de maintenance planifiée, sans compromettre l’accès de gestion indépendant. Consigner au préalable les préfixes appris du Neighbor surveillé et le chemin de remplacement prévu. Pendant la panne contrôlée du peer, les routes concernées doivent disparaître et, si un chemin de remplacement existe, la route de remplacement et le trafic applicatif doivent fonctionner. Après le rétablissement, vérifier à nouveau BFD up, BGP, les préfixes rétablis, le chemin sélectionné et l’application. Aucune sortie d’un équipement ni aucun basculement réussi ne sont présentés ici comme ayant déjà été testés.

Isoler les erreurs et annuler la modification

Le peer manque ou reste down : vérifier le démarrage du service et l’association BFD dans show running-config, puis comparer l’adresse réelle du peer, sa joignabilité et la configuration BFD de la contrepartie. Relever les diagnostics locaux et distants ainsi que les timers avec show bfd peers. Ne pas ajouter une autorisation Any-to-Any étendue comme solution générale ; si les exigences d’accès ne sont pas claires, faire appel à Sophos Support.
BFD ne fonctionne plus après une modification : des changements apportés aux paramètres associés, tels que l’adresse de destination ou le Remote Gateway, peuvent supprimer les paramètres BFD. Comparer la configuration à l’état sauvegardé, reconfigurer BFD pour le Neighbor concerné et effectuer à nouveau une validation complète.
Session instable ou charge accrue après une modification des timers : dans le même contexte de peer BFD, rétablir les valeurs précédemment consignées et les enregistrer avec write. Si l’état initial correspondait au profil par défaut, le bloc ci-dessus indique 3 et 300 ms. Vérifier ensuite les diagnostics des deux peers, les routes BGP et le trafic avant de modifier d’autres valeurs.
Retour arrière complet : appliquer uniquement le plan de retour arrière préalablement confirmé pour ce build, puis comparer la configuration BGP sans BFD à l’état initial sauvegardé. Ni une commande no inventée ni un arrêt systématique du service ne remplacent ce plan. Supprimer le Neighbor BGP entier ne serait pas un rollback BFD équivalent, car cela supprimerait également ses routes. Ne terminer le retour arrière que lorsque la session BGP, les préfixes nécessaires, l’accès de gestion et l’application sont à nouveau dans l’état prévu.

Weight, MED et Route Precedence globale

La Route Precedence globale ordonne static, sdwan_policyroute et vpn. Elle doit être distinguée des attributs de sélection BGP. system route_precedence show affiche sa valeur ; ne la modifier que si ces catégories sont réellement en concurrence. Ajuster la priorité de routage sur Sophos Firewall explique la vérification et le retour arrière.

L’Administrative Distance est l’un des facteurs utilisés pour choisir entre différents protocoles de routage. Au sein de BGP, les attributs BGP sont évalués. Sophos indique par exemple qu’un Weight plus élevé est préféré ; entre des chemins par ailleurs comparables, un MED plus faible est préféré.

Ce point est particulièrement important lorsque le même préfixe est disponible via redistribute ospf et également appris d’un Neighbor BGP. Par défaut, la route redistribuée générée localement a un Weight de 32768, tandis que la route apprise du Neighbor a un Weight de 0. Sans ajustement volontaire, la route redistribuée l’emporte donc. Pour privilégier le chemin par le peer, augmenter son Weight, puis vérifier la route obtenue.

Utiliser MED pour plusieurs chemins d’entrée

SFOS 23 : vérifier les noms au préalable. Avant de créer ou de réutiliser des Access Lists, Prefix Lists ou Route Maps, inventorier leurs noms dans tous les protocoles de routage dynamique. Ils sont stockés dans un même fichier de configuration et les noms doivent être uniques entre protocoles. Éviter les collisions et vérifier les associations Neighbor/policy prévues par rapport à la configuration actuelle et sauvegardée. Cette condition ne remplace pas le plan de retour arrière MED confirmé pour le build installé exigé ci-dessous ; la configuration MED exécutable reste suspendue jusqu’à cette confirmation.

Mise à niveau vers SFOS 23.0 : À partir de cette version, tous les protocoles de routage dynamique utilisent une configuration intégrée. Lors d’une mise à niveau depuis une version antérieure, le firewall ajoute automatiquement des préfixes de protocole aux noms des Route Maps, Prefix Lists et Access Lists, mais uniquement en cas de conflit de noms. Il met également à jour automatiquement toutes les références aux configurations renommées. Cela ne signifie pas que tous les objets sont renommés.

Après la mise à niveau, comparer les noms d’objets et les références sauvegardés au préalable avec le show running-config actuel et consigner la correspondance entre les anciens noms et les noms actuels. Vérifier que les associations Neighbor/Route Map prévues pointent toujours vers les bonnes policies, y compris les associations MED existantes. Ne pas rétablir aveuglément les anciens noms. Sous Routing > Information > BGP-IPv4 > Routes et avec show ip bgp sur la contrepartie, vérifier que les préfixes réseau attendus sont présents, que les préfixes interdits sont absents et que le chemin prévu est sélectionné ; contrôler aussi le chemin réellement utilisé avec Route Lookup. Cette vérification ne remplace pas le plan de retour arrière MED exigé ci-dessous pour le build installé et ne lève pas la suspension de la configuration MED.

Le Multi-Exit Discriminator (MED) indique à un AS voisin direct lequel de plusieurs chemins d’entrée dans l’AS local il doit préférer. Un MED inférieur est meilleur et la valeur par défaut est 0. Une valeur supérieure est donc annoncée sur le chemin le moins souhaité. Par défaut, MED n’est comparé que lorsque le même préfixe est appris par plusieurs liens depuis le même AS voisin.

MED est non transitif. Si l’AS récepteur transmet la route à un autre AS, la valeur revient à 0. BGP évalue d’abord Weight, Local Preference, origine locale, longueur de l’AS Path et Origin Type. MED ne décide que si ces attributs sont égaux. Une valeur configurée ne prouve donc pas que le chemin souhaité gagne.

Sophos définit MED au moyen d’une Route Map sortante dotée d’un numéro de séquence fixe, puis l’associe à un Neighbor précis dans l’IPv4 Address Family. out modifie l’annonce envoyée à ce peer ; il n’impose pas directement le chemin de sortie du trafic de Sophos Firewall. La page officielle de SFOS 22 documente la mise en place, mais pas de procédure complète de retour arrière. N’appliquer la modification qu’après avoir confirmé séparément les commandes de suppression exactes pour la version installée et les avoir consignées dans un plan de restauration avec le show running-config préalablement sauvegardé.

Après une modification approuvée, show ip bgp sur le routeur récepteur doit afficher le MED attendu et le chemin privilégié. Sur un peer Sophos, la route apparaît également sous Routing > Information > BGP-IPv4 > Routes. Sans cette comparaison avant/après, cette section reste une aide à la décision et non une modification de production directement exécutable.

BGP via IPsec route-based et VPN cloud

BGP peut fonctionner via une interface XFRM adressée d’un tunnel IPsec site-to-site route-based. Les deux interfaces XFRM reçoivent des IP de transit adaptées. Dynamic Routing est autorisé de manière ciblée pour la zone VPN ; les règles du trafic de données restent néanmoins nécessaires.

Pour les connexions cloud, les valeurs ne sont pas choisies librement :

Pour AWS Site-to-Site VPN, les adresses inside du tunnel, le Remote AS et les autres valeurs proviennent de la configuration AWS. Les deux tunnels AWS sont vérifiés séparément.
Pour Azure VPN Gateway, l’IP XFRM locale doit correspondre à l’IP de peer BGP prévue ; les ASN local et Azure doivent être différents.

Un tunnel IPsec vert et un Neighbor BGP Established constituent deux contrôles distincts. Les préfixes attendus et le trafic applicatif réel doivent ensuite fonctionner.

Isoler les erreurs méthodiquement

Neighbor reste sur Active ou n’apparaît pas

Active ne signifie pas que la session fonctionne. Le firewall essaie encore d’établir une connexion BGP. Vérifier d’abord la joignabilité directe de l’IP du peer, l’état de l’interface et du tunnel, Local AS, Remote AS et l’IP du Neighbor. Contrôler ensuite si Dynamic Routing est autorisé dans la bonne zone ou via une Local Service ACL Exception appropriée.

Pour XFRM, vérifier également que les deux adresses de tunnel sont correctes et que le tunnel IPsec est up. Pour les configurations cloud et XFRM, contrôler aussi les règles prévues par le design VPN concerné. Si leurs services sont restreints, elles doivent inclure TCP 179 entre les deux IP des peers. Device Access ou la Local Service ACL du service BGP local reste distinct de ces règles.

Neighbor est Established, mais le réseau distant manque

La session fonctionne, mais le préfixe n’est pas annoncé ou accepté. Vérifier l’entrée Network, sa version IP, son masque et show running-config, puis Routes et Summary sur la contrepartie pour savoir si une policy le rejette.

Si un réseau derrière un tunnel IPsec policy-based disparaît après une mise à niveau vers SFOS 22, l’ancienne dépendance à redistribute kernel peut en être la cause. La session BGP peut rester Established ; SFOS 22 : routes IPsec et redistribute kernel explique le changement de version et l’architecture cible XFRM route-based.

La route BGP est visible, mais n’est pas utilisée

Utiliser d’abord Route Lookup pour déterminer quelle route gagne pour une IP de destination précise. Une route plus spécifique est prioritaire sur un préfixe plus large. Si plusieurs sources sont en concurrence, évaluer séparément l’Administrative Distance et les attributs BGP, puis seulement la catégorie globale Route Precedence.

La route est correcte, mais le trafic ne fonctionne pas

BGP a rempli son rôle dès que la bonne route est installée. Les erreurs se situent ensuite généralement dans la règle firewall, le NAT, le chemin retour ou le système de destination. Dans des réseaux de sites routés normalement, le SNAT est souvent inutile, car les deux côtés doivent connaître les préfixes LAN réels.

Des réglages avancés ont disparu après une modification WebAdmin

WebAdmin ne représente que les valeurs de base. Si un Neighbor y a été enregistré après une configuration CLI avancée, son mot de passe, sa Route Map ou des valeurs par défaut modifiées peuvent avoir été supprimés. L’application de la Global configuration supprime également les modifications apportées à bgp log-neighbor-changes et no bgp ebgp-requires-policy. Comparer la configuration sauvegardée, restaurer les valeurs via la CLI et les enregistrer avec write.

Associer les logs BGP et de routage

La référence des logs de SFOS 22 associe BGP et BGPv6 au fichier bgpd.log. zebra.log concerne l’installation des routes dynamiques IPv4 et IPv6 dans le noyau ; pour un tunnel IPsec route-based, xfrmi.log concerne l’interface de tunnel XFRM. Cette correspondance permet de procéder par étapes : vérifier d’abord la session BGP et l’annonce, puis l’intégration dans la table de routage du système et, si nécessaire, l’état du tunnel. Services et fichiers de logs de Sophos Firewall explique comment accéder à ces fichiers et à d’autres logs. Aucune commande Live Shell non documentée n’est nécessaire pour cette validation.

Annuler la modification en toute sécurité

Avant de supprimer BGP, un chemin alternatif ou une fenêtre de maintenance doit exister pour chaque réseau de destination appris. Supprimer d’abord les Networks et Neighbors concernés. Ne modifier ensuite la configuration BGP globale que si aucun autre peer n’en dépend. Dynamic Routing ne doit être désactivé que si la zone n’a plus besoin d’un autre service de routage dynamique.

Dans WebAdmin, supprimer d’abord les annonces inutiles sous Routing > BGP > Networks, puis les contreparties sous Neighbors. Vérifier les routes de remplacement après chaque étape. Laisser Router ID et Local AS inchangés tant que d’autres connexions BGP en dépendent ; une modification du Local AS supprimerait tous les Neighbors et Networks restants.

Les pages de présentation BGP vérifiées pour SFOS 22 et 23 affichent bien une syntaxe de désactivation de la configuration de routage BGP. Cela ne valide toutefois ni le contexte d’exécution complet ni un retour arrière sûr pour le build installé. La syntaxe anormale de la source n’est ni reprise comme commande exécutable ni corrigée silencieusement ; aucun arrêt confirmé du daemon ni aucune suppression du processus n’en sont déduits. Aucune commande CLI destructive n’est recommandée. Les policies CLI avancées exigent des commandes de suppression confirmées pour le build installé et le bloc de configuration précédent sauvegardé.

Vérifier ensuite à nouveau Routing Information, Route Lookup, l’accès de gestion et le trafic réel. Un rollback n’est terminé que lorsque la session BGP a disparu et que tous les réseaux de destination nécessaires restent joignables via le chemin de remplacement prévu.