Application Traffic Shaping auf Sophos Firewall konfigurieren

Mit Application Traffic Shaping priorisiert oder begrenzt die Sophos Firewall einzelne Anwendungen wie Microsoft Teams, VoIP, OneDrive oder Backup-Dienste. Der vollständige anwendungsbasierte Ablauf ist:

1. Unter System services > Traffic shaping eine Policy mit Policy association > Applications erstellen.
2. Unter Applications > Application filter die gewünschte Anwendung erkennen lassen.
3. Unter Applications > Traffic shaping default die Policy der Anwendung oder Kategorie zuweisen.
4. Unter Rules and policies > Firewall rules den Application Filter auswählen und Apply application-based traffic shaping policy aktivieren.

Eine Policy mit Policy association > Rules im Feld Shape traffic ist eine andere Variante: Sie formt den gesamten Traffic der passenden Firewall-Regel, nicht nur die im Application Filter ausgewählte Anwendung.

⚠️ Traffic Shaping erzeugt keine zusätzliche Bandbreite. Es verteilt einen Engpass kontrollierter. Ist die Leitung dauerhaft ausgelastet, müssen trotzdem Kapazität, Backups, Cloud-Synchronisationen und andere Verursacher geprüft werden.

Traffic Shaping begrenzt eine Datenrate, nicht die insgesamt übertragene Datenmenge. Für konsumierbare Zeit- oder Datenkontingente verwendet man stattdessen Surfing Quota und Network Traffic Quota.

Voraussetzungen und Bandbreite planen

Vor der Konfiguration sollte man Folgendes klären:

• Für anwendungsbasiertes Shaping ist Application Control erforderlich. Es gehört zu Web Protection und ist auch im Bundle Standard Protection enthalten. Den Status sieht man unter System > Administration > Licensing. Eine reine Rules-Policy benötigt dagegen keine Anwendungserkennung.
• Die betroffene Anwendung wird von der Firewall erkannt und der Traffic läuft über eine bekannte Firewall-Regel.
• Logging ist für diese Regel aktiviert.
• Es ist klar, ob Upload, Download oder beide Richtungen knapp sind und welches WAN-Gateway beziehungsweise welcher SD-WAN-Pfad verwendet wird.
• Die gewünschte Wirkung ist definiert: Guarantee reserviert eine Mindestbandbreite und erlaubt Traffic bis zum Limit; Limit setzt nur eine Obergrenze.

Sophos zeigt Shaping-Werte in KBps, Speedtests meistens in kbps oder Mbit/s. 1 KBps entspricht 8 kbps. 100 Mbit/s sind daher ungefähr 12'500 KBps, 20 Mbit/s ungefähr 2'500 KBps.

Massgebend sind stabile Messwerte, nicht die Providerangabe. Liefert ein Anschluss mit nominell 100/20 Mbit/s zuverlässig nur 80/15 Mbit/s, sollte man mit rund 10'000/1'875 KBps planen. Zu hohe Werte liegen ausserhalb des realen Engpasses und können ihn deshalb nicht sauber steuern.

Bei asymmetrischen Anschlüssen sollte man Limit upload/download separately aktivieren. Gerade Teams, VoIP, VPN und Cloud-Backups leiden häufig zuerst unter einem vollen Upload. Die globalen Werte unter System services > Traffic shaping settings gelten nur für weitergeleiteten ausgehenden Traffic zur WAN-Zone. Einzelne Traffic-Shaping-Policies können dagegen auf eingehenden und ausgehenden weitergeleiteten Traffic angewendet werden. QoS gilt ausserdem nicht für systemgenerierten Firewall-Traffic wie Pattern-Updates oder Lizenzsynchronisationen.

Anwendungsbasiertes Traffic Shaping konfigurieren

Das folgende Beispiel priorisiert bis zu vier gleichzeitig aktive Teams-Video-Meetings an einem kleinen Standort mit stabil etwa 80/15 Mbit/s. Microsoft nennt im Bandbreitenbedarf für Teams pro Endpunkt für ein Video-Meeting ungefähr 2'500 kbps Upload und 4'000 kbps Download als empfohlenen Bedarf. Die Beispielwerte reservieren diesen gemeinsamen Bedarf, müssen aber mit den eigenen Messungen und der tatsächlichen Zahl gleichzeitiger Meetings abgeglichen werden.

