Sophos Firewall OSPF konfigurieren und prüfen

OSPF tauscht IPv4-Routen automatisch zwischen Routern aus. Das ist sinnvoll, wenn mehrere Standorte, redundante Pfade oder häufig wechselnde Netze mit statischen Routen nur noch mühsam gepflegt werden können. Für eine kleine oder bestehende Routing-Domain mit wenigen Routern kann RIPv2 einfacher sein; OSPF bietet dagegen schnellere Konvergenz und ein skalierbareres Pfadmodell.

Im folgenden Beispiel bilden zwei Sophos Firewalls über ein eigenes Transitnetz eine OSPF-Nachbarschaft. Am Ende steht der Neighbor auf Full, Firewall A kennt das LAN hinter Firewall B und umgekehrt. Für IPv6 wird OSPFv3 separat konfiguriert.

⚠️ OSPF-Nachbarschaften gehören auf dafür vorgesehene, vertrauenswürdige Transit- oder VPN-Interfaces. Im Beispiel wird zusätzlich das LAN als OSPF Network eingetragen, damit SFOS sein Präfix ankündigt. Dadurch nimmt SFOS auch das LAN-Interface in OSPF auf und kann dort OSPF Hellos senden. Dynamic Routing bleibt für die LAN-Zone deaktiviert, damit keine eingehenden OSPF-Pakete zugelassen werden; die ausgehenden Hellos verhindert dies nicht. Redistribute connected nicht aktivieren, bevor klar ist, welche direkt verbundenen Netze dadurch angekündigt werden.

Ablauf im Überblick

Für eine einfache OSPFv2-Verbindung sind diese Schritte nötig:

Transit-Interfaces adressieren und die direkte IP-Erreichbarkeit prüfen.
Unter Administration > Device access Dynamic Routing für eine eigene Transit-Zone oder mit einer eng begrenzten Local Service ACL Exception erlauben.
Unter Routing > OSPF auf jeder Firewall eine eindeutige Router ID eintragen.
Area 0.0.0.0 als Normal anlegen.
Das lokale Transitnetz unter Networks der Area 0.0.0.0 zuweisen.
Das jeweilige LAN als zweites OSPF Network eintragen oder eine separat geprüfte Redistribution verwenden.
Unter Routing > Information > OSPF den Neighbor-Status Full und die gelernte Route prüfen.

Ein OSPF-Network ist dabei nicht das entfernte Zielnetz. Der Eintrag aktiviert OSPF auf den lokalen Interfaces, deren IP-Adresse in dieses Netz fällt. Das entfernte LAN erscheint erst, wenn die Gegenstelle es über OSPF ankündigt.

Was OSPF auf der Firewall entscheidet

OSPF ist ein internes Link-State-Routingprotokoll. Benachbarte Router tauschen Informationen über ihre erreichbaren Netze und Pfade aus, bauen daraus eine Link-State Database und berechnen den günstigsten Weg. Ein kleinerer Cost wird gegenüber einem grösseren bevorzugt.

Damit löst OSPF eine andere Aufgabe als Firewall-Regeln und SD-WAN:

OSPF lernt und verteilt Zielnetze innerhalb der eigenen Routing-Domain.
Eine Firewall-Regel entscheidet weiterhin, ob Nutzdaten zwischen den beteiligten Zonen und Netzen passieren dürfen.
NAT verändert bei Bedarf Adressen, ist aber kein Bestandteil von OSPF.
Eine SD-WAN Route kann zusätzlich nach Quelle, Dienst, Anwendung oder Leitungsqualität entscheiden.

OSPF-Routen erscheinen zusammen mit den anderen Unicast-Routen in der Routingtabelle. Innerhalb des klassischen Routings gewinnt zuerst das längste passende Präfix. Für dasselbe Präfix vergleicht SFOS die Administrative Distance verschiedener Routingquellen; zwischen vergleichbaren OSPF-Pfaden entscheidet anschliessend die OSPF-Metrik. Davon getrennt bestimmt die globale Route Precedence, ob klassisches Routing, SD-WAN Policy Routes oder VPN-Routen zuerst ausgewertet werden. Vor einer globalen Änderung wird die aktuelle Reihenfolge deshalb mit system route_precedence show dokumentiert.

OSPFv2 verarbeitet IPv4. OSPFv3 erfüllt dieselbe Aufgabe für IPv6, wird auf Sophos Firewall aber separat eingerichtet.

Beispieltopologie planen

Die Beispielwerte bilden zwei Standorte ab:

Firewall A: Router ID 192.0.2.10, Transit-IP 198.51.100.1/30, lokales LAN 10.10.10.0/24
Firewall B: Router ID 192.0.2.20, Transit-IP 198.51.100.2/30, lokales LAN 10.20.20.0/24
Transitnetz: 198.51.100.0/30
OSPF Area: 0.0.0.0

Die Adressen 192.0.2.0/24 und 198.51.100.0/24 sind Dokumentationsnetze. Sie werden durch die tatsächlichen Werte der Umgebung ersetzt.

Die Router ID sieht wie eine IPv4-Adresse aus, muss aber keinem Interface zugewiesen sein. Entscheidend ist, dass sie innerhalb der OSPF-Domain eindeutig und dauerhaft stabil bleibt. 0.0.0.0 ist nicht zulässig. Ohne eigenen Wert verwendet SFOS die höchste Interface-Adresse; eine bewusst gewählte Router ID verhindert, dass sich die Identität nach einer Interface-Änderung unerwartet verschiebt.

Für diesen einfachen Aufbau genügt die Backbone Area 0.0.0.0. Mehrere Areas lohnen sich erst, wenn eine grössere Routing-Domain bewusst gegliedert und zusammengefasst werden soll. Jede weitere Area benötigt eine Verbindung zur Backbone Area.

