Sophos Firewall BGP konfigurieren und prüfen

BGP tauscht ausgewählte Routen zwischen Routern aus. Auf einer Sophos Firewall ist das besonders bei mehreren Standorten, redundanten Verbindungen sowie AWS- oder Azure-VPNs sinnvoll. Für ein einzelnes Zielnetz mit festem Next Hop bleibt eine statische Route meist einfacher.

Im folgenden Beispiel bilden zwei Sophos Firewalls über ein Transitnetz eine eBGP-Session. Am Ende steht der Neighbor auf Established, Firewall A kennt das LAN hinter Firewall B und umgekehrt.

⚠️ Dynamic Routing sollte nur für die vorgesehene Gegenstelle erreichbar sein. Eine Änderung der Router ID unterbricht alle BGP-Sessions; eine Änderung der Local AS löscht zusätzlich alle konfigurierten Neighbors und Networks. Beides gehört deshalb in ein geplantes Wartungsfenster mit aktuellem Backup.

BGP in sieben Schritten

Für einen einfachen IPv4-Aufbau sind diese Schritte nötig:

Transit-IPs, lokale und entfernte ASN sowie die anzukündigenden Netze festlegen.
Die direkte IP-Erreichbarkeit zwischen den beiden BGP-Peers prüfen.
Unter Administration > Device access Dynamic Routing nur für die Peer-Zone beziehungsweise über eine enge Local Service ACL Exception erlauben und die für das eigene Design nötigen Firewall-Regeln getrennt prüfen.
Unter Routing > BGP Router ID und Local AS setzen.
Die Peer-IP als Neighbor mit der Remote AS hinzufügen.
Nur die benötigten lokalen Präfixe unter Networks eintragen.
Unter Routing > Information > BGP-IPv4 den State Established, die gelernte Route und anschliessend echten Traffic prüfen.

Was BGP auf der Firewall entscheidet

BGP beantwortet die Frage, welche Netze über welchen Router erreichbar sind. Dafür benötigt jeder Teilnehmer einige klar getrennte Werte:

Die Local AS bezeichnet das eigene autonome System. Zwei unterschiedliche ASNs bilden eine eBGP-Verbindung; dieselbe ASN auf beiden Seiten wäre iBGP.
Die Remote AS ist die ASN der Gegenstelle.
Die Router ID identifiziert den BGP-Router innerhalb der BGP-Topologie. Sie sieht wie eine IPv4-Adresse aus, muss aber keine Interface-Adresse sein und sollte eindeutig sowie stabil bleiben.
Ein Neighbor ist die IPv4- oder IPv6-Adresse der Gegenstelle, zu der die BGP-Session aufgebaut wird. Im direkt verbundenen Beispiel ist das die Transit-IP.
Ein Network ist ein lokales Präfix, das die Firewall der Gegenstelle ankündigen soll.

BGP gibt keinen Nutzdatenverkehr frei und verschlüsselt ihn nicht. Dynamic Routing unter Device Access beziehungsweise eine Local Service ACL steuert den lokalen BGP-Dienst der Firewall. Der Verkehr, den die Firewall über gelernte Routen weiterleitet, benötigt zusätzlich passende Firewall-Regeln, einen funktionierenden Rückweg und je nach Design eine bewusste NAT-Konfiguration.

Für dynamisches Routing innerhalb einer zusammenhängenden internen Routing-Domain ist OSPF häufig naheliegender. BGP passt besser zwischen unterschiedlichen autonomen Systemen, zu Cloud-Anbietern oder wenn Routen gezielt mit Richtlinien beeinflusst werden müssen.

Beispieltopologie planen

Das Beispiel verwendet zwei Standorte:

Firewall A: Local AS 65010, Router ID 192.0.2.10, Transit-IP 198.51.100.1/30, LAN 10.10.10.0/24
Firewall B: Local AS 65020, Router ID 192.0.2.20, Transit-IP 198.51.100.2/30, LAN 10.20.20.0/24
Transitnetz: 198.51.100.0/30

Die Bereiche 192.0.2.0/24 und 198.51.100.0/24 sind Dokumentationsnetze. Sie werden durch die tatsächlichen Werte der Umgebung ersetzt. Die beiden privaten ASNs sind für ein internes Beispiel geeignet; bei einer Verbindung zu AWS, Azure oder einem Provider werden die von der Gegenstelle vorgegebenen ASN- und Peer-Werte verwendet.

Die Router ID sollte bewusst gewählt, eindeutig und stabil sein. Bei Automatic verwendet SFOS die höchste Interface-IP. Ändert sich diese später, kann sich auch die Identität des Routers unerwartet ändern. Ein manueller Wert vermeidet diese Abhängigkeit.

