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.
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’IP directement joignable du peer avec laquelle la session BGP est établie.
Un Network est un préfixe local que le firewall doit annoncer au peer.

BGP n’autorise aucun trafic utile et ne le chiffre pas. La session BGP elle-même est établie via TCP 179 et autorisée vers le firewall par Device Access ou une Local Service ACL. Le trafic utile qui emprunte une route apprise nécessite toujours des règles firewall appropriées, un chemin retour fonctionnel et, selon le design, une configuration NAT volontaire.

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.
Les réseaux à annoncer existent déjà comme routes correspondantes dans la table de routage locale.
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 utile 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 sûre qu’une autorisation large de toute la zone. Sous Administration > Device access > Local service ACL exception rule > Add, créer une règle Accept pour la zone du peer, l’IP précise du peer ou un réseau de transit restrictif, l’adresse firewall requise et le service Dynamic Routing. Tester ensuite l’accès depuis l’IP autorisée du peer et depuis une source non autorisée.

Device Access contrôle uniquement la connexion BGP vers le firewall. Les connexions de production entre les deux LAN nécessitent ensuite des règles firewall normales. Sécuriser Device Access sur Sophos Firewall explique cette séparation.

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).

Un Network ne crée pas de route. Le préfixe exact doit déjà exister dans la table de routage locale, par exemple comme réseau directement connecté ou route statique. S’il manque ou si le masque diffère, la session BGP peut rester Established, mais le Network n’est pas annoncé.

Seuls les préfixes réellement nécessaires doivent être saisis. Une redistribution globale des routes connectées ou statiques peut également inclure des réseaux WAN, de management ou blackhole et ne doit être utilisée en production qu’avec un filtrage vérifié.

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 BGP après la connexion SSH. Les commandes suivantes ne sont pas exécutées en plus sur un environnement d’exemple déjà entièrement configuré. Le chemin de menu est :

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

Sur Firewall A, l’exemple complet se présente comme suit :

enable
configure terminal
router bgp 65010
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
show running-config
write
end

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.

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.

Route Precedence et sélection du chemin BGP

system route_precedence ne décide pas entre BGP et une route statique. Le réglage global ordonne uniquement les catégories static, sdwan_policyroute et vpn ; BGP et les autres routes dynamiques appartiennent dans ce contexte à la catégorie static.

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é.

Afficher l’ordre global actuel dans 4. Device Console :

system route_precedence show

Il ne doit être modifié que lorsque des catégories de routage sont réellement en concurrence. Ajuster la priorité de routage sur Sophos Firewall explique les relations et donne des exemples sûrs.

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 utile 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é. Sur le firewall émetteur, le Network doit exister dans la table de routage locale avec exactement le même masque. Vérifier ensuite Networks, les filtres et show running-config. Une route locale manquante doit être corrigée et non masquée en désactivant BGP Network Import Check.

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. Comparer la configuration sauvegardée, restaurer les valeurs via la CLI et les enregistrer avec write.

Vérifier les logs BGP et de routage

Dans 5. Device Management > 3. Advanced Shell, deux fichiers de log montrent les différents niveaux :

tail -f /log/bgpd.log

bgpd.log consigne les événements BGP et BGPv6. Arrêter l’affichage en direct avec Ctrl+C. Si BGP connaît une route mais qu’elle n’apparaît pas dans le système, poursuivre avec :

tail -f /log/zebra.log

Pour lire le log sans le suivre en direct, utiliser par exemple :

less /log/bgpd.log

Pour IPsec route-based, /log/xfrmi.log peut également expliquer l’état de l’interface XFRM. Services et fichiers de log Sophos Firewall classe les autres fichiers.

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.

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.