OPNsense - OSPF und OSPFv3 mit FRR
Auf einen Blick
| Gilt für | OPNsense 26.1 und 26.7 mit Plugin os-frr 1.55 (FRR 10), OSPFv2 (IPv4) und OSPFv3 (IPv6) |
|---|---|
| Bereich | IT-Security |
| Dauer | ca. 30 Minuten (zwei Router in der Backbone-Area) |
| Rechte | Administrator (OPNsense-WebUI) |
| Stand | Oktober 2026 (OPNsense 26.7.5, os-frr 1.55) |
OSPF auf OPNsense (Plugin os-frr) verbindet die Firewall per Link-State-Routing mit Layer-3-Switches, Routern und weiteren Firewalls im eigenen Netz. OSPF (Open Shortest Path First) berechnet aus den Verbindungsinformationen aller Router den kürzesten Weg, reagiert schnell auf Ausfälle und verteilt neue Netze automatisch. OSPFv2 arbeitet mit IPv4, OSPFv3 mit IPv6.
Dieser Artikel gehört zur Serie OPNsense - FRR Dynamisches Routing und zeigt die Einrichtung mit os-frr 1.55 (Stand Oktober 2026): Grundbegriffe, OSPF zwischen zwei Routern, Areas, Interface-Einstellungen, Redistribution und Filter, Hochverfügbarkeit mit CARP sowie OSPFv3 für IPv6.
OSPF-Grundbegriffe
| Begriff | Bedeutung |
|---|---|
| Router-ID | eindeutige Kennung jedes Routers im IPv4-Format; in CARP-Clustern fest vergeben |
| Area | Bereich des OSPF-Netzes; 0.0.0.0 ist die Backbone-Area, an die alle anderen Areas angebunden sein müssen |
| Nachbarschaft (Adjacency) | Router auf demselben Netz erkennen sich per Hello-Paketen (Multicast 224.0.0.5/224.0.0.6) und tauschen ihre Datenbank aus |
| Kosten (Cost) | Metrik pro Interface – niedrigere Kosten werden bevorzugt; standardmäßig aus der Bandbreite berechnet (Reference Cost) |
| DR/BDR | Designated Router in Broadcast-Netzen; per Priority beeinflussbar |
| Passive Interface | Netz wird angekündigt, aber auf dem Interface werden keine OSPF-Pakete gesendet (z. B. LAN, WAN) |
Szenario: OSPF zwischen zwei Routern
Wie in der OPNsense-Dokumentation: Zwei Firewalls (oder Firewall und Layer-3-Switch) mit eigenem LAN sind über ein Peering-Netz verbunden.
| Eigenschaft | Router A | Router B |
|---|---|---|
| LAN | 192.168.1.0/24 |
192.168.200.0/24
|
Peering-Netz 10.1.1.0/30 |
10.1.1.1 (Interface Peering) |
10.1.1.2
|
| Router-ID | 10.1.1.1 |
10.1.1.2
|
Schritt 1: Plugin und Firewall-Regeln
- os-frr installieren, Routing → General aktivieren (siehe OPNsense - FRR Dynamisches Routing).
- Mit Firewall rules in Routing → General erzeugt das Plugin automatisch Regeln für OSPF (IP-Protokoll 89) aus den konfigurierten Netzen zu 224.0.0.0/24, zur Firewall selbst und zum jeweiligen Netz. Alternativ die Option abschalten und auf der Peering-Schnittstelle eine eigene Regel anlegen: Pass, Protokoll OSPF, Quelle Peering-Netz, Ziel 224.0.0.5/224.0.0.6.
- Regeln für den eigentlichen Nutzverkehr zwischen den LANs (LAN- und Peering-Schnittstelle) nicht vergessen.
Schritt 2: Routing → OSPF → General
| Einstellung | Empfehlung |
|---|---|
| Enable | aktiv |
| Router ID (erweitert) | fest setzen, z. B. 10.1.1.1
|
| Passive Interfaces | LAN und WAN – nur das Peering-Interface spricht OSPF |
| Route Redistribution | Connected routes – damit werden die LANs angekündigt; optional per Route-Map filtern |
| Log Adjacency Changes | aktiv |
| Advertise Default Gateway | nur auf der Firewall mit Internetzugang aktivieren, die anderen Router erhalten dann eine Default-Route per OSPF (Always Advertise auch ohne eigene Default-Route) |
| Reference Cost (erweitert) | bei 10- oder 25-Gbit-Schnittstellen erhöhen (z. B. 100000 Mbit/s), damit schnelle Links unterschiedliche Kosten erhalten |
Schritt 3: Routing → OSPF → Interfaces
+: Interface = Peering, Area = 0.0.0.0. Damit spricht die Firewall auf diesem Interface OSPF in der Backbone-Area.
Alternativ lassen sich Netze über den Reiter Networks (Network Address, Mask, Area) zuordnen. Pro Umgebung am besten eine Methode konsequent verwenden – entweder Interfaces mit Area oder Networks.
Schritt 4: Prüfen
Unter Routing → Diagnostics → OSPF muss der Nachbar im Zustand Full erscheinen; die Routen des anderen LANs stehen in der Routing-Tabelle (System → Routes → Status).
Interface-Einstellungen im Detail
| Feld | Zweck |
|---|---|
| Authentication Type / Key | MD5 (empfohlen) oder plain – auf allen Routern eines Netzes identisch |
| Cost | feste Kosten statt Berechnung aus der Bandbreite – z. B. Backup-Leitung teurer machen |
| Hello Interval / Dead Interval | müssen auf beiden Seiten übereinstimmen; für schnellere Erkennung besser BFD nutzen |
| Priority | DR-Wahl in Broadcast-Netzen (0 = nie DR) |
| Network Type | Broadcast (Standard für Ethernet), Point-to-point (Transfernetze, Tunnel – keine DR-Wahl, schnellere Nachbarschaft), NBMA bzw. Point-to-multipoint (ohne Multicast, dann Nachbarn unter Neighbors eintragen) |
| BFD | schnelle Ausfallerkennung, siehe OPNsense - BFD mit FRR |
| Depend on (carp) / Cost (when demoted) | Kosten abhängig vom CARP-Status, siehe unten |
Für OSPF über VPN-Tunnel (IPsec-VTI, WireGuard) den Network Type Point-to-point wählen und die MTU des Tunnels auf beiden Seiten gleich halten.
Areas und Zusammenfassung
Kleine und mittlere Netze kommen mit der Backbone-Area 0.0.0.0 aus. Bei vielen Standorten können weitere Areas die Datenbank verkleinern. Unter Areas werden nur Areas mit besonderem Verhalten angelegt:
| Area Type | Verhalten |
|---|---|
| stub | keine externen Routen (z. B. aus BGP), stattdessen Default-Route |
| stub no-summary | zusätzlich keine Routen aus anderen Areas – nur Default-Route (totally stubby) |
| nssa | wie stub, aber eigene externe Routen dürfen eingespeist werden |
| nssa no-summary | NSSA ohne Routen aus anderen Areas |
Mit Area Range im Reiter Networks werden mehrere Netze einer Area zu einem Präfix zusammengefasst.
Redistribution und Filter
- Route Redistribution (General): verbundene Netze, statische Routen, BGP oder Kernel-Routen in OSPF übernehmen – jeweils optional mit Route-Map.
- Prefix Lists und Route Maps (eigene Reiter) filtern, welche Netze angekündigt bzw. angenommen werden (Prefix-List In/Out je Netz).
- Typisch: nur die internen Netze ankündigen, keine Transfer- oder Verwaltungsnetze; bei Redistribution von BGP sehr zurückhaltend vorgehen.
Hochverfügbarkeit mit CARP
OSPF bietet im Plugin zwei feine Steuerungen für CARP-Cluster:
- Depend on (carp) und Cost (when demoted) je Interface: Ist die gewählte CARP-Adresse auf dieser Firewall nicht Master, setzt ein Skript des Plugins bei jedem CARP-Ereignis die Kosten des Interfaces per vtysh auf den „demoted“-Wert (z. B.
1000) und bei Rückkehr zum Master wieder auf Cost zurück (Log: ospfd demote/promote interface). Beide Firewalls bleiben OSPF-Nachbarn, die anderen Router schicken den Verkehr aber zum aktuellen Master – ohne Neuaufbau der Nachbarschaften. - CARP demote (General): Ein Statusmonitor prüft, ob mindestens ein OSPF-Nachbar im Zustand Full ist. Wenn nicht, erhöht OPNsense den CARP-Demotion-Wert und die Firewall gibt die Master-Rolle ab; sobald wieder ein Nachbar Full ist, wird das zurückgenommen. Voraussetzung ist Log Level Debug unter Routing → General, da die Nachbarschaftsmeldungen nur dann protokolliert werden.
- Beide Optionen lassen sich kombinieren, aber nicht mit Enable CARP Failover.
Alternativ stoppt Enable CARP Failover (Routing → General) FRR komplett auf dem Backup – einfacher, aber mit Neuaufbau der Nachbarschaften beim Failover. Router-IDs in jedem Fall pro Firewall fest vergeben. Funktionsweise, Entscheidungshilfe und Failover-Test beschreibt der Abschnitt Hochverfügbarkeit im Überblicksartikel.
OSPFv3 für IPv6
Routing → OSPFv3 ist ähnlich aufgebaut (Reiter General, Networks, Interfaces, Prefix Lists, Route Maps):
- Router ID ist Pflicht und wird im IPv4-Format angegeben (z. B. dieselbe wie bei OSPFv2).
- Interfaces mit Area zuordnen; Passive Interface wird hier pro Interface gesetzt.
- Die automatischen Firewall-Regeln erlauben OSPFv3 zu
ff02::5,ff02::6und Link-Local-Adressen (fe80::/10). - Depend on (carp), Cost (when demoted) und CARP demote stehen wie bei OSPFv2 zur Verfügung.
- Die Oberfläche bietet für OSPFv3 keine Authentifizierung – OSPFv3 daher nur auf vertrauenswürdigen Segmenten betreiben.
Sicherheitsempfehlungen
- OSPF nur auf Transfer- bzw. Peering-Schnittstellen aktiv; alle übrigen Schnittstellen als Passive Interfaces.
- MD5-Authentifizierung für OSPFv2 auf allen Peering-Netzen.
- Automatische Firewall-Regeln prüfen bzw. durch eigene, enger gefasste Regeln ersetzen.
- Advertise Default Gateway nur dort aktivieren, wo der Internetzugang tatsächlich liegt.
- Log Adjacency Changes aktivieren und Nachbarschaftswechsel überwachen.
Typische Probleme und Lösungen
| Symptom | Ursache und Lösung |
|---|---|
| Kein Nachbar sichtbar | Interface passiv, Firewall-Regel für Protokoll 89/Multicast fehlt, unterschiedliche Area, Hello/Dead-Intervalle oder Authentifizierung ungleich. |
| Nachbar hängt in ExStart/Exchange | MTU auf beiden Seiten unterschiedlich – angleichen. |
| Nachbar 2-Way statt Full | normal zwischen zwei DROthers in Broadcast-Netzen; bei zwei Routern Network Type Point-to-point wählen. |
| Netze werden nicht angekündigt | Redistribution fehlt, Netz keinem Interface/Network mit Area zugeordnet oder Prefix-Liste filtert. |
| Im CARP-Cluster läuft Verkehr über den Backup | Depend on (carp) und Cost (when demoted) fehlen. |
| CARP demote reagiert nicht | Log Level nicht auf Debug. |
| Router-ID-Konflikt | Router-IDs fest und eindeutig vergeben, insbesondere nach Synchronisation im HA-Cluster. |
Fazit
OSPF bindet die OPNsense schnell und robust in interne Routing-Domänen ein: Nachbarschaften über Peering-Netze, passive LANs, automatische Default-Route und Areas für größere Netze. Die CARP-Integration über abhängige Kosten macht OSPF besonders interessant für Firewall-Cluster. Für die Anbindung an Provider und Cloud ergänzt BGP das Konzept, für Umschaltzeiten unter einer Sekunde BFD.
Unterstützung von m.a.x. it
Sie möchten Ihre Firewall per OSPF in Campus- oder Rechenzentrumsnetze integrieren oder einen hochverfügbaren OPNsense-Cluster mit dynamischem Routing aufbauen? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit OPNsense-Firewall-Services von m.a.x. it und einer Managed Firewall von m.a.x. it.
Siehe auch
- OPNsense - Hochverfügbarkeit mit CARP und pfsync
- OPNsense - FRR Dynamisches Routing
- OPNsense - BGP mit FRR
- OPNsense - BFD mit FRR
- OSPF
- Dynamisches Routing
- MTU
- OPNsense - IPsec Site-to-Site route-based
Links und Quellen
- OPNsense-Doku – Dynamic Routing (FRR)
- OPNsense-Doku – OSPF Tutorials
- FRRouting-Dokumentation – OSPFv2
- m.a.x. it – OPNsense-Firewall-Services
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
