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)
| bereich = IT-Security
| dauer = ca. 20 Minuten (Installation und Grundeinrichtung), je Protokoll zusätzlich 20–40 Minuten
| rechte = Administrator (OPNsense-WebUI)
| stand = Oktober 2026 (OPNsense 26.7.5, os-frr 1.55)
}}
'''FRR auf OPNsense''' (Plugin ''os-frr'') bringt [[Dynamisches Routing|dynamisches Routing]] auf die Firewall: Mit '''BGP''', '''OSPF''', '''OSPFv3''' und '''RIP''' tauscht die OPNsense Routen automatisch mit anderen Routern, Firewalls, Rechenzentren oder Cloud-Plattformen aus. '''BFD''' erkennt Leitungsausfälle in Sekundenbruchteilen, und '''STATIC''' ergänzt statische Routen, die an BFD gekoppelt sind. FRRouting (FRR) ist eine verbreitete Open-Source-Routing-Suite und Nachfolger von Quagga – daher stammt auch das Kürzel ''quagga'' in den URLs des Plugins.

Dieser Artikel ist der Einstieg in die TechCorner-Serie zu FRR auf OPNsense (Stand Oktober 2026): Installation, allgemeine Einstellungen, Auswahl des passenden Protokolls, Hochverfügbarkeit mit CARP, Diagnose und Sicherheit. Die Protokolle selbst beschreiben eigene Artikel:
* [[OPNsense - BGP mit FRR]] – iBGP, eBGP mit dem Provider, Prefix-Listen und Route-Maps, BGP über VPN-Tunnel
* [[OPNsense - OSPF und OSPFv3 mit FRR]] – Areas, Interfaces, Redistribution, CARP-gesteuerte Kosten
* [[OPNsense - BFD mit FRR]] – schnelle Ausfallerkennung für BGP, OSPF und statische Routen

== Wann lohnt sich dynamisches Routing? ==
Laut OPNsense-Dokumentation verbessert dynamisches Routing die '''Ausfallsicherheit''' (fällt eine Verbindung aus, wird automatisch ein anderer Weg gefunden) und '''vereinfacht die Verwaltung''' (weniger manuelle Routen). Nicht sinnvoll ist es in kleinen Netzen, in denen ein paar statische Routen genügen, oder in Umgebungen, in denen jede Route bewusst von Hand kontrolliert werden muss.

Typische Einsatzfälle:
* '''Mehrere Standorte''' über [[OPNsense - IPsec Site-to-Site route-based|route-based IPsec]] oder [[OPNsense - WireGuard Site-to-Site und Road Warrior|WireGuard]] – neue Netze werden automatisch bekannt, Tunnel schwenken bei Ausfall um.
* '''Cloud-Anbindung''' an Azure VPN Gateway oder AWS Site-to-Site-VPN mit BGP.
* '''Eigener Adressraum''' (Provider-unabhängig) mit BGP zu einem oder mehreren Providern.
* '''Campus- und Rechenzentrumsnetze''' mit Layer-3-Switches, die per OSPF an die Firewall angebunden sind.

=== Welches Protokoll? ===
{| class="wikitable"
! Protokoll !! Typ !! Einsatz !! Artikel
|-
| '''[[BGP]]''' || Pfadvektor, zwischen [[Autonomes System|autonomen Systemen]] || Provider, Cloud, viele Standorte, Richtlinien (Route-Maps) || [[OPNsense - BGP mit FRR]]
|-
| '''[[OSPF]]''' (IPv4) / '''OSPFv3''' (IPv6) || Link-State, innerhalb eines Netzes || Campus, Rechenzentrum, schnelle Konvergenz zwischen eigenen Routern || [[OPNsense - OSPF und OSPFv3 mit FRR]]
|-
| '''BFD''' || Ausfallerkennung (kein Routingprotokoll) || ergänzt BGP, OSPF und statische Routen um Erkennung im Sekundenbereich || [[OPNsense - BFD mit FRR]]
|-
| '''RIP''' (v1/v2) || Distanzvektor || nur für Altgeräte – maximal 15 Hops, langsame Konvergenz || in diesem Artikel
|-
| '''STATIC''' || statische Routen über FRR || statische Routen, die bei BFD-Ausfall zurückgezogen werden || in diesem Artikel
|}

