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

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.

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

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

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.

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

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:

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

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

Um nur ein Network zurückzunehmen, wird die Zeile aus show running-config unter router ospf mit no entfernt:

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.

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 über 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF. show running-config ist dort der offiziell dokumentierte Befehl für die gespeicherte OSPF-Konfiguration. 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 gespeicherten Wert.

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

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.

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.

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.