OSPF sicher vorbereiten

Vor der OSPF-Konfiguration sollten folgende Voraussetzungen erfüllt sein:

Die Firewall läuft im Gateway Mode. OSPF ist im Transparent Mode nicht verfügbar.
Beide Transit-IPs liegen im gleichen Netz und erreichen sich direkt, beispielsweise mit Ping.
Interface, Subnetzmaske, MTU und Zone sind dokumentiert.
Router ID, Area, Authentifizierung, Hello- und Dead-Interval sind auf beiden Seiten abgestimmt.
Ein Konfigurationsbackup und ein unabhängiger Managementzugang sind vorhanden.
Für die beiden LANs sind passende Firewall-Regeln und Rückwege geplant.

Ein eigenes Transit-VLAN und eine eigene Transit-Zone erleichtern die Absicherung. Die Grundlagen dazu erklärt Sophos Firewall Zonen und Interfaces konfigurieren.

Dynamic Routing gezielt freigeben

Unter Administration > Device access ist Dynamic Routing standardmässig für alle Zonen deaktiviert. Für das Beispiel wird der Dienst nur in der eigenen Transit-Zone aktiviert, an die das Netz 198.51.100.0/30 gebunden ist.

Die Checkbox in der Device-Access-Matrix gilt für die gesamte Zone und nicht nur für ein einzelnes Interface. Eine eigene Transit-Zone ist deshalb die klarste Variante. Teilt das Transit-Interface seine Zone mit weiteren Netzen, kann eine Local service ACL exception rule den Zugriff nach IP version, Source zone, Source networks and hosts, Destination host, Dienst Dynamic Routing, Action und Regelposition einschränken. OSPFv2 verwendet jedoch die Multicast-Ziele 224.0.0.5 und 224.0.0.6; die lokale Transitadresse ist deshalb nicht ohne Weiteres ein funktionierender Destination host. Vor dem Einsatz einer solchen Ausnahme muss das Multicast-Matching auf dem installierten SFOS-Build bestätigt werden. Ohne diesen Nachweis bleibt die dedizierte Transit-Zone die sichere Wahl.

Diese Freigabe betrifft OSPF-Pakete zur Firewall selbst. Dafür ist keine normale Firewall-Regel nötig. Der eigentliche Datenverkehr zwischen 10.10.10.0/24 und 10.20.20.0/24 benötigt trotzdem passende IPv4-Firewall-Regeln. Die Trennung zwischen lokalen Diensten und durchgeleitetem Traffic erklärt Device Access auf Sophos Firewall absichern.

OSPFv2 im WebAdmin konfigurieren

Die folgenden Schritte werden auf beiden Firewalls ausgeführt. Nur Router ID, Transit-IP und lokales LAN unterscheiden sich.

1. Globale Einstellungen setzen

⚠️ Die Beispielwerte gelten für eine Ersteinrichtung. Bei einem bestehenden Router darf die Router ID nicht unbesehen ersetzt werden: Die SFOS-23-Hilfe warnt, dass eine Änderung alle OSPF-Sessions zurücksetzt. Dies ist keine Aussage, dass ältere Versionen davon ausgenommen wären. Vor einer Änderung Backup, unabhängigen Managementzugang, aktuelle Nachbarn und Routen sichern und ein Wartungsfenster planen. Danach müssen die erwarteten Nachbarschaften wieder Full sein, gewünschte Präfixe vorhanden, unerwünschte Präfixe abwesend und echte Verbindungen samt Rückweg geprüft sein.

Unter Routing > OSPF werden die globalen Werte festgelegt:

Router ID: auf Firewall A 192.0.2.10, auf Firewall B 192.0.2.20
Default metric: 20 belassen, sofern keine bewusste Vorgabe für redistribuierte Routen besteht
ABR type: für einen neuen Standardaufbau Standard
Auto-cost reference-bandwidth: auf dem Standardwert 100000 Mbps belassen, solange die Kostenplanung keinen anderen gemeinsamen Referenzwert verlangt
Default-information originate: Never, solange die Firewall nicht ausdrücklich eine Default Route an alle OSPF-Nachbarn verteilen soll
Redistribute connected, static, RIP und BGP: zunächst deaktiviert lassen

Danach die globale Konfiguration mit Apply übernehmen.

Default metric ist der Rückfallwert für redistribuierte Routen, wenn für deren Routentyp keine eigene Metrik gesetzt ist. Ein Area Border Router (ABR) verbindet weitere Areas mit dem Backbone und hält für jede angeschlossene Area eine eigene Topologiedatenbank und Routinginformation. OSPFv2 bietet unter ABR type Standard, Cisco, IBM und Shortcut zur Kompatibilität mit der bestehenden Routing-Domain; die Wahl muss zum abgestimmten Design passen.

Bei einer Migration von einer älteren Version auf SFOS 19.5 oder neuer wird der frühere Standard der Reference Bandwidth von 100 auf 100000 Mbps umgestellt. Ein zuvor individuell gesetzter Wert bleibt unverändert. Nach einem Upgrade deshalb den tatsächlichen Referenzwert und die daraus berechneten Costs mit der Kostenplanung vergleichen.

Ein Autonomous System Boundary Router (ASBR) bringt Routen aus anderen Routingquellen in OSPF ein. Auf ihn beziehen sich die folgenden externen Metriken.