BGP sicher vorbereiten

Vor der Konfiguration sollten folgende Punkte erfüllt sein:

Die Firewall läuft im Gateway Mode. Im Transparent Mode ist BGP nicht verfügbar.
Beide Transit-IPs erreichen sich direkt. Bei einem XFRM-Tunnel muss auch das Tunnelinterface up sein.
Local AS, Remote AS, Peer-IPs und die erlaubten Präfixe sind mit der Gegenstelle abgestimmt.
Die lokale Routingtabelle und die geplanten Networks sind dokumentiert, damit nach der Konfiguration jede Ankündigung gezielt geprüft werden kann.
Ein aktuelles Konfigurationsbackup und ein unabhängiger Managementzugang sind vorhanden.
Firewall-Regeln und Rückwege für den späteren Nutzdatenverkehr sind geplant.

Die Grundlagen für Transitinterface und Zone erklärt Sophos Firewall Zonen und Interfaces konfigurieren. Vor einer Änderung an einer produktiven Routingumgebung sollte ausserdem ein aktuelles Firewall-Backup ausserhalb der Appliance verfügbar sein.

Dynamic Routing gezielt freigeben

Unter Administration > Device access ist Dynamic Routing standardmässig für alle Zonen deaktiviert. Für ein eigenes, ausschliesslich als Transit verwendetes Netz kann der Dienst in dessen Zone aktiviert werden.

Teilt das Peer-Interface seine LAN- oder WAN-Zone mit weiteren Netzen, ist eine Local Service ACL Exception für die konkrete Peer-IP beziehungsweise das Transitnetz enger als die breite Zonenfreigabe. Unter Administration > Device access > Local service ACL exception rule > Add wird dafür eine Accept-Regel mit IP version, Source zone, Source networks and hosts, Destination hosts, dem Service Dynamic Routing und der passenden Rule position erstellt. Danach den Zugriff von der erlaubten Peer-IP und einer nicht erlaubten Quelle prüfen.

Die Sophos-BGP-Hilfe fordert zusätzlich Firewall-Regeln für ein- und ausgehenden BGP-Traffic. Die Device-Access-Hilfe sagt zugleich, dass lokale Dienste nicht mit Firewall-Regeln gesteuert werden. Diese Formulierungen sind nicht eindeutig deckungsgleich. Verlässlich getrennt werden deshalb die Local Service ACL für den lokalen BGP-Dienst, die vom jeweiligen Tunnel- oder Providerdesign verlangten Regeln und die normalen Regeln für den gerouteten Nutzdatenverkehr. Eine pauschale Any-to-Any-Regel für TCP 179 ist daraus nicht abzuleiten. Device Access auf Sophos Firewall absichern erklärt die lokale Zugriffsebene ausführlicher.

BGP im WebAdmin konfigurieren

Die folgenden Schritte werden auf beiden Firewalls ausgeführt. Nur die lokalen und entfernten Werte werden vertauscht.

1. Router ID und Local AS setzen

Unter Routing > BGP in Global configuration auf Firewall A folgende Werte eintragen:

Besteht bereits eine BGP-Konfiguration, muss der aktuelle Stand vor dem Übernehmen dokumentiert werden: Eine geänderte Router ID setzt alle BGP-Sessions zurück; eine geänderte Local AS löscht alle Neighbors und Networks. Solche Änderungen werden nur in einem geplanten Wartungsfenster übernommen.

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

Auf Firewall B werden ebenfalls Manual sowie 192.0.2.20 und 65020 verwendet. Anschliessend die globale Konfiguration übernehmen.

Die Local AS akzeptiert Werte von 1 bis 4294967295. Für interne Umgebungen ohne öffentliche ASN nennt Sophos den privaten Bereich 64512 bis 65535.

2. Gegenstelle als Neighbor hinzufügen

Unter Routing > BGP > Neighbors auf Add klicken und auf Firewall A eintragen:

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

Firewall B verwendet als Neighbor 198.51.100.1 und als Remote AS 65010. Danach jeweils mit Save speichern.

Die Neighbor-Adresse ist nicht das entfernte LAN und nicht die Router ID, sondern die direkt erreichbare Transit-IP der Gegenstelle. Wenn diese IP nicht erreichbar ist oder die ASNs vertauscht sind, kann die Session nicht Established erreichen.

3. Lokales LAN ankündigen

Unter Routing > BGP > Networks auf Add klicken. Firewall A kündigt an:

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

Auf Firewall B werden stattdessen 10.20.20.0 und 255.255.255.0 (/24) eingetragen.