[[Datei:OPNsense-FRR-Routing.png|thumb|center|750px|FRR auf der OPNsense: Zebra verbindet die Routing-Daemons BGP, OSPF/OSPFv3, RIP, STATIC und BFD mit der Routing-Tabelle des Kernels; die Firewall tauscht Routen mit Providern, Cloud, Standorten und internen Layer-3-Switches aus.]]

== Installation und allgemeine Einstellungen ==
=== Plugin installieren ===
'''System → Firmware → Plugins''' → ''os-frr'' installieren und die Seite neu laden. Anschließend erscheint das Menü '''Routing''' mit ''General'', den Protokollseiten (''RIP'', ''OSPF'', ''OSPFv3'', ''BGP'', ''BFD'', ''STATIC'') und ''Diagnostics''.

{{Hinweis|Die OPNsense-Dokumentation empfiehlt dringend, unter '''System → Settings → Tunables''' den Wert <code>kern.ipc.maxsockbuf</code> auf <code>33554432</code> zu setzen (bzw. zu erhöhen, falls er kleiner ist) – sonst können bei vielen Routen, etwa einer vollständigen Internet-Routingtabelle, Meldungen verloren gehen.}}

=== Routing → General ===
{| class="wikitable"
! Einstellung !! Empfehlung
|-
| '''Enable''' || aktivieren – ohne diesen Schalter läuft keines der Protokolle. Auch ohne Protokoll startet dann ''zebra'', der Kern von FRR, der die Routen in den Kernel schreibt.
|-
| '''Profile''' || ''Traditional'' (Standard, IETF-konforme Vorgaben für WAN/Internet); ''Datacenter'' nur für eine einzige Verwaltungsdomäne mit aggressiven Timern
|-
| '''Enable CARP Failover''' || nur im HA-Cluster, siehe unten
|-
| '''Enable SNMP AgentX Support''' || wenn Routing-Daten per [[OPNsense - Net-SNMP Monitoring per SNMP|Net-SNMP]] abgefragt werden sollen
|-
| '''Enable logging''' / '''Log Level''' || aktiv, Level ''Notifications''; ''Debug'' nur zur Fehlersuche bzw. für OSPF-CARP-Demote
|-
| '''Firewall rules''' || automatische Regeln – erzeugt Regeln '''nur für OSPF/OSPFv3'''. BGP (TCP 179) und BFD (UDP 3784/4784) immer selbst freigeben. Für feinere Kontrolle deaktivieren und eigene Regeln anlegen.
|-
| '''Manual config''' || verwaltet <code>/usr/local/etc/frr/frr.conf</code> von Hand; die Protokollseiten werden dann ausgeblendet. Nur für Experten mit Funktionen, die die Oberfläche nicht bietet.
|}
Seit Plugin-Version 1.43 werden Änderungen per ''frr-reload'' unterbrechungsfrei übernommen; Sitzungen zu Nachbarn bleiben bei den meisten Änderungen bestehen.

== RIP (Legacy) ==
'''Routing → RIP''': ''Version'' 2 (classless), '''Networks''' in CIDR-Schreibweise, '''Passive Interfaces''' (z. B. WAN – dort keine RIP-Pakete senden), '''Route Redistribution''' (z. B. verbundene Netze) und '''Default Metric'''. RIP eignet sich höchstens zur Anbindung älterer Geräte, die nichts anderes beherrschen; für neue Netze OSPF oder BGP verwenden.