Die Default Metric betrifft Routen, die aus anderen Quellen in OSPF übernommen werden. Für redistribuierte Routen und die angekündigte Default Route lässt sich zusätzlich Metric type wählen. External type 1 addiert den internen Cost bis zum ASBR und den externen Cost. Bei External type 2 entscheidet zuerst die externe Metrik; ist sie gleich, wird auch der interne Pfad zum ASBR als Tie-Breaker berücksichtigt. Der Interface Cost bestimmt dagegen die Pfadwahl innerhalb der OSPF-Topologie. Ein kleinerer Cost gewinnt.

Default-information originate: Always darf nicht als schneller Internet-Failover-Schalter verwendet werden. Die Firewall würde damit auch dann eine Default Route ankündigen, wenn sie selbst keine besitzt. Regular kündigt sie nur an, wenn eine Default Route in der Routingtabelle vorhanden ist.

2. Backbone Area anlegen

Im Bereich Areas auf Add klicken und folgende Werte setzen:

Area: 0.0.0.0
Type: Normal

Area cost lässt sich nur für andere Area-Typen als Normal setzen; für die Backbone Area dieses Beispiels entfällt das Feld. Für eine Normal Area kann unter Virtual links > Add ein Virtual Link ergänzt werden, um eine Area ohne physische Backbone-Verbindung an das Backbone anzubinden. Dies ist eine geplante Mehr-Area-Änderung, kein Ersatz für die Prüfung der physischen Topologie.

Bei der Area wird der Authentication Type Text oder MD5 gewählt. Wenn die Gegenstelle MD5 unterstützt, ist dies der Klartextvariante vorzuziehen. Die zugehörige Key ID und der Schlüssel werden später am Transit-Interface hinterlegt. MD5 authentifiziert die OSPF-Pakete, verschlüsselt aber nicht die ausgetauschten Routinginformationen.

Die Area anschliessend mit Save speichern.

Für den einfachen Aufbau bleibt Area 0.0.0.0 vom Typ Normal. Eine Stub Area übernimmt keine externen AS-Routen, Stub no-summary unterdrückt zusätzlich normale Summary-Routen ausser der Default Route. Eine NSSA kann eigene externe Routen als Type-7-LSAs in die OSPF-Domain einbringen; NSSA no-summary kombiniert dies mit der stärkeren Summary-Begrenzung. Ein Virtual Link steht nur für eine Normal Area zur Verfügung. Den Area-Typ nicht als schnellen Troubleshooting-Schalter ändern, weil beide Seiten und das gesamte Area-Design dazu passen müssen.

3. Transitnetz hinzufügen

Im Bereich Networks auf Add klicken:

IPv4/Netmask: 198.51.100.0/30
Area: 0.0.0.0

Auf Firewall A passt die Adresse 198.51.100.1 zu diesem Network, auf Firewall B 198.51.100.2. Dadurch läuft OSPF auf den jeweiligen Transit-Interfaces und die beiden Firewalls können eine Nachbarschaft bilden.

Den Network-Eintrag mit Save speichern.

Ein OSPF Network bezeichnet immer ein lokales Netz: SFOS aktiviert OSPF auf jedem Interface, dessen Adresse zum Eintrag passt, und kündigt dessen Präfix an. Für das LAN verwendet dieses Beispiel in Schritt 5 ebenfalls einen Network-Eintrag, weil sich damit im WebAdmin genau das gewünschte Präfix auswählen und wieder entfernen lässt. Der Nachteil ist, dass dadurch auch das LAN-Interface Teil von OSPF wird. Eine gefilterte Redistribution vermeidet dies, benötigt unter SFOS 22 aber eine separat geprüfte CLI-Konfiguration samt Rückbau.

4. Interface-Werte nur bewusst überschreiben

Unter Override interface configuration kann das Transit-Interface ausgewählt werden. Die Standardwerte passen für viele Ethernet-Verbindungen:

Hello interval: 10 Sekunden
Dead interval: 40 Sekunden
Retransmit interval: 5 Sekunden
Transmit delay: 1 Sekunde
Interface cost: Auto
Router priority: 1

Hello interval steuert den Abstand der Hello-Pakete zur Nachbarerkennung. Dead interval legt fest, wie lange ohne Hello gewartet wird, bevor ein Nachbar als nicht verfügbar gilt. SFOS setzt Dead automatisch auf das Vierfache von Hello; nach einer Hello-Änderung den berechneten Wert auf den zulässigen Bereich und die Übereinstimmung mit den Nachbarn prüfen. Dead kann auch manuell überschrieben werden. Retransmit interval steuert die erneute Übertragung von Link-State Advertisements (LSAs), Transmit delay die für ein Link-State-Update berücksichtigte Übertragungs- und Laufzeitverzögerung.

DR bedeutet Designated Router, BDR Backup Designated Router. Bei der Wahl wird die höhere Router Priority bevorzugt; bei gleicher Priority gewinnt die höchste Router ID.

Hello und Dead müssen auf allen Routern des Segments identisch sein. Retransmit Interval und Transmit Delay werden lokal gesetzt. Cost und Router Priority dürfen bewusst abweichen: Der Cost bestimmt den bevorzugten Datenpfad, während die Priority auf Broadcastnetzen die Wahl von DR und BDR beeinflusst. Eine Priority von 0 schliesst das Interface von dieser Wahl aus.

Bei gleicher Priority entscheidet die Router ID, eine laufende DR-Wahl ist jedoch nicht präemptiv. Ein manuell gesetzter Cost ist sinnvoll, wenn bei mehreren Pfaden einer bevorzugt werden soll. Bei Auto berechnet SFOS den Cost aus der globalen Reference Bandwidth und der konfigurierten Interface-Geschwindigkeit. Wird die Link-Geschwindigkeit unter Network > Interfaces geändert, übernimmt OSPF den neuen Auto-Cost erst nach einem Firewall-Neustart.

