imported>TechCorner-Redaktion: Verlinkung auf OPNsense - NetFlow und Insight ergänzt

2026-10-09T00:00:00Z

Verlinkung auf OPNsense - NetFlow und Insight ergänzt

Neue Seite

{{Steckbrief
| gilt_fuer = OPNsense 26.1 und 26.7 (Firewall → Shaper, im Kern enthalten)
| bereich = IT-Security
| dauer = ca. 30 Minuten (FQ_CoDel gegen Bufferbloat), je weiteres Szenario ca. 15 Minuten
| rechte = Administrator (OPNsense-WebUI)
| stand = Oktober 2026 (OPNsense 26.7.5)
}}
Der '''Traffic Shaper in OPNsense''' steuert, wie die verfügbare [[Bandbreite]] einer Internetleitung genutzt wird: Er '''begrenzt''' die Bandbreite für Benutzer, Netze oder Anwendungen, '''verteilt''' sie gerecht auf alle Clients, '''gewichtet''' wichtige Dienste stärker und senkt mit '''FQ_CoDel''' die [[Latenz]] unter Last („Bufferbloat“). Damit bleiben [[VoIP]]-Telefonate und Videokonferenzen auch dann flüssig, wenn im Hintergrund große Downloads oder Backups laufen – ein zentraler Baustein für [[Quality of Service|QoS]] am Internetanschluss.

Dieser Artikel erklärt Aufbau und Bedienung des Shapers in OPNsense 26.7 (Pipes, Queues, Regeln) und zeigt die wichtigsten Szenarien aus der Praxis: FQ_CoDel gegen Bufferbloat, Bandbreitenbegrenzung pro Benutzer, gerechte Verteilung, Gewichtung über Queues, Gästenetz und Control-Plane-Schutz.

== Aufbau: Pipes, Queues und Regeln ==
Der Shaper basiert auf '''IPFW und dummynet''' aus FreeBSD und arbeitet unabhängig von den Firewall-Regeln. Er besteht aus drei Bausteinen unter '''Firewall → Shaper''':
{| class="wikitable"
! Baustein !! Aufgabe !! Wichtige Einstellungen
|-
| '''Pipe''' || Emuliert eine Leitung mit fester Bandbreite – setzt die '''harte Obergrenze''' || Bandwidth + Metric, Mask (dynamische Pipes je Quelle/Ziel), Scheduler (z. B. FQ_CoDel), Delay
|-
| '''Queue''' || Teilt die Bandbreite einer Pipe '''gewichtet''' auf (WF2Q+) || Pipe, Weight (1–100), Mask
|-
| '''Rule''' || Ordnet Verkehr einer Pipe oder Queue zu || Interface, Protokoll, Quelle/Ziel/Ports, DSCP, Direction, Target
|}
'''Wichtig:''' Gewichte sind keine strikten Prioritäten. Eine Queue mit niedrigem Gewicht erhält auch bei voller Auslastung immer ihren Anteil – Gewichte wirken erst, wenn die Pipe ausgelastet ist.

Die '''Mask''' erzeugt dynamisch Pipes bzw. Queues: ''source'' erzeugt einen eigenen Anteil je Quell-Adresse (für den Upload), ''destination'' je Ziel-Adresse (für den Download). So lässt sich mit einer einzigen Pipe jedem Client ein eigenes Limit geben.

[[Datei:OPNsense-Traffic-Shaper.png|thumb|center|750px|Traffic Shaper auf der OPNsense: Regeln ordnen Verkehr am WAN Pipes und Queues zu; die Download-Pipe mit FQ_CoDel (85 % der Leitung) verhindert Bufferbloat, Queues gewichten Anwendungen, Masken begrenzen die Bandbreite pro Client.]]

=== Scheduler ===
{| class="wikitable"
! Scheduler !! Eigenschaft !! Einsatz
|-
| Weighted Fair Queueing (Standard) || Gewichte der Queues werden berücksichtigt || Priorisierung über Queues
|-
| '''FlowQueue-CoDel''' (FQ_CoDel) || jeder Datenstrom in eigener Warteschlange, aktive Verzögerungskontrolle (RFC 8290) || '''gegen Bufferbloat''' – Empfehlung für den Internetanschluss
|-
| FlowQueue-PIE (FQ_PIE) || ähnlicher AQM-Ansatz mit PIE || Alternative zu FQ_CoDel
|-
| QFQ || gewichtete Verteilung mit geringem Aufwand || viele Queues
|-
| Deficit Round Robin, FIFO || einfache Verfahren || Sonderfälle
|}