Traffic-Shaping-Policy erstellen

Unter System services > Traffic shaping erstellt man eine neue Policy, zum Beispiel mit diesen Werten:

• Name: Teams Guarantee
• Policy association: Applications
• Rule type: Guarantee
• Limit upload/download separately: Enable
• Priority: 1 (höchste Priorität)
• Upload Guarantee / Limit: 1'250 / 1'500 KBps
• Download Guarantee / Limit: 2'000 / 5'000 KBps
• Bandwidth usage type: Shared

1'250 KBps entsprechen 10 Mbit/s, 2'000 KBps entsprechen 16 Mbit/s. Mit Shared teilen alle Anwendungen oder Kategorien, denen diese Policy zugewiesen wird, den gemeinsamen Pool. Individual stellt den Wert pro zugewiesenem Objekt bereit. Hohe Garantiewerte sollte man nicht auf viele Policies verteilen, weil ihre Summe zur real verfügbaren Bandbreite passen muss.

Traffic-Shaping-Policies lassen sich nach dem Erstellen nicht bearbeiten. Benötigt man später andere Werte, dokumentiert man zuerst alle Zuweisungen, erstellt eine Ersatz-Policy mit neuem Namen und stellt zunächst einen begrenzten Scope um. Nach der Prüfung folgen die übrigen Zuweisungen; die alte Policy wird erst entfernt, wenn keine Referenz mehr darauf zeigt. Beim Rollback weist man wieder die alte Policy oder None zu.

Application Filter erstellen

Unter Applications > Application filter erstellt man einen Filter, der nur den gewünschten Traffic enthält:

1. Einen Namen wie Microsoft Teams vergeben.
2. Eine Application-Regel hinzufügen.
3. Im Smart Filter nach microsoft teams suchen.
4. Die passenden Teams-Anwendungen auswählen und mit Allow speichern.

Microsoft 365 sollte man nicht pauschal als eine einzige Anwendung behandeln. Teams, Exchange, SharePoint und OneDrive erzeugen unterschiedlichen Traffic und sollten zunächst getrennt beobachtet werden. Wenn es um Erkennung und Blockierung statt um Bandbreite geht, hilft Sophos Firewall Application Control einrichten und testen.

Policy der Anwendung zuweisen

Unter Applications > Traffic shaping default sucht man Microsoft Teams oder die passende Anwendungskategorie, öffnet den Eintrag und wählt Teams Guarantee aus.

Eine Policy auf einer einzelnen Anwendung hat Vorrang vor einer Policy auf ihrer Kategorie. Wenn mehrere Shaping-Ebenen gleichzeitig passen, verwendet Sophos diese Reihenfolge: Anwendung, Anwendungskategorie, Webkategorie, Benutzer, Gruppe und zuletzt Firewall-Regel.

Firewall-Regel aktivieren

Unter Rules and policies > Firewall rules öffnet man die Regel, über die der Teams-Traffic tatsächlich läuft. Im Bereich Other security features:

1. Bei Identify and control applications (App control) den Filter Microsoft Teams auswählen.
2. Apply application-based traffic shaping policy aktivieren.
3. Regel speichern und Traffic erzeugen.

Die Applications-Policy wird nicht im Feld Shape traffic ausgewählt, sondern stammt aus Traffic shaping default. Passen mehrere Shaping-Ebenen gleichzeitig, gilt die dokumentierte Reihenfolge: Anwendung, Anwendungskategorie, Webkategorie, Benutzer, Gruppe und zuletzt Firewall-Regel. Die Rules-Policy im Feld Shape traffic hat damit die niedrigste Priorität. Mehrere Ebenen sollten nur bewusst kombiniert und mit echtem Traffic geprüft werden.

Die Regelreihenfolge bleibt entscheidend: Trifft der Traffic bereits eine allgemeinere Regel weiter oben, werden weder der Filter noch das Shaping der späteren Regel angewendet.

Rule-based Traffic Shaping für eine ganze Regel

Soll der gesamte Traffic einer klar abgegrenzten Firewall-Regel dieselben Werte erhalten, ist eine Rules-Policy einfacher:

1. Unter System services > Traffic shaping eine Policy mit Policy association > Rules erstellen.
2. Unter Rules and policies > Firewall rules die betroffene Regel öffnen.
3. Unter Shape traffic die Rules-Policy auswählen.
4. Apply application-based traffic shaping policy nicht aktivieren, sofern keine zusätzlichen Applications-Policies verwendet werden.

Ein Application Filter schränkt eine Rules-Policy nicht automatisch auf diese Anwendung ein. Dafür muss entweder die Firewall-Regel selbst über Quelle, Ziel und Services eng begrenzt sein oder man verwendet den anwendungsbasierten Ablauf. DSCP marking ist ebenfalls kein Ersatz für Shaping: DSCP markiert Pakete für nachgelagerte Geräte, während die Shaping-Policy auf der Firewall Bandbreite garantiert oder begrenzt.

Wirkung prüfen und Policy sicher anpassen

Nach der Änderung sollte man nicht nur einen Speedtest ausführen, sondern kontrollieren:

• Trifft der Traffic die erwartete Firewall-Regel?
• Zeigen Application-Control-Logs die erwartete Anwendung beziehungsweise Application ID?
• Bestätigen Reports wie Top Applications und die Regelzähler die erwartete Zuordnung?
• Ist die betroffene Richtung während des Tests tatsächlich ausgelastet?
• Verändern sich Bandbreite, Latenz, Paketverlust oder die Gesprächsqualität wie erwartet?
• Läuft der Test über dasselbe WAN-Gateway und denselben SD-WAN-Pfad wie der produktive Traffic?
• Bestätigen Benutzer von Echtzeitdiensten die technische Messung auch in der Praxis?

Für einen belastbaren Vorher-Nachher-Vergleich verwendet man dieselbe Quelle, dasselbe Ziel, dieselbe Richtung und möglichst denselben Zeitraum. Die Anleitung Sophos Firewall Performance mit iPerf und Speedtest prüfen zeigt geeignete Messmethoden. Bei mehreren Leitungen hilft zusätzlich Sophos Firewall SD-WAN Routing für Reply Packets und System Traffic prüfen.

Zum Nachjustieren erstellt man wegen der nicht editierbaren Policy eine neue Version mit konservativ geänderten Werten. Diese weist man zuerst einer eingegrenzten Anwendung, Kategorie oder Regel zu, beobachtet Logs und Benutzerfeedback und entfernt die alte Policy erst nach erfolgreicher Kontrolle. Zweck, betroffene Regel, Werte, Verantwortlicher und Review-Termin sollten dokumentiert sein.

Wenn Traffic Shaping nicht wie erwartet wirkt

Anwendung wird nicht erkannt

Man prüft zuerst, ob der richtige Application Filter in der tatsächlich getroffenen Firewall-Regel ausgewählt ist. Breite oder verschlüsselte Cloud-Dienste sollten im Application-Control-Log anhand der erkannten Application ID kontrolliert werden.

Shaping zeigt keinen Unterschied

Ist die Leitung während des Tests nicht ausgelastet, gibt es keinen sichtbaren Engpass zu steuern. Weitere häufige Ursachen sind Werte oberhalb der realen Bandbreite, die falsche Richtung, eine allgemeinere Firewall-Regel weiter oben oder ein anderer SD-WAN-Pfad.

Bei application-based Shaping müssen zusätzlich alle drei Zuordnungen stimmen: eine Policy mit Applications, die Zuweisung unter Traffic shaping default und die aktivierte Option in der Firewall-Regel. Der Haken allein weist noch keine Bandbreite zu.

Application Traffic stoppt zeitweise

SFOS 22.0 MR2 Build 546 behebt mit NC-178197 einen Fehler, durch den Application Traffic bei einer application-based bandwidth policy intermittierend stoppen konnte. Tritt dieses Symptom unter SFOS 22.0 GA oder MR1 auf, sollte man vor einem Umbau der Policies den Firmwarestand prüfen und auf MR2 oder eine neuere freigegebene Version aktualisieren.

Microsoft 365 oder Gastnetz bleiben problematisch

Microsoft 365 sollte man nach Teams, Exchange, SharePoint und OneDrive getrennt untersuchen, statt die ganze Kategorie blind zu garantieren oder zu begrenzen. Beim Gastnetz prüft man, ob dessen Traffic wirklich die vorgesehene Regel trifft und ob nicht nur der Download, sondern auch der Upload begrenzt ist.