Bei MD5-Authentifizierung wird in der Area der Authentication Type MD5 gewählt. Danach werden am Transit-Interface auf beiden Seiten dieselbe Key ID von 0 bis 255 und derselbe Schlüssel hinterlegt.

Wird für OSPFv2 stattdessen Text gewählt, muss am Interface ein Authentifizierungspasswort hinterlegt und mit der Gegenstelle abgestimmt werden. Dies gilt nicht für OSPFv3, das keine Authentifizierung unterstützt.

Geänderte Interface-Werte werden mit Save übernommen.

5. Nur die benötigten LANs ankündigen

Für das Beispiel muss Firewall A 10.10.10.0/24 und Firewall B 10.20.20.0/24 ankündigen. Dafür gibt es zwei grundsätzlich unterschiedliche Wege:

Ein OSPF Network nimmt das passende lokale Interface in OSPF auf und kündigt sein Präfix an.
Redistribution übernimmt Routen aus einer anderen Routingquelle in OSPF.

Unter Routing > OSPF > Networks auf Add klicken und das jeweilige LAN der Area 0.0.0.0 zuweisen: auf Firewall A 10.10.10.0/24, auf Firewall B 10.20.20.0/24. Den Eintrag mit Save speichern. Dynamic Routing bleibt für die LAN-Zone deaktiviert; erlaubt ist der Dienst nur für die Transit-Zone beziehungsweise die enge Local Service ACL Exception. Danach muss die Gegenstelle genau dieses LAN lernen. Ein unerwünschtes lokales Netz dient als Negativkontrolle und darf nicht in ihrer OSPF-Routingtabelle erscheinen.

Diese Variante passt, solange die LAN-Interfaces bewusst Teil von OSPF sein dürfen. Soll OSPF dort grundsätzlich nicht aktiviert werden oder stammen die zu verteilenden Präfixe aus Static, RIP oder BGP, ist Redistribution die passendere Methode. Die Option Redistribute connected im WebAdmin übernimmt jedoch alle direkt verbundenen Netze. Auf einer produktiven Firewall können dazu auch WAN-, Management-, DMZ-, VPN- und weitere VLAN-Netze gehören. Deshalb darf die Checkbox nicht unbesehen aktiviert werden.

Beim Remote Access SSL VPN übernimmt Redistribute connected nur das dynamische Client-Subnetz. Ein statisch zugewiesenes SSL-VPN-Subnetz wird nicht automatisch injiziert und muss bei begründetem Bedarf als eigenes OSPF Network konfiguriert und separat geprüft werden.

WebAdmin kann Connected Routes nicht nach einzelnen Präfixen filtern. Die SFOS-22-Command-Line-Hilfe zeigt dafür zwar eine ACL mit Route Map, dokumentiert aber nur ein Ausschlussbeispiel und keinen vollständigen Rückbau einer produktiven Allowlist. Ohne einen auf der eingesetzten SFOS-Version geprüften Rückweg ist daraus kein sicheres Copy-and-paste-Rezept abzuleiten. Wer selektive Redistribution benötigt, plant deshalb die ACL und Route Map als eigene Routingänderung, lässt Syntax und Rückbau für den installierten Build bestätigen und prüft auf der Gegenstelle sowohl das gewünschte Präfix als auch mindestens ein Netz, das ausdrücklich nicht angekündigt werden darf.

Ab SFOS 23.0: Namen von Access Lists, Prefix Lists und Route Maps müssen über alle dynamischen Routingprotokolle hinweg eindeutig sein, weil sie in einer integrierten Konfiguration gespeichert werden. Beim Upgrade von einer früheren Version auf SFOS 23.0 oder neuer ergänzt Sophos Firewall bei einem Namenskonflikt automatisch Protokollpräfixe an den Namen von Route Maps, Prefix Lists und Access Lists und aktualisiert alle Referenzen auf die umbenannten Konfigurationen. Vor selektiver Redistribution oder Rückbau die vor dem Upgrade gesicherten Objektnamen und Referenzen mit der aktuellen Konfiguration vergleichen; ein alter Name darf nicht ungeprüft als aktuelle Bindung verwendet werden. Nach der Änderung oder dem Rückbau auf der Gegenstelle prüfen, dass gewünschte Präfixe vorhanden und ausdrücklich nicht erlaubte Präfixe abwesend sind. Vor Namenswahl und Rückbau alle Namen und Referenzen protokollübergreifend inventarisieren. Nur die zur Änderung gehörenden Referenzen gezielt zurücknehmen; gemeinsam genutzte Objekte nicht pauschal löschen. Andere Protokolle müssen ihre erwarteten Nachbarn und Routen behalten. Auch hier bleibt ein ausführbares Filterrezept ohne bestätigte Syntax und Rückbau zurückgehalten.

Die globale WebAdmin-Option Redistribute connected bleibt bei einer CLI-gefilterten Variante deaktiviert. Nach späteren Änderungen an der globalen OSPF-Konfiguration muss show running-config erneut geprüft werden, weil WebAdmin widersprechende erweiterte CLI-Einstellungen und Änderungen an log-adjacency-changes entfernen kann. Auch Redistribute static wird erst nach einer vollständigen Inventur der vorhandenen statischen Routen aktiviert.

OSPF in der CLI konfigurieren und zurücknehmen

SFOS 22, nur OSPFv2/IPv4: Die OSPF-CLI liegt unter 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF. Die folgende minimale Konfiguration für Firewall A bildet Transitnetz und LAN-Ankündigung des WebAdmin-Beispiels ab. Die dokumentierte SFOS-22-Folge mit exit und write im globalen ospf(config)#-Kontext bleibt hier erhalten.