Der Network-Eintrag legt fest, welches Präfix BGP ankündigen soll; er ersetzt weder die lokale Route noch eine Firewall-Regel. Nach dem Speichern wird deshalb nicht nur die Session, sondern auch das angekündigte und auf der Gegenstelle empfangene Präfix geprüft. Nur tatsächlich benötigte Präfixe gehören in diese Liste.

IPv6-Nachbarn und -Netze einordnen

SFOS unterstützt unter Neighbors und Networks auch IPv6. Die vorangehende Beispielkonfiguration bleibt bewusst bei IPv4; für IPv6 werden die passende IP-Version, eine direkt erreichbare IPv6-Peer-Adresse und das IPv6-Präfix separat eingetragen.

WebAdmin ergänzt die nötige Trennung automatisch. Bei einer reinen CLI-Konfiguration sind die Defaults asymmetrisch: IPv4-Networks werden zunächst für alle Neighbors aktiviert, auch für IPv6-Neighbors. IPv6-Networks werden dagegen für keinen Neighbor aktiviert. Für einen IPv6-Neighbor werden deshalb in den jeweiligen Address Families ausdrücklich diese Zustände gesetzt:

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

Um die WebAdmin-Defaults auch bei einer CLI-Konfiguration abzubilden, nennt Sophos zusätzlich no bgp ebgp-requires-policy und bgp log-neighbor-changes. show running-config zeigt nur von Defaults abweichende Werte; eine automatisch gewählte Router ID und beispielsweise der Default maximum-paths ibgp 16 erscheinen dort nicht zwingend. IPv4 und IPv6 werden unter Routing > Information > BGP-IPv4 beziehungsweise BGP-IPv6 getrennt abgenommen, einschliesslich eigener IPv6-Firewall-Regeln und Rückwege.

BGP prüfen und abnehmen

Eine aufgebaute Session allein bestätigt noch keinen funktionierenden Paketfluss. Die Abnahme erfolgt deshalb in mehreren Ebenen:

Unter Routing > Information > BGP-IPv4 > Neighbors muss die Gegenstelle im State Established erscheinen.
Unter Routes erwartet Firewall A das Präfix 10.20.20.0/24; Firewall B erwartet 10.10.10.0/24.
Unter Summary werden die Session und die Anzahl empfangener Präfixe kontrolliert.
Unter Diagnostics > Tools > Route lookup wird auf Firewall A beispielsweise das Ziel 10.20.20.10 geprüft.
Danach folgt ein Test mit einem echten Dienst zwischen je einem Host aus beiden LANs. Log Viewer und Packet Capture müssen die erwartete Regel, das richtige Transitinterface und den Rückverkehr zeigen.

Ein Neighbor auf Established beweist nur, dass der BGP-Austausch funktioniert. Erst die gelernte Route, der korrekte Route Lookup und eine reale Verbindung bestätigen den gesamten Aufbau. Für die Paketflussprüfung hilft Sophos Firewall Regel mit Log Viewer und Packet Capture testen.

Dasselbe Beispiel über die CLI

Alternativ zum WebAdmin lässt sich dieselbe Basiskonfiguration nach der SSH-Anmeldung in der Routing-CLI erfassen. Die folgenden Befehle werden nicht zusätzlich auf eine bereits fertig konfigurierte Beispielumgebung angewendet. Vor Änderungen den aktuellen Stand sichern; ASN-Änderungen löschen Neighbors und Networks und gehören mit Backup in ein Wartungsfenster. Der Einstieg hängt von der SFOS-Version ab.

SFOS 22: Unter folgendem Menüpfad erscheint bgp>. Nur hier beginnt der Einstieg mit enable:

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

Auf Firewall A ohne bisher zugewiesene ASN:

enable
configure terminal
router bgp 65010

SFOS 23: Unter 3. Route Configuration > 1. Configure Unicast Routing erscheint direkt router#; weder die dritte Menüauswahl noch enable gehört zu diesem Einstieg. Für die erstmalige ASN-Zuweisung auf Firewall A:

configure terminal
router bgp 65010

Ist die ASN unter SFOS 23 bereits zugewiesen, wird nach configure terminal stattdessen router bgp ohne ASN verwendet, um die vorhandene Konfiguration auszuwählen. router bgp 65010 ist für die erstmalige Zuweisung oder eine bewusst geplante ASN-Änderung bestimmt, nicht für eine unkontrollierte Neuzuweisung.

Nach genau einem dieser Einstiege im BGP-Konfigurationsmodus fortfahren:

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

Auf Firewall B werden Local AS, Router ID, Neighbor, Remote AS und Network entsprechend durch 65020, 192.0.2.20, 198.51.100.1, 65010 und 10.20.20.0/24 ersetzt.