== STATIC: statische Routen mit BFD ==
'''Routing → STATIC''' verwaltet statische Routen über den FRR-Daemon ''staticd'' (''Network'' in CIDR, ''Gateway'', ''Interface''). Der Unterschied zu ''System → Routes'': Mit der Option '''BFD''' wird eine Route an eine BFD-Sitzung zum Next-Hop gekoppelt und bei einem Ausfall sofort zurückgezogen – so kann eine zweite Route mit höherer Distanz übernehmen. Details im Artikel [[OPNsense - BFD mit FRR]].

== Hochverfügbarkeit: FRR im CARP-Cluster ==
In einem [[OPNsense - Hochverfügbarkeit mit CARP und pfsync|HA-Cluster mit CARP]] (dem OPNsense-Pendant zu [[VRRP]]) müssen Routing und Firewall-Rolle zusammenpassen: Nur die Firewall, die gerade CARP-Master ist, soll den Verkehr anziehen. Das Plugin bietet dafür drei Mechanismen. Die FRR-Konfiguration wird in allen Fällen über '''System → High Availability''' (Dienst ''FRR'') auf den Backup übertragen; Router-IDs danach pro Firewall prüfen.

=== Mechanismus 1: Enable CARP Failover (Dienst starten/stoppen) ===
'''Routing → General → Enable CARP Failover'''. Technisch hängt sich das Plugin in die CARP-Ereignisse von OPNsense ein: Meldet eine CARP-Adresse den Wechsel zu '''MASTER''', startet die Firewall den kompletten FRR-Dienst; bei '''BACKUP''' wird er gestoppt. Der Backup betreibt also gar keine Routing-Daemons.
* '''Vorteile:''' einfach, keine doppelten Nachbarschaften, gut für BGP zum Provider über eine CARP-Adresse (bei getrennten Switches mit Unicast CARP).
* '''Nachteile:''' Nach einem Failover müssen alle Sessions und Nachbarschaften '''neu aufgebaut''' werden – je nach Protokoll und Timern einige Sekunden bis Minuten ohne gelernte Routen. Die Gegenstellen müssen die CARP-Adresse als Nachbar verwenden.
* '''Einschränkung:''' laut Dokumentation nicht mit den beiden folgenden Optionen kombinierbar – ist CARP Failover aktiv, werden CARP-Ereignisse nicht an OSPF weitergereicht.

=== Mechanismus 2: OSPF-Kosten abhängig vom CARP-Status (Depend on carp) ===
Beide Firewalls bleiben dauerhaft OSPF-Nachbarn; nur die '''Kosten''' ändern sich. Einstellung je Interface unter '''Routing → OSPF[v3] → Interfaces''':
* '''Depend on (carp):''' die CARP-Adresse (VHID), an die das Interface gekoppelt ist
* '''Cost:''' normale Kosten (leer = FRR-Standard)
* '''Cost (when demoted):''' hohe Kosten im Backup-Zustand, z. B. <code>1000</code>
Bei jedem CARP-Ereignis (und beim Start) prüft ein Skript des Plugins für jedes so konfigurierte Interface: Ist die CARP-Adresse '''nicht Master''', setzt es per ''vtysh'' die demoted-Kosten (Log: ''ospfd demote interface …''); wird sie wieder Master, stellt es die normalen Kosten wieder her (''ospfd promote interface …''). Die Nachbarschaften bleiben dabei bestehen – die anderen Router berechnen nur den Weg neu, das Umschalten geht deshalb sehr schnell.
* '''Geeignet für:''' Firewall-Cluster, die per OSPF mit Core-Switches oder Routern verbunden sind.
* '''Hinweis:''' Die Kosten auf '''allen''' OSPF-Interfaces koppeln, über die Verkehr in den Cluster fließt, und jeweils die VHID desselben Netzes wählen.