⚠️ Vor ospf router-id auf einem bestehenden Router gilt dieselbe Vorprüfung wie im WebAdmin: Eine Änderung der bisherigen Router ID setzt laut SFOS-23-Hilfe alle OSPF-Sessions zurück. Die vorhandene ID nicht durch den Beispielwert ersetzen. Backup, unabhängigen Managementzugang, Nachbarn und Routen sichern und die Änderung im Wartungsfenster mit anschliessender Prüfung von Full-Nachbarschaften, gewünschten/unerwünschten Präfixen und echtem Traffic durchführen.

enable
configure terminal
router ospf
ospf router-id 192.0.2.10
network 198.51.100.0/30 area 0
network 10.10.10.0/24 area 0
log-adjacency-changes
exit
write
show running-config
end

SFOS 23, nur OSPFv2/IPv4: Unter 3. Route Configuration > 1. Configure Unicast Routing öffnet sich die gemeinsame Routing-Konsole bei router# (EXEC). configure terminal führt zu router(config)# (globale Konfiguration), router ospf zu router(config-ospf)#. Für dasselbe Beispiel werden ab router# folgende Befehle ohne die abgebildeten Prompts eingegeben:

router# configure terminal
router(config)# router ospf
router(config-ospf)# ospf router-id 192.0.2.10
router(config-ospf)# network 198.51.100.0/30 area 0
router(config-ospf)# network 10.10.10.0/24 area 0
router(config-ospf)# log-adjacency-changes
router(config-ospf)# end
router# show running-config
router# write

end kehrt direkt nach EXEC zurück. Die SFOS-23-Setup-Hilfe zeigt dort show running-config und write; ihr Hinweis verlangt dagegen allgemein do write. Das Filterbeispiel zeigt konkret router(config)# do write nach exit aus OSPF. Diese Dokumentationsspannung ist kein Nachweis, dass EXEC-write nicht speichert: Hier wird der mode-qualifizierte Setup-Ablauf verwendet, nicht ein nacktes write im SFOS-23-Konfigurationsmodus.

show running-config zeigt den laufenden Zustand, nicht den Nachweis einer Speicherung. Bei SFOS 23 nach write die Bestätigung für die integrierte Datei /conf/routing/frr.conf kontrollieren; das SFOS-22-Filterbeispiel nennt noch /conf/routing/ospfd.conf. Die Datei nicht von Hand bearbeiten. CLI-Änderungen müssen gespeichert werden, damit sie laut Sophos im WebAdmin erscheinen und einen Firewall- oder Daemon-Neustart überstehen. Die Speicherbestätigung und die erwarteten WebAdmin-Werte prüfen; ein Neustart ist hier kein vorgeschriebener Test und wurde für diesen Artikel nicht durchgeführt. Bei fehlender Bestätigung vor weiteren Änderungen mit Sophos klären. Danach Nachbarn, Routen und Traffic prüfen.

Auf Firewall B werden stattdessen die Router ID 192.0.2.20 und das LAN-Network 10.20.20.0/24 verwendet.

Die Router ID muss eindeutig sein, darf nicht 0.0.0.0 lauten und muss keine tatsächlich zugewiesene IP-Adresse sein. Ohne manuelle Vorgabe verwendet SFOS die höchste Interface-IP. Die Area ID darf als Zahl von 0 bis 4294967295 oder in IPv4-Schreibweise eingegeben werden. SFOS speichert das Network entsprechend der Maske normalisiert; aus 198.51.100.1/30 wird deshalb 198.51.100.0/30. Genau dieser gespeicherte Wert ist später für Kontrolle und Entfernung massgebend. log-adjacency-changes protokolliert Neighbor-Wechsel ohne Debug-Modus und wird bei einer WebAdmin-Konfiguration standardmässig gesetzt.

Network, OSPF-Prozess und Default Route unterscheiden

SFOS 22, OSPFv2/IPv4: Um nur ein Network zurückzunehmen, wird die normalisierte Zeile aus show running-config unter router ospf mit no entfernt. Vor dem Entfernen des Transitnetzes alternative Routen, Backup und unabhängigen Managementzugang sichern und ein Wartungsfenster planen; die Nachbarschaft auf diesem Segment fällt weg:

enable
configure terminal
router ospf
no network 198.51.100.0/30 area 0
exit
write
show running-config
end

Dadurch endet OSPF auf den dazugehörigen Interfaces und die betroffenen Ankündigungen verschwinden. no router ospf entfernt dagegen die OSPFv2-Routingkonfiguration. Vor diesem destruktiven Schritt werden die vollständige laufende Konfiguration, ein Backup und alternative Routen gesichert; der Befehl gehört in ein Wartungsfenster und ist kein vorübergehender Ein-/Aus-Schalter.

SFOS 23, OSPFv2/IPv4: Für dieselbe Network-Entfernung bei router# in der gemeinsamen Konsole beginnen. Die SFOS-23-Übersicht dokumentiert no network bei router(config-ospf)#; anschliessend gilt derselbe EXEC-Prüf- und Speicherablauf wie oben:

router# configure terminal
router(config)# router ospf
router(config-ospf)# no network 198.51.100.0/30 area 0
router(config-ospf)# end
router# show running-config
router# write

Nach der Entfernung müssen genau der beabsichtigte Network-Eintrag und seine Ankündigung fehlen; verbleibende Nachbarn, alternative Routen, Managementzugang und Traffic müssen wie geplant funktionieren. Die Speicherbestätigung ebenfalls prüfen. Zur gezielten Rücknahme dieser Änderung den zuvor gesicherten network … area …-Eintrag im versionsgerechten OSPF-Kontext wiederherstellen, speichern und erneut prüfen.