show running-config dient der Kontrolle. write speichert die CLI-Konfiguration dauerhaft, macht die Einträge im WebAdmin sichtbar und erhält sie nach einem Neustart. Ohne write ist die Änderung nicht vollständig abgeschlossen.

end verlässt vor diesen beiden Befehlen den Konfigurationsmodus. Für SFOS 23 dokumentiert Sophos als erwartete Speicherbestätigung Integrated configuration saved to /conf/routing/frr.conf; dies ist keine hier beobachtete Appliance-Ausgabe. Danach Konfiguration und WebAdmin-Einträge gegen die beabsichtigten Werte prüfen.

Die offiziell dokumentierte zusätzliche Kontrolle lautet:

show ip bgp

Sie zeigt die bekannten BGP-Präfixe und deren Pfadinformationen. Neighbor-State und Summary werden zuverlässig unter Routing > Information > BGP-IPv4 geprüft.

⚠️ Erweiterte CLI-Konfiguration und WebAdmin nicht unkontrolliert mischen. Das Bearbeiten eines Neighbors im WebAdmin kann zusätzliche CLI-Werte wie ein Neighbor-Passwort oder eine Route Map entfernen. Sobald solche Einstellungen verwendet werden, zuerst show running-config sichern und die BGP-Konfiguration weiter über die CLI pflegen.

SFOS 23.0: experimentelles BFD für BGP

Bidirectional Forwarding Detection (BFD) überwacht die Erreichbarkeit eines BGP-Nachbarn mit eigenen Kontrollpaketen. Dadurch kann die Firewall einen Ausfall früher erkennen als mit den BGP-Timern allein. Dieser optionale Ablauf gehört nicht zur vorangehenden BGP-Basiskonfiguration und wird nicht auf ältere SFOS-Versionen übertragen.

⚠️ In SFOS 23.0 ist BFD experimentell. Die dokumentierte Anwendung betrifft BGP in Standalone-Deployments; daraus folgt keine Freigabe für HA-Cluster oder andere Routingprotokolle. Für andere Protokolle muss Sophos Support einbezogen werden. Avanet empfiehlt zunächst eine isolierte Testumgebung. Ohne einen für den installierten Build bestätigten Rückweg wird BFD nicht produktiv aktiviert.

Geltungsbereich und Vorbereitung

Sophos nennt BGP-IPv4- und BGP-IPv6-Nachbarn sowie eBGP, iBGP, eBGP multihop und Route-Reflector-Nachbarn als BFD-Anwendungsfälle. Das folgende Beispiel bleibt beim bereits eingerichteten IPv4-Nachbarn 198.51.100.2 auf Firewall A. Es ist keine zusätzliche Zusage für einen bestimmten Cloud-VPN-Dienst oder eine bestimmte Multihop-Topologie.

Vor dem Start müssen die BGP-Session, die erwarteten Präfixe und der Anwendungstraffic ohne BFD funktionieren. Die Gegenstelle muss für BFD vorbereitet sein; Peer-Adressen, Erreichbarkeit und Timer werden mit deren Administrator abgestimmt. Aktuellen SFOS-Build, show running-config, Neighbor-Status und Route Lookup sichern und Backup, Wartungsfenster sowie unabhängigen Managementzugang bereithalten. Den Rückbau der BFD-Nachbarbindung, eines zusätzlichen Peer-Profils und des Dienstes vorab mit Sophos Support für diesen Build klären. Die BFD-Anleitung dokumentiert dafür keine vollständigen Remove- oder Stop-Befehle.

Wird der überwachte Neighbor unerreichbar, entfernt die Firewall alle von ihm gelernten Routen unmittelbar aus der Routingtabelle. Nur wenn ein alternativer Pfad vorhanden ist, kann der Traffic dorthin wechseln; ohne ihn verlieren die betroffenen Netze ihre Route. Bei Rückkehr des Nachbarn beschreibt Sophos die Wiederherstellung der Routen und den Rückwechsel zum ursprünglichen Pfad. Deshalb werden sowohl Ausfall als auch Wiederkehr geprüft, einschliesslich der tatsächlich gewählten Route.

Dienst starten und Nachbar überwachen

Der BFD-Dienst ist standardmässig ausgeschaltet. Die folgenden Befehle ändern den Routingbetrieb; vor dem Ausführen müssen der gesicherte Ausgangsstand und der bestätigte Rückweg vorliegen. Per CLI unter 5. Device Management > 3. Advanced shell anmelden und dort den Dienst starten:

service -ds nosync bfdd:start

