OPNsense - BGP mit FRR

Aus maxTechCorner

Auf einen Blick

Gilt fürOPNsense 26.1 und 26.7 mit Plugin os-frr 1.55 (FRR 10), BGPv4 für IPv4 und IPv6
BereichIT-Security
Dauerca. 30 Minuten (iBGP zwischen zwei Standorten), ca. 45 Minuten (eBGP zum Provider mit Filtern)
RechteAdministrator (OPNsense-WebUI); bei eBGP Absprache mit dem Provider
StandOktober 2026 (OPNsense 26.7.5, os-frr 1.55)

BGP auf OPNsense wird mit dem Plugin os-frr umgesetzt und macht die Firewall zum vollwertigen Border-Router: Sie tauscht Routen mit Providern, Cloud-Plattformen und anderen Standorten aus, kündigt eigene Netze an und schwenkt bei Ausfällen automatisch auf einen anderen Weg um. BGP (Border Gateway Protocol) ist das Routingprotokoll des Internets und arbeitet zwischen autonomen Systemen (AS).

Dieser Artikel gehört zur Serie OPNsense - FRR Dynamisches Routing und zeigt die Einrichtung mit os-frr 1.55 (Stand Oktober 2026): Grundbegriffe, iBGP zwischen zwei Firewalls, eBGP zum Provider mit Prefix-Listen und Route-Maps, BGP über VPN-Tunnel, Peer-Groups, ECMP und Hochverfügbarkeit.

BGP-Grundbegriffe für OPNsense

Begriff Bedeutung
AS-Nummer Kennung des eigenen Netzes. Private 16-Bit-AS-Nummern: 64512–65534 (32-Bit: 4200000000–4294967294). Öffentliche AS-Nummern vergibt die RIPE NCC.
iBGP Nachbarn mit derselben AS-Nummer (eigene Standorte, eigene Router)
eBGP Nachbarn mit unterschiedlicher AS-Nummer (Provider, Cloud, Partner)
Neighbor konfigurierte Gegenstelle mit IP-Adresse und AS-Nummer; BGP nutzt eine TCP-Verbindung auf Port 179
Network Netze, die die OPNsense ankündigt
Redistribution andere Routenquellen (verbunden, statisch, OSPF) in BGP übernehmen
Prefix-Liste / Route-Map Filter und Richtlinien für ein- und ausgehende Routen (z. B. nur Default-Route annehmen, Local Preference setzen)
BGP auf der OPNsense: eBGP zum Provider (nur Default-Route annehmen, nur eigene Präfixe ankündigen), iBGP zu einer zweiten Firewall über ein Peering-Netz und BGP über VPN-Tunnel zu Filialen oder zur Cloud – jeweils mit Prefix-Listen und Route-Maps gefiltert.

Vorbereitung

  1. os-frr installieren und unter Routing → General aktivieren (siehe OPNsense - FRR Dynamisches Routing), Tunable kern.ipc.maxsockbuf = 33554432 setzen.
  2. Firewall-Regel für BGP: Die automatischen Regeln des Plugins decken BGP nicht ab. Auf der Schnittstelle zum Nachbarn eine Regel Pass, TCP, Quelle = Nachbar-IP, Ziel = eigene Adresse, Port 179 anlegen (Firewall → Rules).
  3. Für jede Firewall eine eindeutige Router-ID festlegen (z. B. die Loopback- oder LAN-Adresse).

Szenario 1: iBGP zwischen zwei Firewalls

Zwei Firewalls mit eigenem LAN sind über ein Peering-Netz verbunden und sollen ihre LANs automatisch austauschen (Beispiel nach der OPNsense-Dokumentation):

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 10.1.1.2
AS-Nummer 65011 (privat, beide gleich = iBGP)

Routing → BGP → General (beide Seiten):

  • enable, BGP AS Number 65011, optional Router ID
  • Network: das eigene LAN (z. B. 192.168.1.0/24) – oder im selben Reiter unter Route Redistribution die verbundenen Netze (Connected routes) übernehmen und per Route-Map filtern
  • Log Neighbor Changes aktivieren

Routing → BGP → Neighbors → +:

  • Peer-IP 10.1.1.2 (auf Router B: 10.1.1.1)
  • Remote AS mode Use Remote AS Number, Remote AS 65011 – alternativ Internal, das die eigene AS-Nummer übernimmt
  • Update-Source Interface: die Peering-Schnittstelle

