OPNsense - FRR Dynamisches Routing

Aus maxTechCorner

Auf einen Blick

Gilt fürOPNsense 26.1 und 26.7 mit Plugin os-frr 1.55 (FRR 10)
BereichIT-Security
Dauerca. 20 Minuten (Installation und Grundeinrichtung), je Protokoll zusätzlich 20–40 Minuten
RechteAdministrator (OPNsense-WebUI)
StandOktober 2026 (OPNsense 26.7.5, os-frr 1.55)

FRR auf OPNsense (Plugin os-frr) bringt 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:

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 route-based IPsec oder 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?

Protokoll Typ Einsatz Artikel
BGP Pfadvektor, zwischen 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
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.


HinweisDie OPNsense-Dokumentation empfiehlt dringend, unter System → Settings → Tunables den Wert kern.ipc.maxsockbuf auf 33554432 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

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 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 /usr/local/etc/frr/frr.conf 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 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. 1000

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 net.inet.carp.demotion) um einen festen, sehr hohen Betrag (220) – 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?

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

  1. Unter Interfaces → Virtual IPs → Status auf dem Master Enter Persistent CARP Maintenance Mode wählen.
  2. Beim CARP Failover: auf dem neuen Master Routing → Diagnostics prüfen, ob die Sessions wieder Established/Full sind.
  3. Bei Depend on (carp): im Log ospfd demote/promote interface prüfen und auf den Nachbarn die neuen Kosten bzw. Wege kontrollieren.
  4. 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 Wazuh-Agent; Nachbarschaftswechsel (Log Neighbor Changes / Log Adjacency Changes) aktivieren.

Typische Probleme und Lösungen

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 kern.ipc.maxsockbuf 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 BGP, OSPF und 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 OPNsense-Firewall-Services von m.a.x. it und einer Managed Firewall von m.a.x. it.

Siehe auch

Links und Quellen


Ü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? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=OPNsense_-_FRR_Dynamisches_Routing&oldid=3910“