Danach in derselben Advanced Shell mit vtysh zur Routing-CLI wechseln:

vtysh

In der Routing-CLI die BFD-Bindung für den bereits vorhandenen Neighbor auf Firewall A ergänzen. Router ID, Local AS, Remote AS und Networks bleiben dabei unverändert:

configure terminal
router bgp
neighbor 198.51.100.2 bfd
end
write

198.51.100.2 wird durch die tatsächliche Neighbor-Adresse ersetzt, nicht durch dessen LAN oder Router ID. Auf Firewall B lautet die entsprechende Adresse im Beispiel 198.51.100.1. Die Gegenstelle wird nach ihrer eigenen Produktanleitung eingerichtet. Fehlt der BGP-Nachbar noch, zuerst die BGP-Basiskonfiguration dieses Artikels abschliessen; BFD ersetzt sie nicht. write speichert die Routingkonfiguration, ist aber kein Beweis für eine erfolgreiche BFD-Session oder einen automatischen Dienststart nach Neustart.

Timer nur bei begründetem Bedarf ändern

Für den ersten Test empfiehlt Avanet die dokumentierten Defaults: Detect multiplier 3, Transmit interval 300 ms und Receive interval 300 ms. Sehr kurze Intervalle oder ein empfindlicher Multiplikator können die Verarbeitungslast erhöhen. Ein fester Umschaltzeitwert wird daraus nicht versprochen.

Timer werden in der BFD-Konfiguration gesetzt, nicht im BGP-Nachbarkommando. Wenn ein explizites Peer-Profil benötigt wird, zeigt dieser Block in der Routing-CLI die dokumentierten Default-Werte für denselben Beispielpeer:

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

peer startet die Peer-Überwachung mit Default-Timern; dieser zusätzliche Block ist nicht nötig, um nur die BGP-Bindung einzurichten. Für detect-multiplier dokumentiert Sophos den Bereich 1–155, für beide Intervalle 10–4294967 ms. Der Transmit-Wert bezeichnet das minimale Sendeintervall ohne Jitter, der Receive-Wert das erwartete minimale Empfangsintervall. Die Gegenstelle berechnet ihre Erkennungszeit aus dem lokalen Multiplikator und dem grösseren Wert aus lokalem Sende- und entferntem Empfangsintervall. Man stimmt deshalb beide Seiten ab, statt allein einen möglichst kleinen lokalen Wert zu wählen. Zusätzliche Timer direkt hinter neighbor … bfd sind keine gültige Syntax.

BFD, Routen und Anwendung gemeinsam abnehmen

In der Routing-CLI sind diese beiden Prüfungen lesend:

show bfd peers
show bfd peers brief

Für den vorgesehenen Peer erwartet man Status: up. Die Detailausgabe muss passende lokale und entfernte Timer sowie Diagnostics: ok und Remote diagnostics: ok zeigen; die Kurzansicht ordnet Peer-Adresse und Status zu. Anschliessend die BGP-Session unter Routing > Information > BGP-IPv4 beziehungsweise BGP-IPv6, die erwarteten Präfixe, Route Lookup und echten Anwendungstraffic erneut prüfen. BFD up allein bestätigt weder die richtige BGP-Route noch den Datenpfad.

Einen Ausfalltest nur in einer freigegebenen Testumgebung oder einem geplanten Wartungsfenster durchführen, ohne den unabhängigen Managementzugang zu gefährden. Vorher die vom überwachten Neighbor gelernten Präfixe und den geplanten Ersatzpfad festhalten. Während des kontrollierten Peer-Ausfalls müssen die betroffenen Routen verschwinden und, sofern vorhanden, die Ersatzroute sowie der Anwendungstraffic funktionieren. Nach Wiederherstellung erneut BFD up, BGP, zurückgekehrte Präfixe, ausgewählten Pfad und Anwendung prüfen. Keine Geräteausgabe oder erfolgreiche Umschaltung wird hier als bereits getestet dargestellt.

Fehler eingrenzen und Änderung zurücknehmen