Für die vollständige Prozessentfernung nennt SFOS 22 ospf(config)# no router ospf, die SFOS-23-Übersicht dagegen router(config-ospf)# no router ospf. Das ist ein dokumentierter Promptwechsel, kein bewiesener Befehlsfehler. Der SFOS-23-Kontext wurde hier nicht auf einem Gerät bestätigt. Deshalb wird keine ausführbare SFOS-23-Prozessentfernung angeboten, bis Sophos den Kontext und Wiederherstellungsweg für den installierten Build bestätigt hat; nicht aus Intuition in einen anderen Modus wechseln. Dabei keine gemeinsamen ACLs, Prefix Lists oder Route Maps pauschal löschen.

ospf push-default-route-to-kernel löst eine dritte, getrennte Aufgabe: Eine über OSPF gelernte Default Route wird in die Kernel-Routingtabelle übernommen. Der Befehl kündigt keine Default Route an die Neighbors an und ist daher nicht dasselbe wie Default-information originate. Vorher werden bestehende Default Routes, Route Precedence, Management-Rückweg und Route Lookup gesichert. Der offiziell dokumentierte Rückbau erfolgt am OSPF-Prompt mit no ospf push-default-route-to-kernel; danach werden Routingtabelle, Route Lookup, Managementzugang und echter Traffic erneut geprüft.

Globale Änderungen im WebAdmin können widersprechende CLI-Einstellungen entfernen. Nach jeder solchen Änderung werden show running-config, Neighbor, gelernte Routen und die gespeicherte Konfiguration erneut geprüft.

OSPF prüfen und abnehmen

Eine Nachbarschaft allein beweist noch nicht, dass das gewünschte LAN erreichbar ist. Die Abnahme erfolgt deshalb von der OSPF-Ebene bis zum echten Paketfluss.

Unter Routing > Information > OSPF > Neighbors muss die Gegenstelle mit ihrer Router ID erscheinen. Full zeigt, dass die relevanten Link-State-Informationen vollständig ausgetauscht wurden.
Unter Routes muss Firewall A 10.20.20.0/24 über 198.51.100.2 sehen. Firewall B erwartet 10.10.10.0/24 über 198.51.100.1. Ein nicht freigegebenes Testpräfix darf dagegen nicht auftauchen.
Unter Interface werden Area, Router ID, Cost, Timer, Network Type und MTU kontrolliert. Database zeigt die Link-State-Datenbank; Border routers hilft bei Mehr-Area-Designs, ABR- und ASBR-Einträge zu prüfen.
Unter Diagnostics > Tools > Route lookup wird ein konkretes Ziel geprüft, beispielsweise 10.20.20.10 auf Firewall A.
Danach wird eine echte Verbindung zwischen je einem Host aus beiden LANs getestet. Log Viewer und Packet Capture müssen die erwartete Firewall-Regel, das Transit-Interface und den Rückverkehr zeigen.

Für die letzten beiden Schritte hilft Sophos Firewall Regel mit Log Viewer und Packet Capture testen.

Für eine zusätzliche SSH-Nachkontrolle führt der CLI-Pfad in SFOS 22 über 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF, in SFOS 23 über 3. Route Configuration > 1. Configure Unicast Routing zur gemeinsamen Konsole. In SFOS 23 mit end zu router# zurückkehren und dort show running-config ausführen. Der Befehl zeigt die laufende Konfiguration, nicht den Beweis ihrer Speicherung; die separate Speicherbestätigung ist oben erklärt. Neighbor, Database, Interfaces und berechnete Routen werden in SFOS 22 belastbar unter Routing > Information > OSPF geprüft; deshalb nennt dieser Artikel keine undokumentierten Routing-Daemon-Show-Befehle.

In der Advanced Shell liefern die OSPF- und Kernel-Logs zusätzlichen Kontext. Der Zugang führt über 5. Device Management > 3. Advanced Shell:

cd /log
tail -f ospfd.log

Die laufende Ausgabe wird mit Ctrl+C beendet. Danach kann der zweite Log geprüft werden:

tail -f zebra.log

ospfd.log zeigt OSPF-Ereignisse. zebra.log hilft zu prüfen, ob eine dynamisch gelernte Route in den Kernel übernommen wurde. Wer nicht live mitlesen möchte, verwendet beispielsweise less /log/ospfd.log. Weitere Dateien ordnet Sophos Firewall Service- und Logdateien den zuständigen Diensten zu.

Fehler systematisch eingrenzen

Kein Neighbor erscheint

Zuerst die direkte Erreichbarkeit der Transit-IPs prüfen. Danach müssen das Transit-Interface up, das OSPF Network passend zur lokalen Interface-IP und Dynamic Routing in der richtigen Zone aktiviert sein. Area, Subnetzmaske, Authentication Type, Key ID, Schlüssel, Hello und Dead müssen auf beiden Seiten übereinstimmen. Doppelte Router IDs verhindern ebenfalls einen sauberen Aufbau.

Neighbor bleibt auf Init oder 2-Way

Init bedeutet, dass Hello-Pakete ankommen, die Kommunikation aber noch nicht in beide Richtungen bestätigt ist. Device Access, asymmetrische Filter, Interface-Zuordnung und Rückweg sind dann die ersten Prüfpunkte.

2-Way ist in einem Broadcast-Netz zwischen zwei Routern normal, wenn beide weder DR noch BDR sind. Im Beispiel mit genau zwei OSPF-Routern und Priority 1 werden die beiden Teilnehmer zu DR und BDR; ihre Nachbarschaft sollte deshalb Full erreichen. Bleibt sie auf 2-Way, sind Router Priority, Network Type und die Gegenstelle zu kontrollieren.

Neighbor bleibt auf ExStart, Exchange oder Loading