{{Hinweis|Laut OPNsense-Dokumentation sollte auf '''virtuellen Maschinen''' der Tunable <code>kern.hz</code> mindestens auf <code>1000</code> stehen (''System → Settings → Tunables''); ein höherer Wert verbessert die Reaktionsfähigkeit des Shapers.}}

== Szenario 1: FQ_CoDel gegen Bufferbloat ==
'''Bufferbloat''' entsteht, wenn Router oder Modem bei voller Leitung zu viele Pakete puffern: Neue Pakete warten hinter großen Downloads, Ping und [[Jitter]] steigen, Telefonate stocken. FQ_CoDel löst das, indem die Firewall selbst knapp unterhalb der Leitungsgeschwindigkeit begrenzt und Datenströme fair abwechselnd sendet. Beispiel für eine Leitung mit 530/30 Mbit/s:

=== Pipes ===
'''Firewall → Shaper → Pipes''' (erweiterter Modus), je eine Pipe für Download und Upload:
{| class="wikitable"
! Feld !! Download !! Upload
|-
| Bandwidth / Metric || <code>450</code> Mbit/s (ca. 85 % der Nennrate) || <code>25</code> Mbit/s
|-
| Scheduler type || FlowQueue-CoDel || FlowQueue-CoDel
|-
| (FQ-)CoDel ECN || aktiv || aktiv
|-
| Mask, Enable CoDel, übrige Felder || leer bzw. Standard || leer bzw. Standard
|-
| Description || ''Download'' || ''Upload''
|}

=== Queues ===
Je eine Queue pro Pipe (''Download-Queue'', ''Upload-Queue''), Weight <code>100</code>, Mask leer – FQ_CoDel übernimmt die Fairness, CoDel-Felder der Queue leer lassen.

=== Regeln ===
'''Firewall → Shaper → Rules''':
{| class="wikitable"
! Feld !! Download-Regel !! Upload-Regel
|-
| Sequence || 1 || 2
|-
| Interface || WAN || WAN
|-
| Proto / Source / Destination || ip / any / any || ip / any / any
|-
| '''Direction''' (erweitert) || ''in'' || ''out''
|-
| Target || Download-Queue || Upload-Queue
|}
'''Apply''' – fertig.

=== Abstimmen ===
# Vor der Aktivierung mehrere Bufferbloat-Tests messen (z. B. Waveform Bufferbloat Test, Cloudflare Speed Test) und Durchsatz sowie Latenz unter Last notieren. Welche Dienste und Clients die Leitung belasten, zeigt vorab [[OPNsense - NetFlow und Insight|Reporting → Insight]].
# Mit 85 % der Nennrate starten, dann die Bandbreite schrittweise erhöhen, solange die Latenz unter Last niedrig bleibt; steigt sie, wieder etwas reduzieren. Für Upload genauso.
# Die übrigen Parameter sind für „no knobs“ ausgelegt; Standardwerte: quantum 1514, target 5 ms, interval 100 ms, limit 10240, flows 1024. Laut Dokumentation sollte '''quantum''' der WAN-MTU entsprechen (bei niedrigen Raten unter 100 Mbit/s ggf. 300), und '''limit''' darf für Anschlüsse unter 10 Gbit/s auf etwa 1000 gesenkt werden – seit OPNsense 25.7.8 ist das gefahrlos möglich, da ein FreeBSD-Fehler mit übermäßigem Logging behoben wurde.

== Szenario 2: Bandbreite pro Benutzer begrenzen ==
Jeder Client im LAN soll höchstens 10 Mbit/s erhalten:
* Pipe ''PipeDown-10'' mit 10 Mbit/s und '''Mask destination''' (je Download-Client eine eigene Pipe)
* Pipe ''PipeUp-10'' mit 10 Mbit/s und '''Mask source'''
* Regel Download: Interface WAN, Destination <code>192.168.1.0/24</code>, Target ''PipeDown-10''
* Regel Upload: Interface WAN, Source <code>192.168.1.0/24</code>, Target ''PipeUp-10''
Download und Upload '''immer in getrennten Pipes''' begrenzen – gemischter Verkehr in einer Pipe führt zu undefiniertem Verhalten.