=== Mechanismus 3: CARP demote durch OSPF (Rolle abhängig vom Routing) ===
'''Routing → OSPF[v3] → General → CARP demote''' kehrt die Richtung um: Nicht CARP steuert das Routing, sondern OSPF beeinflusst CARP. Das Plugin registriert einen Statusmonitor im CARP-Dienststatus von OPNsense; er fragt per ''vtysh'' die OSPF-Nachbarn ab und meldet einen Fehler, wenn '''kein Nachbar im Zustand „Full“''' ist. OPNsense erhöht daraufhin den CARP-Demotion-Wert dieser Firewall (Systemwert <code>net.inet.carp.demotion</code>) um einen festen, sehr hohen Betrag (2<sup>20</sup>) – sie wird für CARP unattraktiver und gibt die Master-Rolle an den Partner ab. Sobald wieder ein Nachbar ''Full'' ist, wird der Betrag zurückgenommen. Den aktuellen Wert zeigt ''Interfaces → Virtual IPs → Status''.
* Ausgelöst wird die Prüfung durch OSPF-Meldungen im Systemlog. Laut OPNsense-Dokumentation werden die relevanten Nachbarschaftsmeldungen nur mit '''Log Level Debug''' (''Routing → General'') geschrieben – ohne Debug reagiert der Monitor nicht zuverlässig; das Log wird dadurch deutlich umfangreicher.
* '''Geeignet für:''' Fälle, in denen eine Firewall zwar läuft, aber ihre Upstream-Verbindung (OSPF-Nachbarn) verloren hat und deshalb nicht Master bleiben soll.
* Mechanismus 2 und 3 lassen sich kombinieren: CARP demote sorgt für die richtige Master-Rolle, Depend on (carp) für die passenden Kosten.

=== Welche Variante wann? ===
{| class="wikitable"
! Situation !! Empfehlung
|-
| BGP zum Provider über eine CARP-Adresse || '''CARP Failover''' – nur der Master hält die Session (Timer bzw. BFD für schnellen Neuaufbau beachten)
|-
| Cluster per OSPF an Core-Switches || '''Depend on (carp)''' mit Cost (when demoted), optional zusätzlich '''CARP demote'''
|-
| Uplink-Ausfall soll Failover auslösen || '''CARP demote''' (OSPF) bzw. Gateway-/Interface-Überwachung von CARP
|-
| BGP auf beiden Firewalls gleichzeitig || keine CARP-Option; eigene Sessions pro Firewall und Pfadwahl über Local Preference/AS-Path-Prepending (siehe [[OPNsense - BGP mit FRR]])
|}

=== Failover testen ===
# Unter ''Interfaces → Virtual IPs → Status'' auf dem Master '''Enter Persistent CARP Maintenance Mode''' wählen.
# Beim CARP Failover: auf dem neuen Master ''Routing → Diagnostics'' prüfen, ob die Sessions wieder ''Established''/''Full'' sind.
# Bei Depend on (carp): im Log ''ospfd demote/promote interface'' prüfen und auf den Nachbarn die neuen Kosten bzw. Wege kontrollieren.
# Maintenance Mode wieder beenden und das Zurückschwenken prüfen.

== Diagnose ==
'''Routing → Diagnostics''' zeigt den Zustand ohne Konsole:
* '''General''' – Routing-Tabelle von zebra, Konfiguration und Status der Daemons
* '''OSPF''' / '''OSPFv3''' – Nachbarn, Datenbank, Interfaces, Routen
* '''BGP''' – Zusammenfassung der Nachbarn, empfangene und angekündigte Routen
* '''BFD''' – Sitzungen, Zähler
* '''Log''' – Meldungen aller FRR-Daemons
Die von FRR gelernten Routen erscheinen zusätzlich in der normalen Routing-Tabelle unter ''System → Routes → Status''.

