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.

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 sollte nur auf dafür vorgesehenen, vertrauenswürdigen Transit- oder VPN-Interfaces laufen. Dynamic Routing nicht pauschal für LAN- und WAN-Zonen freigeben und Redistribute connected nicht aktivieren, bevor klar ist, welche direkt verbundenen Netze dadurch angekündigt werden.

OSPF in sieben Schritten

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.
Nur die tatsächlich benötigten LAN-Routen ankündigen.
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.

Sophos Firewall ordnet dynamisch gelernte Routen in der globalen Route Precedence der Kategorie static zu. Konkurriert eine OSPF-Route mit einer SD-WAN- oder VPN-Route, muss deshalb auch die Route Precedence zum gewünschten Paketfluss passen. Innerhalb von OSPF entscheidet dagegen der Cost.

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. Teilt das Transit-Interface seine Zone mit weiteren Netzen, sollte stattdessen eine Local Service ACL Exception den Dienst auf das Transitnetz und die vorgesehenen Gegenstellen begrenzen.

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

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.

Das lokale LAN wird nicht einfach als vermeintliches entferntes Ziel eingetragen. Ein zusätzlicher Network-Eintrag kann es zwar auch ohne Nachbar ankündigen, aktiviert OSPF aber gleichzeitig auf dem dazu passenden LAN-Interface. Wenn dort keine OSPF-Router vorgesehen sind, grenzt eine selektive Redistribution die Ankündigung sauberer ab.

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 aktiviert OSPF auf dem passenden lokalen Interface. Das passt, wenn dort weitere OSPF-Router eine Nachbarschaft bilden sollen.
Redistribution übernimmt eine Route aus einer anderen Routingquelle in OSPF. Damit kann ein direkt verbundenes LAN angekündigt werden, ohne dort eine OSPF-Nachbarschaft zu benötigen.

Im Beispiel werden die beiden LANs selektiv redistribuiert, weil auf ihren Interfaces keine weiteren OSPF-Router eine Nachbarschaft bilden sollen.

Die Option Redistribute connected im WebAdmin übernimmt 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.

Für eine selektive Ankündigung lässt sich im OSPF-CLI eine ACL mit einer Route Map verwenden. Nach der SSH-Anmeldung führt der Pfad über 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF. Das folgende Beispiel auf Firewall A erlaubt nur das lokale LAN 10.10.10.0/24:

enable
configure terminal
access-list ospf-connected-out permit 10.10.10.0/24
route-map ospf-connected-filter permit 10
match ip address ospf-connected-out
exit
router ospf
redistribute connected route-map ospf-connected-filter
exit
write
show running-config

Auf Firewall B wird im access-list stattdessen 10.20.20.0/24 verwendet. Die ACL hat implizit eine abschliessende Deny-Regel; nicht ausdrücklich erlaubte Connected Routes werden daher nicht über diese Route Map redistribuiert.

Die globale WebAdmin-Option Redistribute connected bleibt bei diesem Vorgehen deaktiviert. Nach späteren Änderungen an der globalen OSPF-Konfiguration muss show running-config erneut geprüft werden, weil WebAdmin widersprechende erweiterte CLI-Einstellungen entfernen kann.

Auch Redistribute static benötigt eine bewusste Filterung. Es erfasst unter anderem statische Blackhole-Routen, die sonst unbeabsichtigt an Nachbarrouter weitergegeben werden können.

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.
Unter Interface werden Area, Router ID, Cost, Timer, Network Type und MTU kontrolliert.
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:

enable
show ip ospf interface
show ip ospf database
show ip ospf neighbor
show ip ospf route

Damit lassen sich beteiligte Interfaces, Link-State Database, Neighbor-Status und die von OSPF berechneten Routen gemeinsam dokumentieren.

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 oder durch die Filterung nicht zugelassen. Auf der sendenden Firewall müssen Connected Route, ACL, Route Map und redistribute connected route-map zum gewünschten Prefix passen. show running-config zeigt die gespeicherte OSPF-Konfiguration.

Wurde stattdessen Redistribute connected im WebAdmin aktiviert, ist nicht nur das fehlende LAN, sondern die vollständige Liste aller dadurch angekündigten Netze zu kontrollieren.

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. Bei einem Any-to-Any- oder Dual-Stack-Tunnel weist man den XFRM-Interfaces auf beiden Seiten eindeutige IP-Adressen aus demselben Transitnetz zu. Bei spezifischen Traffic Selectors ist diese Adressierung nicht möglich.

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; lässt sie sich nicht im WebAdmin korrigieren, muss die Gegenstelle angepasst oder Sophos Support einbezogen 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.

In einem HA-Cluster kann OSPF nach einem Failover neu konvergieren. Deshalb sollte ein geplanter Failover getestet und danach auf dem aktiven Node geprüft werden, 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.

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 derzeit nur eine OSPFv3-Instanz mit der Standard-Instance-ID 0.

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.

Im WebAdmin lassen sich für OSPFv3 direkt verbundene IPv6-Netze und BGP-IPv6-Routen redistribuieren. Redistribute connected erfasst auch hier alle direkt verbundenen IPv6-Netze und sollte daher nicht pauschal aktiviert 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. Zuerst wird die Redistribution des lokalen LANs entfernt, danach das Transit-Network und zuletzt Dynamic Routing für die Zone deaktiviert. 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.