== Szenario 3: Bandbreite gerecht verteilen ==
Alle Clients sollen sich die Leitung gleichmäßig teilen, egal wie viele Verbindungen sie öffnen:
* Pipes mit der Gesamtbandbreite (Download/Upload), Mask leer
* Queues mit Weight 100 und '''Mask destination''' (Download) bzw. '''source''' (Upload)
* Regeln am WAN für das LAN-Netz mit den Queues als Target
Wer nur wenige Geräte hat, kommt oft schon mit FQ_CoDel aus, das Datenströme ebenfalls fair behandelt.

== Szenario 4: Anwendungen gewichten ==
In einer Pipe mit 10 Mbit/s soll E-Mail (SMTP) bei Vollauslastung neunmal so viel Bandbreite erhalten wie Web-Verkehr:
* Queue ''Queue-SMTP'' mit Weight 9, Queue ''Queue-HTTP'' mit Weight 1 – beide an derselben Pipe
* Regeln am WAN: Source-Port ''smtp'' → Queue-SMTP, Source-Ports ''http'' und ''https'' → Queue-HTTP
Für '''VoIP''' und Videokonferenzen lässt sich auf dieselbe Weise eine Queue mit hohem Gewicht anlegen und per Port, Ziel (z. B. Adressen des Telefonanbieters) oder '''DSCP'''-Markierung (z. B. EF für Sprache) zuordnen.

== Szenario 5: Gästenetz und Captive Portal ==
Für ein [[OPNsense - Captive Portal für Gäste-WLAN|Gäste-WLAN]] wird die Gesamtbandbreite des Gästenetzes begrenzt (eigene Pipe für das Gästenetz) und zusätzlich pro Gast eine Obergrenze gesetzt (Mask). Die Regeln beziehen sich auf das Interface des Gästenetzes bzw. dessen Netz als Quelle/Ziel. So kann das Gästenetz die Leitung des Unternehmens nicht auslasten.

== Szenario 6: Control Plane schützen ==
Laufen dynamische Routingprotokolle (z. B. [[OPNsense - BGP mit FRR|BGP]] oder OSPF), IPv6 oder BFD über die Leitung, sollte deren Verkehr nicht in derselben Pipe wie Nutzverkehr stecken. Die OPNsense-Dokumentation empfiehlt, rund '''1 % der Bandbreite''' (mindestens 1 Mbit/s) als eigene Pipe für die '''Control Plane''' zu reservieren – mit einem gewichtenden Scheduler (WFQ oder QFQ), nicht mit FQ_CoDel – und diese Bandbreite von den übrigen Pipes abzuziehen.

== Shaping direkt in Firewall-Regeln ==
Statt eigener Shaper-Regeln lässt sich eine Pipe oder Queue auch direkt in einer Firewall-Regel zuweisen: Unter [[OPNsense - Firewall-Regeln|''Firewall → Rules'']] gibt es die Felder '''Traffic shaper''' (Regelrichtung) und '''Traffic shaper [reverse]''' (Gegenrichtung). Das ist praktisch, wenn die Zuordnung ohnehin an einer bestimmten Firewall-Regel hängt, z. B. für ein einzelnes Netz oder einen Dienst.

== Status und Fehlersuche ==
'''Firewall → Shaper → Status''' zeigt Pipes, Queues und – mit ''Show rules'' – die Regeln mit Paket- und Bytezählern seit dem letzten Start; ''Show active flows'' listet die aktiven Datenströme. Aussagekräftige Beschreibungen erleichtern die Zuordnung.
{| class="wikitable"
! Symptom !! Ursache und Lösung
|-
| Shaper wirkt nicht || Regel trifft nicht (Zähler bei 0) – Interface, Richtung, Quelle/Ziel prüfen; ''Apply'' vergessen; Pipe deaktiviert.
|-
| Download wird nicht begrenzt || Regel am falschen Interface oder falsche Richtung – Download am WAN ist ''in'' bzw. Ziel = LAN-Netz.
|-
| Weiterhin hohe Latenz unter Last || Bandbreite der Pipe zu hoch (über der realen Leitungsgeschwindigkeit) – schrittweise senken; Scheduler FQ_CoDel prüfen.
|-
| Durchsatz deutlich zu niedrig || Bandbreite zu niedrig angesetzt, CPU-Last bei sehr hohen Raten, auf VMs <code>kern.hz</code> zu niedrig.
|-
| Gewichte zeigen keine Wirkung || Pipe nicht ausgelastet (Gewichte greifen nur bei Vollast) oder Queues hängen an verschiedenen Pipes.
|-
| Routing-Sessions brechen bei Vollast ab || Control-Plane-Verkehr in der Nutzverkehrs-Pipe – eigene Control-Plane-Pipe einrichten.
|}