Peer fehlt oder bleibt down: Dienststart und BFD-Bindung in show running-config prüfen, dann tatsächliche Peer-Adresse, Erreichbarkeit und BFD-Konfiguration der Gegenstelle vergleichen. Mit show bfd peers lokale und entfernte Diagnose sowie Timer erfassen. Keine breite Any-to-Any-Freigabe als pauschale Lösung hinzufügen; bei unklaren Zugriffsanforderungen Sophos Support einbeziehen.
BFD funktioniert nach einer Änderung nicht mehr: Änderungen an zugehörigen Einstellungen, etwa Zieladresse oder Remote Gateway, können die BFD-Einstellungen entfernen. Konfiguration mit dem gesicherten Stand vergleichen, BFD für den betroffenen Neighbor erneut einrichten und vollständig abnehmen.
Instabile Session oder höhere Last nach Timeränderung: Im selben BFD-Peer-Kontext die zuvor dokumentierten Werte wieder setzen und mit write speichern. War der Ausgangsstand das Default-Profil, zeigt der obige Block 3 und 300 ms. Danach beide Peer-Diagnosen, BGP-Routen und Traffic prüfen, bevor weitere Werte verändert werden.
Vollständiger Rückbau: Nur den vorab für diesen Build bestätigten Rückbauplan anwenden und danach die BGP-Konfiguration ohne BFD gegen den gesicherten Ausgangsstand vergleichen. Weder ein erfundenes no-Kommando noch das pauschale Stoppen des Dienstes ersetzt diesen Plan. Das Entfernen des ganzen BGP-Nachbarn wäre kein gleichwertiger BFD-Rollback, weil dadurch auch seine Routen entfallen. Rückbau erst abschliessen, wenn BGP-Session, benötigte Präfixe, Managementzugang und Anwendung wieder im vorgesehenen Zustand sind.

Weight, MED und die globale Route Precedence

Die globale Route Precedence ordnet die Kategorien static, sdwan_policyroute und vpn. Sie ist von den Attributen zu trennen, mit denen BGP seine eigenen Pfade auswählt. Den aktuellen globalen Wert zeigt system route_precedence show; geändert wird er nur, wenn diese drei Kategorien tatsächlich konkurrieren. Routing-Priorität auf Sophos Firewall anpassen erklärt dafür den vollständigen Prüf- und Rückweg.

Zwischen verschiedenen Routingprotokollen entscheidet unter anderem die Administrative Distance. Innerhalb von BGP werden BGP-Attribute ausgewertet. Sophos nennt beispielsweise eine höhere Weight als bevorzugt; bei ansonsten vergleichbaren Wegen wird eine niedrigere MED bevorzugt.

Das ist besonders wichtig, wenn dasselbe Präfix über redistribute ospf und zusätzlich von einem BGP-Neighbor gelernt wird. Die lokal erzeugte, redistribuierte Route hat standardmässig Weight 32768, die vom Neighbor gelernte Route Weight 0. Ohne bewusste Anpassung gewinnt deshalb die redistribuierte Route. Soll der Peer-Pfad bevorzugt werden, muss dessen Weight höher gesetzt und die resultierende Route danach geprüft werden.

MED für mehrere Eintrittspfade verwenden

SFOS 23 – Namen vorab prüfen: Vor dem Erstellen oder Wiederverwenden von Access Lists, Prefix Lists und Route Maps deren Namen über alle dynamischen Routingprotokolle inventarisieren. Sie liegen in einer gemeinsamen Konfigurationsdatei und müssen protokollübergreifend eindeutig sein. Namenskollisionen vermeiden und die beabsichtigten Neighbor-/Policy-Bindungen gegen die aktuelle und gesicherte Konfiguration prüfen. Diese Voraussetzung ersetzt nicht den unten verlangten, für den installierten Build bestätigten MED-Rückbauplan; ausführbare MED-Einrichtung bleibt bis dahin zurückgestellt.

Upgrade auf SFOS 23.0: Ab dieser Version verwenden alle dynamischen Routingprotokolle eine integrierte Konfiguration. Beim Upgrade von einer früheren Version ergänzt die Firewall die Namen von Route Maps, Prefix Lists und Access Lists automatisch um Protokollpräfixe, aber nur bei einem Namenskonflikt. Alle Referenzen auf die umbenannten Konfigurationen werden ebenfalls automatisch aktualisiert. Daraus folgt keine pauschale Umbenennung aller Objekte.

Nach dem Upgrade die vorab gesicherten Objektnamen und Referenzen mit dem aktuellen show running-config vergleichen und die Zuordnung der alten zu den aktuellen Namen festhalten. Prüfen, ob die beabsichtigten Neighbor-/Route-Map-Bindungen weiterhin auf die richtigen Policies zeigen, einschliesslich vorhandener MED-Bindungen. Alte Namen nicht blind wiederherstellen. Unter Routing > Information > BGP-IPv4 > Routes und mit show ip bgp auf der Gegenstelle prüfen, dass erwartete Netzpräfixe vorhanden sind, nicht erlaubte Netzpräfixe fehlen und der beabsichtigte Pfad gewählt wird; den tatsächlich verwendeten Pfad zusätzlich mit Route Lookup kontrollieren. Diese Prüfung ersetzt weder den unten verlangten MED-Rückbauplan für den installierten Build noch hebt sie die Zurückstellung der MED-Einrichtung auf.

