imported>TechCorner-Redaktion: Verlinkung auf den Artikel OPNsense - Hochverfügbarkeit mit CARP und pfsync ergänzt

2026-10-08T00:00:00Z

Verlinkung auf den Artikel OPNsense - Hochverfügbarkeit mit CARP und pfsync ergänzt

Neue Seite

{{Steckbrief
| gilt_fuer = 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 ==
{| class="wikitable"
! 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)
|}

[[Datei:OPNsense-OSPF-FRR.png|thumb|center|750px|OSPF auf der OPNsense: Firewall und Layer-3-Switch bilden über ein Peering-Netz eine Nachbarschaft in der Backbone-Area 0.0.0.0; LAN und WAN sind passiv, Filialnetze liegen in einer Stub-Area. Im CARP-Cluster erhöht der Backup per ''Depend on (carp)'' seine Kosten.]]

== 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.
{| class="wikitable"
! Eigenschaft !! Router A !! Router B
|-
| LAN || <code>192.168.1.0/24</code> || <code>192.168.200.0/24</code>
|-
| Peering-Netz <code>10.1.1.0/30</code> || <code>10.1.1.1</code> (Interface ''Peering'') || <code>10.1.1.2</code>
|-
| Router-ID || <code>10.1.1.1</code> || <code>10.1.1.2</code>
|}

=== 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 ===
{| class="wikitable"
! Einstellung !! Empfehlung
|-
| Enable || aktiv
|-
| Router ID (erweitert) || fest setzen, z. B. <code>10.1.1.1</code>
|-
| '''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''' = <code>0.0.0.0</code>. 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 ==
{| class="wikitable"
! 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:
{| class="wikitable"
! 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 [[OPNsense - Hochverfügbarkeit mit CARP und pfsync|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. <code>1000</code>) 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 [[OPNsense - FRR Dynamisches Routing#Hochverfügbarkeit: FRR im CARP-Cluster|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 <code>ff02::5</code>, <code>ff02::6</code> und Link-Local-Adressen (<code>fe80::/10</code>).
* 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 ==
{| class="wikitable"
! 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 [[OPNsense - BGP mit FRR|BGP]] das Konzept, für Umschaltzeiten unter einer Sekunde [[OPNsense - BFD mit FRR|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 [https://www.max-it.de/it-services/opnsense/ OPNsense-Firewall-Services von m.a.x. it] und einer [https://www.max-it.de/it-services/managed-firewall/ 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 ==
* [https://docs.opnsense.org/manual/dynamic_routing.html OPNsense-Doku – Dynamic Routing (FRR)]
* [https://docs.opnsense.org/manual/how-tos/dynamic_routing_ospf.html OPNsense-Doku – OSPF Tutorials]
* [https://docs.frrouting.org/en/latest/ospfd.html FRRouting-Dokumentation – OSPFv2]
* [https://www.max-it.de/it-services/opnsense/ m.a.x. it – OPNsense-Firewall-Services]

{{Uebermax}}
[[Kategorie:IT-Security]]

OPNsense - OSPF und OSPFv3 mit FRR - Versionsgeschichte

imported>TechCorner-Redaktion: Verlinkung auf den Artikel OPNsense - Hochverfügbarkeit mit CARP und pfsync ergänzt