Speichern. Unter Routing → Diagnostics → BGP sollte der Nachbar nach kurzer Zeit im Zustand Established mit empfangenen Präfixen erscheinen; die gelernten Routen stehen auch unter System → Routes → Status. Zusätzlich die Firewall-Regeln für den Nutzverkehr zwischen den LANs auf den LAN- und Peering-Schnittstellen anlegen.


HinweisNetwork Import-Check (erweitert, standardmäßig aktiv): BGP kündigt ein unter Network eingetragenes Netz nur an, wenn es in der Routing-Tabelle existiert. Das verhindert die Ankündigung nicht vorhandener Netze – erklärt aber auch, warum ein Netz scheinbar „nicht gesendet“ wird.

Szenario 2: eBGP zum Provider

Der Provider (z. B. AS 64496) stellt Internetzugang per BGP bereit, sendet eine Default-Route und kündigt den eigenen, vom Provider zugewiesenen Adressbereich an. Wichtig ist, dass keine internen Netze an den Provider gelangen und nur erwartete Routen angenommen werden. Werte immer mit dem Provider abstimmen – eine fehlerhafte Konfiguration kann zur Abschaltung der Session führen.

Prefix-Listen

Routing → BGP → Prefix Lists:

Name Seq Action Network
PL-IN-DEFAULT 10 permit 0.0.0.0/0
PL-OUT-OWN 10 permit eigener öffentlicher Bereich, z. B. 203.0.113.0/24

Alles, was nicht ausdrücklich erlaubt ist, wird durch eine Prefix-Liste implizit verworfen.

Route-Maps

Routing → BGP → Route Maps: z. B. RM-IN (Action permit, ID 10, Prefix List PL-IN-DEFAULT) und RM-OUT (permit, ID 10, Prefix List PL-OUT-OWN). Über das Feld Set lassen sich Attribute ändern, z. B. local-preference 200 für einen bevorzugten Weg oder as-path prepend 65011 65011, um eingehenden Verkehr auf eine andere Leitung zu lenken. AS Path Lists und Community Lists stehen als weitere Filterkriterien zur Verfügung.

Neighbor

  • Peer-IP = Adresse des Provider-Routers, Remote AS = 64496 (bzw. External)
  • Prefix-List In/Out oder Route-Map In/Out wie oben
  • BGP MD5 Password nach Vorgabe des Providers – dann ist auch Local Initiater IP Pflicht
  • optional BFD (siehe OPNsense - BFD mit FRR), Soft reconfiguration inbound (Filteränderungen ohne Session-Reset)
  • Enforce First AS (erweitert, in General) lehnt Updates ab, in deren AS-Pfad nicht das AS des Nachbarn an erster Stelle steht.

Szenario 3: BGP über VPN-Tunnel und zur Cloud

BGP spielt seine Stärken bei Standortvernetzung über Tunnel aus:

  • IPsec route-based (VTI): Neighbor = Tunneladresse der Gegenstelle; die statischen Routen entfallen – Details im Artikel OPNsense - IPsec Site-to-Site route-based. Azure VPN Gateway und AWS Site-to-Site-VPN unterstützen BGP über IPsec.
  • WireGuard: In der Instanz Disable routes aktivieren, damit WireGuard keine eigenen Routen setzt, und die Allowed IPs weit genug fassen (z. B. 0.0.0.0/0 bei einem Peer pro Instanz) – siehe OPNsense - WireGuard Site-to-Site und Road Warrior.
  • Mit zwei Tunneln über zwei Internetleitungen und je einer BGP-Session schwenkt der Verkehr bei Ausfall eines Tunnels automatisch um; mit BFD in unter einer Sekunde.
  • Bei vielen Filialen (Hub-and-Spoke) erleichtern Peer Groups mit gemeinsamen Einstellungen und Listen Ranges (Nachbarn aus einem Netzbereich automatisch akzeptieren) die Konfiguration; im iBGP mit vielen Standorten hilft ein Route Reflector (Option Route Reflector Client beim Nachbarn) statt vollvermaschter Sessions.

Weitere Optionen im Überblick