== Sicherheitsempfehlungen ==
* Routing-Protokolle '''nur auf den nötigen Schnittstellen''' sprechen lassen (OSPF: Passive Interfaces; BGP: nur definierte Nachbarn) und '''nie unkontrolliert auf dem WAN'''.
* Firewall-Regeln für BGP (TCP 179), BFD (UDP 3784/4784) und OSPF (IP-Protokoll 89) auf die Adressen der Nachbarn beschränken.
* '''Authentifizierung''' nutzen: BGP-MD5-Passwort, OSPF-MD5.
* '''Filter''' setzen: Prefix-Listen und Route-Maps für ein- und ausgehende Routen – insbesondere zum Provider, damit keine internen RFC-1918-Netze angekündigt und nur erwartete Präfixe angenommen werden.
* Änderungen an laufenden Routing-Daemons vorsichtig vornehmen: Wird ein Daemon deaktiviert, können Routen verschwinden, über die die Verwaltung der Firewall läuft.
* Routing-Logs an ein SIEM übertragen, z. B. mit dem [[OPNsense - Wazuh-Agent|Wazuh-Agent]]; Nachbarschaftswechsel (''Log Neighbor Changes'' / ''Log Adjacency Changes'') aktivieren.

== Typische Probleme und Lösungen ==
{| class="wikitable"
! Symptom !! Ursache und Lösung
|-
| Keine Protokollseiten im Menü || ''Manual config'' aktiv oder Plugin-Seite nach der Installation nicht neu geladen.
|-
| Nachbarschaft kommt nicht zustande || Firewall-Regel fehlt (BGP TCP 179, OSPF Protokoll 89, BFD UDP 3784), falsche Adressen/AS-Nummern, MTU-Unterschiede (OSPF) – ''Routing → Diagnostics → Log'' prüfen.
|-
| Routen werden gelernt, aber nicht genutzt || Administrative Distanz (eine statische Route gewinnt), Network Import-Check (BGP) oder fehlende Firewall-Regeln für den eigentlichen Verkehr.
|-
| Backup-Firewall routet im HA-Cluster falsch || CARP-Strategie fehlt – ''Enable CARP Failover'' oder OSPF-Kosten per ''Depend on (carp)'' einrichten.
|-
| Meldungen gehen bei vielen Routen verloren || Tunable <code>kern.ipc.maxsockbuf</code> auf 33554432 erhöhen.
|-
| Verwaltung nach Änderung nicht mehr erreichbar || Route zur Verwaltungsstation kam über FRR – per Konsole Daemon wieder aktivieren bzw. statische Route ergänzen.
|}

== Fazit ==
Mit ''os-frr'' wird die OPNsense zum vollwertigen Router: BGP für Provider, Cloud und viele Standorte, OSPF für das interne Netz, BFD für schnelle Umschaltung und CARP-Integration für den Cluster-Betrieb. Wichtig sind eine saubere Planung (Router-IDs, AS-Nummern, Areas), Filter für ein- und ausgehende Routen und passende Firewall-Regeln. Die Protokolle im Detail beschreiben die Artikel zu [[OPNsense - BGP mit FRR|BGP]], [[OPNsense - OSPF und OSPFv3 mit FRR|OSPF]] und [[OPNsense - BFD mit FRR|BFD]].

== Unterstützung von m.a.x. it ==
Sie möchten Standorte, Rechenzentren oder Cloud-Umgebungen mit dynamischem Routing auf OPNsense verbinden oder einen hochverfügbaren Cluster mit BGP 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 - BGP mit FRR]]
* [[OPNsense - OSPF und OSPFv3 mit FRR]]
* [[OPNsense - BFD mit FRR]]
* [[Dynamisches Routing]]
* [[Routing]]
* [[Routing-Tabelle]]
* [[OPNsense - IPsec Site-to-Site route-based]]
* [[OPNsense - WireGuard Site-to-Site und Road Warrior]]
* [[OPNsense - Plugin-Liste]]

== Links und Quellen ==
* [https://docs.opnsense.org/manual/dynamic_routing.html OPNsense-Doku – Dynamic Routing (FRR)]
* [https://github.com/opnsense/plugins/tree/stable/26.7/net/frr Quellcode des Plugins os-frr]
* [https://docs.frrouting.org/en/latest/ FRRouting-Dokumentation]
* [https://www.max-it.de/it-services/opnsense/ m.a.x. it – OPNsense-Firewall-Services]

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

OPNsense - FRR Dynamisches Routing - Versionsgeschichte

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