Der Multi-Exit Discriminator (MED) teilt einem direkt benachbarten AS mit, welchen von mehreren Eintrittspfaden es in das eigene AS bevorzugen soll. Ein niedrigerer MED ist besser; der Default ist 0. Ein höherer Wert wird daher auf dem weniger gewünschten Pfad angekündigt. MED wird standardmässig nur verglichen, wenn dasselbe Präfix über mehrere Links aus demselben benachbarten AS gelernt wird.

MED ist nicht transitiv. Gibt der Empfänger die Route an ein weiteres AS weiter, wird der Wert auf 0 zurückgesetzt. Ausserdem prüft BGP vorher Weight, Local Preference, lokal erzeugte Route, AS-Path-Länge und Origin Type. MED entscheidet nur, wenn diese wichtigeren Attribute gleich sind. Ein gesetzter Wert ist deshalb kein Beweis, dass der gewünschte Pfad gewinnt.

Sophos setzt MED über eine ausgehende Route Map mit fester Sequenznummer und bindet diese in der IPv4 Address Family an einen bestimmten Neighbor. out verändert die Ankündigung an diese Gegenstelle; es erzwingt nicht direkt den ausgehenden Datenpfad der Sophos Firewall. Die offizielle SFOS-22-Seite dokumentiert die Einrichtung, aber keinen vollständigen Rückbau. Deshalb wird die Änderung erst umgesetzt, wenn die exakten Remove-Befehle für den installierten Build separat bestätigt und mit dem vorher gesicherten show running-config als Wiederherstellungsplan festgehalten sind.

Nach einer freigegebenen Änderung muss show ip bgp auf dem empfangenden Router den erwarteten MED und den bevorzugten Pfad zeigen. Auf einer Sophos-Gegenstelle steht die Route zusätzlich unter Routing > Information > BGP-IPv4 > Routes. Ohne diesen Vorher-/Nachher-Vergleich bleibt der Abschnitt eine Entscheidungshilfe und keine auszuführende Produktionsänderung.

BGP über route-based IPsec und Cloud-VPN

BGP kann über ein adressiertes XFRM-Interface eines route-based Site-to-Site-IPsec-Tunnels laufen. Dafür erhalten beide XFRM-Interfaces passende Transit-IPs. Dynamic Routing wird gezielt für die VPN-Zone erlaubt; Regeln für den Nutzdatenverkehr bleiben trotzdem erforderlich.

Bei Cloud-Verbindungen werden die Werte nicht frei gewählt:

Für AWS Site-to-Site VPN stammen Inside-Tunnel-Adressen, Remote AS und weitere Tunnelwerte aus der AWS-Konfiguration. Beide AWS-Tunnel werden separat geprüft.
Beim Azure VPN Gateway muss die lokale XFRM-IP zur vorgesehenen BGP-Peer-IP passen; lokale und Azure-ASN müssen verschieden sein.

Ein grüner IPsec-Tunnel und ein BGP Neighbor auf Established sind zwei getrennte Prüfpunkte. Danach müssen die erwarteten Präfixe und echter Anwendungstraffic funktionieren.

Fehler systematisch eingrenzen

Neighbor bleibt auf Active oder wird nicht angezeigt

Active bedeutet nicht, dass die Session aktiv funktioniert. Die Firewall versucht weiterhin, eine BGP-Verbindung aufzubauen. Zuerst direkte Erreichbarkeit der Peer-IP, Interface- und Tunnelstatus, Local AS, Remote AS sowie die Neighbor-IP prüfen. Danach kontrollieren, ob Dynamic Routing in der richtigen Zone oder über eine passende Local Service ACL Exception erlaubt ist.

Bei XFRM zusätzlich sicherstellen, dass beide Tunneladressen stimmen und der IPsec-Tunnel up ist. Bei Cloud- und XFRM-Aufbauten werden ausserdem die im jeweiligen VPN-Design vorgesehenen Regeln geprüft. Sind deren Services eingeschränkt, muss TCP 179 zwischen den beiden Peer-IPs enthalten sein. Device Access beziehungsweise die Local Service ACL für den lokalen BGP-Dienst bleibt davon getrennt.

Neighbor ist Established, aber das entfernte Netz fehlt

Dann funktioniert die Session, aber das Präfix wird nicht angekündigt oder nicht akzeptiert. Auf der sendenden Firewall den Network-Eintrag, seine IP-Version und Maske sowie show running-config prüfen. Anschliessend auf der Gegenstelle unter Routes und Summary kontrollieren, ob das Präfix ankommt oder durch eine dortige Policy verworfen wird.

