OPNsense - Traffic Shaper und QoS

Aus maxTechCorner
(Weitergeleitet von OPNsense Bufferbloat)

Auf einen Blick

Gilt fürOPNsense 26.1 und 26.7 (Firewall → Shaper, im Kern enthalten)
BereichIT-Security
Dauerca. 30 Minuten (FQ_CoDel gegen Bufferbloat), je weiteres Szenario ca. 15 Minuten
RechteAdministrator (OPNsense-WebUI)
StandOktober 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 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:

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.

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

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


HinweisLaut OPNsense-Dokumentation sollte auf virtuellen Maschinen der Tunable kern.hz mindestens auf 1000 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:

Feld Download Upload
Bandwidth / Metric 450 Mbit/s (ca. 85 % der Nennrate) 25 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 100, Mask leer – FQ_CoDel übernimmt die Fairness, CoDel-Felder der Queue leer lassen.

Regeln

Firewall → Shaper → Rules:

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

  1. 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 Reporting → Insight.
  2. 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.
  3. 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 192.168.1.0/24, Target PipeDown-10
  • Regel Upload: Interface WAN, Source 192.168.1.0/24, 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 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. 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 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.

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 kern.hz 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 mehreren WAN-Leitungen für jede Leitung eigene Pipes und Regeln anlegen.
  • Laut OPNsense-Dokumentation ist der Shaper nicht mit einer Bridge kompatibel.
  • Für anwendungsbasierte Regeln (z. B. nach Anwendungskategorie statt Port) eignet sich eine Next-Generation-Firewall wie 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 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_-_Traffic_Shaper_und_QoS&oldid=4196“