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), BGPv4 für IPv4 und IPv6
| bereich = IT-Security
| dauer = ca. 30 Minuten (iBGP zwischen zwei Standorten), ca. 45 Minuten (eBGP zum Provider mit Filtern)
| rechte = Administrator (OPNsense-WebUI); bei eBGP Absprache mit dem Provider
| stand = Oktober 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 [[Autonomes System|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 ==
{| class="wikitable"
! 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)
|}

[[Datei:OPNsense-BGP-FRR.png|thumb|center|750px|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 ==
# ''os-frr'' installieren und unter '''Routing → General''' aktivieren (siehe [[OPNsense - FRR Dynamisches Routing]]), Tunable <code>kern.ipc.maxsockbuf</code> = <code>33554432</code> setzen.
# '''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'').
# 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):
{| 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> || <code>10.1.1.2</code>
|-
| AS-Nummer || colspan="2" | <code>65011</code> (privat, beide gleich = iBGP)
|}
'''Routing → BGP → General''' (beide Seiten):
* '''enable''', '''BGP AS Number''' <code>65011</code>, optional '''Router ID'''
* '''Network''': das eigene LAN (z. B. <code>192.168.1.0/24</code>) – 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''' <code>10.1.1.2</code> (auf Router B: <code>10.1.1.1</code>)
* '''Remote AS mode''' ''Use Remote AS Number'', '''Remote AS''' <code>65011</code> – 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.

{{Hinweis|'''Network 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''':
{| class="wikitable"
! Name !! Seq !! Action !! Network
|-
| <code>PL-IN-DEFAULT</code> || 10 || permit || <code>0.0.0.0/0</code>
|-
| <code>PL-OUT-OWN</code> || 10 || permit || eigener öffentlicher Bereich, z. B. <code>203.0.113.0/24</code>
|}
Alles, was nicht ausdrücklich erlaubt ist, wird durch eine Prefix-Liste implizit verworfen.

=== Route-Maps ===
'''Routing → BGP → Route Maps''': z. B. <code>RM-IN</code> (Action ''permit'', ID 10, Prefix List ''PL-IN-DEFAULT'') und <code>RM-OUT</code> (permit, ID 10, Prefix List ''PL-OUT-OWN''). Über das Feld '''Set''' lassen sich Attribute ändern, z. B. <code>local-preference 200</code> für einen bevorzugten Weg oder <code>as-path prepend 65011 65011</code>, 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''' = <code>64496</code> (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. <code>0.0.0.0/0</code> 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 ==
{| class="wikitable"
! 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 [[OPNsense - Hochverfügbarkeit mit CARP und pfsync|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: [[OPNsense - FRR Dynamisches Routing#Hochverfügbarkeit: FRR im CARP-Cluster|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 ==
{| class="wikitable"
! 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 [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 - OSPF und OSPFv3 mit FRR]]
* [[OPNsense - BFD mit FRR]]
* [[BGP]]
* [[Autonomes System]]
* [[BGP EVPN]]
* [[OPNsense - IPsec Site-to-Site route-based]]
* [[OPNsense - WireGuard Site-to-Site und Road Warrior]]

== 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_bgp.html OPNsense-Doku – BGP Tutorials (iBGP, eBGP)]
* [https://docs.frrouting.org/en/latest/bgp.html FRRouting-Dokumentation – BGP]
* [https://www.max-it.de/it-services/opnsense/ m.a.x. it – OPNsense-Firewall-Services]

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

OPNsense - BGP mit FRR - Versionsgeschichte

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