Option Zweck
Maximum Paths / Maximum Paths (IBGP) ECMP – Verkehr über mehrere gleichwertige Wege verteilen
Bestpath Pfadauswahl beeinflussen, z. B. as-path multipath-relax für ECMP über unterschiedliche AS
Graceful Restart Weiterleitung während eines Neustarts des BGP-Prozesses beibehalten
BGP AD Distance administrative Distanz anpassen, etwa um OSPF-Routen zu bevorzugen
Send Defaultroute Default-Route an den Nachbarn senden (z. B. an Filialen)
Next-Hop-Self eigene Adresse als Next-Hop eintragen (typisch im iBGP)
Multi-Hop / Disable Connected Check eBGP über mehrere Hops bzw. über Loopback-Adressen
Local AS, Allow AS In, AS-Override, Remove Private AS Sonderfälle bei Migrationen, Provider-Szenarien und Multi-Site-Netzen
Keepalive / Hold Down Time Standard 60 bzw. 180 Sekunden; für schnelleres Umschalten besser BFD verwenden

Hochverfügbarkeit

  • Enable CARP Failover unter Routing → General: Bei einem CARP-Ereignis startet das Plugin den FRR-Dienst auf dem neuen Master und stoppt ihn auf dem Backup – BGP läuft also nur auf dem Master. Der Provider bzw. die Gegenstelle verwendet die CARP-Adresse als Nachbar. Die Session zum Provider wird dabei neu aufgebaut, was je nach Timern einige Sekunden bis Minuten dauern kann.
  • Alternativ beide Firewalls mit eigenen Sessions zum Provider bzw. zu den Standorten betreiben und die Pfadwahl über Local Preference und AS-Path-Prepending steuern – dafür muss der Provider zwei Sessions unterstützen.
  • Konfiguration per System → High Availability (Dienst FRR, siehe Hochverfügbarkeit mit CARP und pfsync) synchronisieren und Router-IDs bzw. Update-Source je Firewall prüfen.
  • Die OSPF-spezifischen Optionen (CARP demote, Kosten abhängig von CARP) gibt es für BGP nicht. Details und eine Entscheidungshilfe: Hochverfügbarkeit im Überblicksartikel.

Sicherheitsempfehlungen

  • Immer filtern: eingehend nur erwartete Präfixe (z. B. Default-Route), ausgehend nur eigene Netze – nie interne RFC-1918-Netze zum Provider.
  • MD5-Passwort für Sessions über fremde Netze; Firewall-Regel für TCP 179 nur von der Nachbar-IP.
  • Enforce First AS für eBGP aktiv lassen.
  • Bei öffentlichen AS-Nummern Routing-Sicherheit (RPKI/ROA) mit dem Provider bzw. bei der RIPE NCC pflegen.
  • Nachbarschaftswechsel protokollieren (Log Neighbor Changes) und an ein Monitoring/SIEM übertragen.

Typische Probleme und Lösungen

Symptom Ursache und Lösung
Nachbar bleibt in Active/Connect TCP 179 durch Firewall-Regel blockiert, falsche Peer-IP/AS-Nummer, Update-Source falsch oder MD5-Passwort ungleich.
Session Established, aber keine Routen Prefix-Liste/Route-Map verwirft alles (implizites Deny), Network Import-Check (Netz nicht in der Routing-Tabelle) oder Nachbar sendet nichts.
Netz wird nicht angekündigt Netz nicht exakt in der Routing-Tabelle vorhanden, Ausgangsfilter fehlt bzw. ist zu streng.
Routen gelernt, Verkehr fließt nicht Firewall-Regeln für den Nutzverkehr fehlen, Next-Hop nicht erreichbar (Next-Hop-Self im iBGP).
eBGP über Loopback kommt nicht hoch Multi-Hop bzw. Disable Connected Check und Update-Source fehlen, Route zur Loopback-Adresse fehlt.
Umschalten dauert Minuten Standard-Timer (Hold 180 s) – BFD aktivieren.

Fazit

Mit BGP auf der OPNsense lassen sich Provider-Anbindungen, Cloud-Netze und viele Standorte sauber und automatisch routen. Entscheidend sind eindeutige AS-Nummern und Router-IDs, konsequente Filter mit Prefix-Listen und Route-Maps sowie die Firewall-Regel für TCP 179. In Kombination mit route-based IPsec, WireGuard und BFD entstehen ausfallsichere Standortnetze, die bei Leitungsstörungen in Sekunden umschalten.

Unterstützung von m.a.x. it

Sie möchten Ihre Standorte per BGP vernetzen, eine Anbindung an Azure oder AWS aufbauen oder Ihren eigenen Adressraum bei mehreren Providern ankündigen? 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_-_BGP_mit_FRR&oldid=3893“