In diesen Zuständen hat die Synchronisation der Link-State Database begonnen, wird aber nicht abgeschlossen. Häufige Ursachen sind unterschiedliche MTU-Werte, unpassende Network Types, doppelte Router IDs oder instabile Verbindungen. Unter Routing > Information > OSPF > Interface stehen MTU, MTU Mismatch Detection, Network Type und Timer für den Vergleich bereit.

Neighbor ist Full, aber das entfernte LAN fehlt

Dann funktioniert die Nachbarschaft, aber das LAN wird nicht angekündigt. Bei der in diesem Beispiel verwendeten Network-Methode muss auf der sendenden Firewall die Connected Route vorhanden sein und unter router ospf der passende network … area …-Eintrag erscheinen. show running-config zeigt den normalisierten Wert in der laufenden Konfiguration, nicht den Speicherstatus.

Wird stattdessen Redistribution verwendet, müssen die gewählte Routingquelle sowie gegebenenfalls ACL, Route Map und redistribute … route-map zum gewünschten Präfix passen. Bei Redistribute connected ist zusätzlich die vollständige Liste aller angekündigten Connected Routes zu kontrollieren.

Fehlt nach einem Upgrade auf SFOS 22 ausgerechnet ein Netz hinter einem policy-based IPsec-Tunnel, kann die Abhängigkeit von redistribute kernel die Ursache sein. Der Tunnel und der OSPF Neighbor können dabei weiterhin gesund aussehen; SFOS 22: IPsec-Routen und redistribute kernel erklärt die Prüfung und das route-based XFRM-Zieldesign.

Die Route ist vorhanden, aber der Traffic funktioniert nicht

OSPF hat seine Aufgabe erfüllt, wenn die Route mit richtigem Next Hop vorhanden ist. Danach liegen Fehler meist bei Firewall-Regel, NAT, Route Precedence, Rückweg oder Zielsystem. Bei normal gerouteten Standortnetzen ist meist kein SNAT nötig, weil beide Firewalls die LANs über OSPF kennen sollen.

OSPF über route-based IPsec

OSPF kann auch über ein XFRM-Interface eines route-based Site-to-Site-IPsec-Tunnels laufen. Damit SFOS die XFRM-Interfaces erstellt, müssen lokales und entferntes Subnetz auf beiden Seiten Any sein. Die Einstellung IPv4, IPv6 oder Dual bestimmt anschliessend die verwendeten IP-Versionen; bei Dual werden getrennte IPv4- und IPv6-Firewall-Regeln manuell angelegt. Mit spezifischen Traffic Selectors entsteht kein adressierbares XFRM-Interface, dem man IP-Adressen oder Routen zuweisen könnte.

Für diese Variante gelten zusätzlich:

Dynamic Routing wird unter Administration > Device access für die VPN-Zone erlaubt.
Das XFRM-Transitnetz wird als OSPF Network eingetragen.
Die Nutzdaten benötigen passende IPv4- beziehungsweise IPv6-Firewall-Regeln für die VPN-Zone.
Hello, Dead, Authentifizierung und MTU müssen zur Gegenstelle passen.
Der angezeigte OSPF Network Type wird auf beiden Seiten verglichen. Eine Abweichung kann den Aufbau der Nachbarschaft verhindern und muss im Design der beiden Endpunkte geklärt werden.

Ein grüner IPsec-Tunnel und ein OSPF Neighbor auf Full sind getrennte Prüfpunkte. Erst die gelernte Route und ein echter Paketfluss bestätigen den gesamten Aufbau.

Die offizielle HA-Hilfe garantiert keine Übernahme des OSPF-Adjacency-Zustands. In einem HA-Cluster gehört deshalb ein geplanter Failover zum Abnahmetest der konkreten Topologie. Danach wird auf dem aktiven Node geprüft, ob Neighbor, Routen sowie ospfd.log und zebra.log wieder den erwarteten Zustand zeigen.

OSPFv3 für IPv6

Grenze der SFOS-23-CLI-Hilfe: Die Setup-Hilfe ergänzt router ospf6 und erklärt, dieselben Schritte gälten für OSPFv3, zeigt danach aber weiterhin IPv4-OSPF-Router-ID- und Network-Befehle. Die Filterhilfe ergänzt IPv6-ACLs, behält im weiteren Ablauf jedoch match ip address und router ospf bei. Damit ist kein vollständiger, belastbarer IPv6-Ablauf für Matching, Redistribution und Rückbau belegt. Die CLI-Beispiele oben gelten ausschliesslich für OSPFv2/IPv4. Für IPv6 bleibt der folgende interfacebasierte WebAdmin-Weg erhalten; einen IPv6-CLI-Ablauf erst nach Bestätigung durch Sophos für den installierten Build verwenden. IPv4-Befehle nicht durch Tokenaustausch anpassen und keine upstream-FRR-Befehle als Sophos-Unterstützung übernehmen.

Unter Routing > OSPFv3 wird IPv6-Routing unabhängig von OSPFv2 konfiguriert. Die Router ID bleibt dabei ein eindeutiger Wert in IPv4-Schreibweise. SFOS zeigt für Default metric zwar 0, verwendet aber den nicht änderbaren Wert 20; ABR type ist fest auf Standard gesetzt. Die Auto-cost reference-bandwidth steht standardmässig auf 100000 Mbps. Für Default-information originate gibt es wie bei OSPFv2 Never, Regular und Always; im WebAdmin lassen sich Connected- und BGP-IPv6-Routen redistribuieren.

