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:

1. Transit-IPs, lokale und entfernte ASN sowie die anzukündigenden Netze festlegen.
2. Die direkte IP-Erreichbarkeit zwischen den beiden BGP-Peers prüfen.
3. Unter Administration > Device access Dynamic Routing nur für die Peer-Zone beziehungsweise über eine enge Local Service ACL Exception erlauben.
4. Unter Routing > BGP Router ID und Local AS setzen.
5. Die Peer-IP als Neighbor mit der Remote AS hinzufügen.
6. Nur die benötigten lokalen Präfixe unter Networks eintragen.
7. 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 direkt erreichbare Peer-IP, zu der die BGP-Session aufgebaut wird.
• 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. Die BGP-Session selbst wird über TCP 179 aufgebaut und über Device Access beziehungsweise eine Local Service ACL zur Firewall freigegeben. Der Nutzdatenverkehr über eine gelernte Route benötigt weiterhin 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 anzukündigenden Netze existieren bereits als passende Routen in der lokalen Routingtabelle.
• 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 sicherer als die breite Zonenfreigabe. Unter Administration > Device access > Local service ACL exception rule > Add wird dafür eine Accept-Regel für die Peer-Zone, die konkrete Peer-IP oder das enge Transitnetz, die benötigte Firewall-Adresse und den Dienst Dynamic Routing erstellt. Danach den Zugriff von der erlaubten Peer-IP und einer nicht erlaubten Quelle prüfen.

Device Access steuert nur die BGP-Verbindung zur Firewall. Die produktiven Verbindungen zwischen den beiden LANs benötigen danach normale Firewall-Regeln. Die Trennung erklärt Device Access auf Sophos Firewall absichern.

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.

Ein Network erzeugt keine Route. Das Präfix muss bereits exakt in der lokalen Routingtabelle vorhanden sein, beispielsweise als direkt verbundenes Netz oder statische Route. Fehlt es oder stimmt die Maske nicht, bleibt die BGP-Session möglicherweise Established, das Network wird aber nicht angekündigt.

Nur tatsächlich benötigte Präfixe sollten eingetragen werden. Eine pauschale Redistribution direkt verbundener oder statischer Routen kann auch WAN-, Management- oder Blackhole-Netze erfassen und gehört nur mit geprüfter Filterung in den produktiven Betrieb.

BGP prüfen und abnehmen

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

1. Unter Routing > Information > BGP-IPv4 > Neighbors muss die Gegenstelle im State Established erscheinen.
2. Unter Routes erwartet Firewall A das Präfix 10.20.20.0/24; Firewall B erwartet 10.10.10.0/24.
3. Unter Summary werden die Session und die Anzahl empfangener Präfixe kontrolliert.
4. Unter Diagnostics > Tools > Route lookup wird auf Firewall A beispielsweise das Ziel 10.20.20.10 geprüft.
5. 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 im BGP-CLI erfassen. Die folgenden Befehle werden nicht zusätzlich auf eine bereits fertig konfigurierte Beispielumgebung angewendet. Der Menüpfad lautet:

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

Auf Firewall A sieht das vollständige Beispiel so aus:

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

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.

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.

Route Precedence und BGP-Pfadauswahl

system route_precedence entscheidet nicht zwischen BGP und einer statischen Route. Die globale Einstellung ordnet lediglich die Kategorien static, sdwan_policyroute und vpn; BGP und andere dynamische Routen gehören dabei zur Kategorie static.

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.

Die aktuelle globale Reihenfolge lässt sich in 4. Device Console anzeigen:

system route_precedence show

Sie sollte nur geändert werden, wenn tatsächlich Routing-Kategorien konkurrieren. Die Zusammenhänge und sichere Beispiele erklärt Routing-Priorität auf Sophos Firewall anpassen.

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 muss das Network mit exakt derselben Maske in der lokalen Routingtabelle vorhanden sein. Danach Networks, Filter und show running-config prüfen. Eine fehlende lokale Route sollte behoben und nicht durch ein deaktiviertes BGP Network Import Check verdeckt werden.

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. Den gesicherten Stand vergleichen, die Werte über die CLI wiederherstellen und mit write speichern.

BGP- und Routing-Logs prüfen

In 5. Device Management > 3. Advanced Shell zeigen zwei Logdateien die unterschiedlichen Ebenen:

tail -f /log/bgpd.log

bgpd.log protokolliert BGP- und BGPv6-Ereignisse. Die laufende Ausgabe wird mit Ctrl+C beendet. Wenn BGP eine Route kennt, sie aber nicht im System erscheint, folgt:

tail -f /log/zebra.log

Wer nicht live mitlesen möchte, verwendet beispielsweise:

less /log/bgpd.log

Bei route-based IPsec kann zusätzlich /log/xfrmi.log den Zustand des XFRM-Interfaces erklären. Die Einordnung weiterer Dateien steht unter Sophos Firewall Service- und Logdateien.

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

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.