Fehlt nach einem Upgrade auf SFOS 22 ein Netz hinter einem policy-based IPsec-Tunnel, kann die frühere Abhängigkeit von redistribute kernel die Ursache sein. Die BGP-Session kann trotzdem Established bleiben; SFOS 22: IPsec-Routen und redistribute kernel erklärt die Versionsänderung und das route-based XFRM-Zieldesign.

Die BGP-Route ist sichtbar, wird aber nicht verwendet

Zuerst mit Route Lookup prüfen, welche Route für eine konkrete Ziel-IP gewinnt. Eine spezifischere Route hat Vorrang vor einem breiteren Präfix. Konkurrieren mehrere Quellen, sind Administrative Distance, BGP-Attribute und erst danach die globale Route-Precedence-Kategorie getrennt zu beurteilen.

Die Route stimmt, aber der Traffic funktioniert nicht

BGP hat seine Aufgabe erfüllt, sobald die korrekte Route installiert ist. Danach liegen Fehler meist bei Firewall-Regel, NAT, Rückweg oder Zielsystem. Bei normal gerouteten Standortnetzen ist häufig kein SNAT nötig, weil beide Seiten die echten LAN-Präfixe kennen sollen.

Erweiterte Einstellungen sind nach einem WebAdmin-Edit verschwunden

WebAdmin bildet nur die Basiswerte ab. Wurde ein Neighbor dort nach einer erweiterten CLI-Konfiguration gespeichert, können Passwort, Route Map oder geänderte Defaults entfernt worden sein. Auch das Übernehmen der Global configuration entfernt Änderungen an bgp log-neighbor-changes und no bgp ebgp-requires-policy. Den gesicherten Stand vergleichen, die Werte über die CLI wiederherstellen und mit write speichern.

BGP- und Routing-Logs zuordnen

Die SFOS-22-Logreferenz ordnet BGP und BGPv6 der Datei bgpd.log zu. zebra.log betrifft die Installation dynamischer IPv4- und IPv6-Routen im Kernel; bei route-based IPsec gehört xfrmi.log zum XFRM-Tunnelinterface. Damit lässt sich die Fehlerklasse trennen: zuerst BGP-Session und Ankündigung, danach die Übernahme in die System-Routingtabelle und bei Bedarf der Tunnelzustand. Sophos Firewall Service- und Logdateien erklärt den Zugriff und weitere Dateien. Undokumentierte Live-Shell-Befehle sind für diese Abnahme nicht erforderlich.

Änderung sicher zurücknehmen

Vor dem Entfernen von BGP muss für jedes gelernte Zielnetz ein alternativer Pfad oder ein Wartungsfenster vorhanden sein. Zuerst werden die betroffenen Networks und Neighbors entfernt, danach wird die globale BGP-Konfiguration nur dann geändert, wenn keine weiteren Peers davon abhängen. Dynamic Routing darf erst deaktiviert werden, wenn die Zone keinen anderen dynamischen Routingdienst mehr benötigt.

Im WebAdmin werden zuerst unter Routing > BGP > Networks die nicht mehr benötigten Ankündigungen und danach unter Neighbors die betroffenen Gegenstellen entfernt. Nach jedem Schritt wird geprüft, ob die erwarteten Ersatzrouten aktiv sind. Router ID oder Local AS bleiben unverändert, solange noch andere BGP-Verbindungen davon abhängen; eine Änderung der Local AS würde alle verbleibenden Neighbors und Networks löschen.

Die geprüften BGP-Übersichtsseiten für SFOS 22 und 23 zeigen zwar eine Syntax zum Abschalten der BGP-Routingkonfiguration. Der vollständige Ausführungskontext und ein sicherer Rückbau für den installierten Build sind damit aber nicht validiert. Die auffällige Quellsyntax wird weder als ausführbarer Befehl übernommen noch stillschweigend korrigiert; ein bestätigtes Stoppen des Daemons oder Löschen des Prozesses wird daraus nicht abgeleitet. Ein destruktiver CLI-Befehl wird nicht empfohlen. Wer erweiterte CLI-Policies verwendet, benötigt vor dem Rückbau die für den installierten Build bestätigten Remove-Befehle und den gesicherten vorherigen Konfigurationsblock.

Anschliessend werden Routing Information, Route Lookup, Managementzugang und echter Traffic erneut geprüft. Ein Rollback ist erst abgeschlossen, wenn nicht nur die BGP-Session verschwunden ist, sondern alle benötigten Zielnetze weiterhin über den vorgesehenen Ersatzpfad erreichbar sind.