== Grenzen und Empfehlungen ==
* Der Shaper kann nur steuern, was durch die Firewall fließt; der Download lässt sich nur indirekt beeinflussen (Pakete sind bereits über die Leitung gekommen) – deshalb knapp unter der realen Bandbreite begrenzen.
* Bei Leitungen mit stark schwankender Bandbreite (Mobilfunk, Kabel zu Spitzenzeiten) ist eine feste Pipe-Bandbreite ein Kompromiss. Bei [[OPNsense - Gateways und Multi-WAN|mehreren WAN-Leitungen]] für jede Leitung eigene Pipes und Regeln anlegen.
* Laut OPNsense-Dokumentation ist der Shaper '''nicht mit einer [[OPNsense - Bridge und transparente Firewall|Bridge]]''' kompatibel.
* Für anwendungsbasierte Regeln (z. B. nach Anwendungskategorie statt Port) eignet sich eine Next-Generation-Firewall wie [[OPNsense - Zenarmor Next-Generation-Firewall|Zenarmor]].
* Einstellungen im HA-Cluster per Konfigurationssynchronisation übertragen (siehe [[OPNsense - Hochverfügbarkeit mit CARP und pfsync]]).

== Fazit ==
Der Traffic Shaper der OPNsense löst mit wenigen Einstellungen typische Probleme am Internetanschluss: FQ_CoDel beseitigt Bufferbloat und hält Latenz und Jitter für Telefonie und Videokonferenzen niedrig, Masken begrenzen oder verteilen die Bandbreite pro Client, und Queues gewichten wichtige Anwendungen. Entscheidend sind getrennte Pipes für Download und Upload, eine Bandbreite knapp unter der realen Leitungsgeschwindigkeit und Regeln, die am richtigen Interface in der richtigen Richtung greifen.

== Unterstützung von m.a.x. it ==
Sie möchten Telefonie und Videokonferenzen am Internetanschluss absichern oder die Bandbreite für Standorte und Gäste fair verteilen? 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 - NetFlow und Insight]]
* [[OPNsense - Firewall-Regeln]]
* [[OPNsense - Gateways und Multi-WAN]]
* [[OPNsense - Bridge und transparente Firewall]]
* [[OPNsense - VLAN und Netzwerksegmentierung]]
* [[QoS]]
* [[Quality of Service]]
* [[Bandbreite]]
* [[Latenz]]
* [[Jitter]]
* [[VoIP]]
* [[OPNsense - Captive Portal für Gäste-WLAN]]
* [[OPNsense - Zenarmor Next-Generation-Firewall]]
* [[OPNsense - FRR Dynamisches Routing]]

== Links und Quellen ==
* [https://docs.opnsense.org/manual/shaping.html OPNsense-Doku – Traffic Shaping]
* [https://docs.opnsense.org/manual/how-tos/shaper_bufferbloat.html OPNsense-Doku – Fighting Bufferbloat with FQ_CoDel]
* [https://docs.opnsense.org/manual/how-tos/shaper_control_plane.html OPNsense-Doku – Control Plane Shaping]
* [https://datatracker.ietf.org/doc/html/rfc8290 RFC 8290 – FQ-CoDel]
* [https://www.max-it.de/it-services/opnsense/ m.a.x. it – OPNsense-Firewall-Services]

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

OPNsense - Traffic Shaper und QoS - Versionsgeschichte

imported>TechCorner-Redaktion: Verlinkung auf OPNsense - NetFlow und Insight ergänzt