Im Unterschied zu OSPFv2 wird nicht zuerst ein Network eingetragen. Unter Interfaces wählt man das IPv6-fähige Interface und ordnet es einer Area zu. Für einen einfachen Aufbau wird auch hier Area 0.0.0.0 verwendet. Hello und Dead müssen auf dem Segment übereinstimmen; Cost, Retransmit, Transmit Delay und Router Priority werden passend zur eigenen Topologie gesetzt. SFOS unterstützt pro Interface nur eine OSPFv3-Instanz. Die Instance ID ist konfigurierbar; ihr Standardwert ist 0.

Zuerst unter Routing > OSPFv3 > Interfaces and areas > Areas auf Add klicken, Area in IPv4-Schreibweise eintragen, Type passend zum Design wählen und mit Save speichern. Für das einfache Beispiel ist die Area 0.0.0.0. Danach unter Routing > OSPFv3 > Interfaces and areas > Interfaces auf Add klicken, Interface auswählen und dieselbe Area ebenfalls in IPv4-Schreibweise eintragen.

Die OSPFv3-Defaults sind Hello 10, Dead 40, Retransmit 5 und Transmit delay 1 Sekunde sowie Router priority 1. Feldzwecke, automatische Dead-Berechnung und die Prüfung des zulässigen Bereichs gelten wie im Interface-Schritt für OSPFv2. Auch die DR/BDR-Wahl bevorzugt höhere Priority, bei Gleichstand die höchste Router ID; 0 schliesst die Wahl aus. Interface cost kann auf Auto bleiben oder durch Deaktivieren der Checkbox manuell gesetzt werden; kleinere Werte werden bevorzugt. Auto verwendet Reference Bandwidth und konfigurierte Interface-Geschwindigkeit. Nach einer Änderung der konfigurierten Link-Geschwindigkeit wird der neue Auto-Cost auch hier erst nach einem Firewall-Neustart verwendet. Die Interface-Konfiguration abschliessend mit Save speichern.

Zusätzliche OSPFv3-Areas können als Stub, Stub no-summary, NSSA oder NSSA no-summary angelegt werden. Die Varianten unterscheiden sich darin, welche externen und Summary-LSAs sie tragen; NSSA kann zusätzlich Type-7-LSAs aus einer eigenen Redistribution zum ABR weitergeben. Solche Area-Typen gehören in ein abgestimmtes Mehr-Area-Design und nicht in einen spontanen Reparaturversuch.

Stub trägt keine Type-4- oder Type-5-LSAs und erlaubt keine Virtual Links. Stub no-summary unterdrückt zusätzlich Type-3-LSAs ausser der Default Summary Route und erlaubt ebenfalls keine Virtual Links. NSSA empfängt keine externen Type-5-LSAs aus anderen Areas; eigene Type-7-LSAs werden innerhalb der NSSA transportiert und am ABR in Type-5-LSAs für das Backbone umgewandelt. NSSA no-summary unterdrückt Type 4 und 5 sowie Type 3 ausser der Default Summary Route, behält aber Type 7 und dessen Umwandlung am ABR bei. Diese LSA-Eigenschaften bedeuten nicht, dass SFOS im OSPFv3-WebAdmin RIP- oder Static-Redistribution anbietet.

Für die globale OSPFv3-Konfiguration nur die benötigten Ankündigungen wählen und die zugehörige Metrik sowie Metric type setzen. Die E1/E2-Bedeutung und die Wirkung von Never, Regular und Always sind im globalen OSPFv2-Schritt erklärt; insbesondere gilt die Warnung vor Always auch hier. Mit Apply übernehmen. Dabei können eigene Änderungen an log-adjacency-changes entfernt werden; danach die laufende und gespeicherte Konfiguration sowie Nachbarn, gewünschte und unerwünschte IPv6-Präfixe unter Routing > Information > OSPFv3 und den tatsächlichen IPv6-Traffic erneut prüfen.

Sophos Firewall unterstützt für OSPFv3 derzeit keine Authentifizierung. Der Austausch sollte deshalb nur über vertrauenswürdige oder bereits geschützte Links erfolgen. Eine vorhandene OSPFv2-Konfiguration kündigt keine IPv6-Netze an, und für den IPv6-Nutzdatenverkehr werden eigene IPv6-Firewall-Regeln benötigt.

Redistribute connected erfasst auch bei OSPFv3 alle direkt verbundenen IPv6-Netze und sollte daher nicht pauschal aktiviert werden. Laut Sophos wird beim Remote Access SSL VPN nur das dynamische Subnetz injiziert, nicht das statische. Die SFOS-22-Hilfe nennt für das statische Subnetz ein „OSPF network“, obwohl OSPFv3 im WebAdmin über Interfaces statt über eine Networks-Liste konfiguriert wird. Aus diesem Widerspruch lässt sich kein sicherer Ablauf ableiten; die Ankündigung eines statischen IPv6-SSL-VPN-Präfixes muss für den installierten Build mit Sophos geklärt werden.

Die Abnahme erfolgt unter Routing > Information > OSPFv3; bei Fehlern liefert ospf6d.log den protokollspezifischen Kontext.

Änderung sicher zurücknehmen

Vor dem Entfernen von OSPF muss für jedes gelernte Zielnetz ein alternativer Pfad oder ein geplantes Wartungsfenster vorhanden sein. Im Beispiel wird zuerst der LAN-Network-Eintrag entfernt, danach das Transit-Network und zuletzt Dynamic Routing für die Transit-Zone deaktiviert. Wird das LAN stattdessen redistribuiert, wird zuerst diese Redistribution zurückgenommen. Anschliessend werden Route Lookup, Routingtabelle und Managementzugang erneut geprüft.

Wird nur ein fehlerhafter Cost, Timer oder Filter zurückgenommen, sollte immer nur diese eine Einstellung geändert werden. So bleibt erkennbar, ob die OSPF-Nachbarschaft, die Routenankündigung oder erst der Nutzdatenverkehr betroffen war.