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.

Globalen Default und einzelne Policies auseinanderhalten

Unter System services > Traffic shaping settings legt Total available WAN bandwidth den gemeinsamen QoS-Rahmen aller WAN-Leitungen fest. Eingetragen wird die Summe der stabil nutzbaren Bandbreite, in KBps, nicht nur der Vertragswert einer einzelnen Leitung. Show bandwidth usage zeigt, wie dieser Rahmen auf die Prioritäten verteilt ist. Diese globalen Werte greifen nur bei weitergeleitetem ausgehendem WAN-Traffic, der keine eigene Traffic-Shaping-Policy trifft.

Mit Optimize for real-time (VoIP) priorisiert SFOS Echtzeittraffic immer zuerst. Ist die Option aus, erhalten garantierende Policies zuerst ihre zugesagte Bandbreite und Echtzeittraffic wird aus dem Rest bedient. Enforce guaranteed bandwidth aktiviert für Traffic ohne eigene Policy die Werte Guarantee, Limit und Priority von 1 bis 7 aus der Default Policy. Ist Enforce guaranteed bandwidth ausgeschaltet, erhält dieser Traffic keine garantierte Mindestbandbreite, sondern nur die noch verfügbare Kapazität. Bei Priority steht 1 für die höchste und 7 für die niedrigste Priorität.

Diese Schalter werden nicht als allgemeiner Performance-Fix aktiviert. Zuerst werden reale Bandbreite, bestehende Garantien und die gewünschte Priorität dokumentiert. Andernfalls konkurrieren zu hohe Zusagen um eine Kapazität, die physisch nicht vorhanden ist.

Anwendungsbasiertes Traffic Shaping konfigurieren

Das folgende Beispiel priorisiert den Traffic von bis zu vier gleichzeitig aktiven Teams-Videoendpunkten 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 gleichzeitig aktiver Endpunkte 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 reserviert den Wert dagegen nur für das Objekt, dem die Policy zuerst zugewiesen wird; eine Individual-Policy eignet sich deshalb nicht als wiederverwendbare Vorlage für mehrere Objekte. Hohe Garantiewerte sollte man nicht auf viele Policies verteilen, weil ihre Summe zur real verfügbaren Bandbreite passen muss. Im Beispiel entsprechen die Garantien dem empfohlenen Gesamtbedarf von vier Teams-Videoendpunkten. Falls Bandbreite verfügbar ist, dürfen sie diese bis zu den höheren Limits nutzen. Die Limits von 12/40 Mbit/s lassen auf der gemessenen 80/15-Mbit/s-Leitung bewusst Kapazität für anderen Traffic. Es sind Startwerte und keine allgemeingültigen Teams-Vorgaben.

Im hier beschriebenen UI-Ablauf lassen sich Traffic-Shaping-Policies nach dem Erstellen nicht bearbeiten. Diese UI-Einschränkung ist keine Aussage, dass die XML API keine Update-Operation dokumentiert. 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.

QoS-Policy: UI-Ablauf und XML-API-Vertrag unterscheiden

Die XML-API-Referenzen für SFOS 22.0 und 23.0 dokumentieren für QoSPolicy ausdrücklich Add QoS policy / Update QoS policy und beschreiben Add/Edit. Damit ist eine API-Operation dokumentiert, aber noch kein ausführbarer Update-Vertrag für den installierten Build bestätigt. Die folgenden Objektangaben sind keine vollständige Request-Vorlage. Der sichere UI-Ersatzablauf bleibt die Anleitung zum Nachjustieren. Zugriff, explizite Operation und Antwortprüfung erklärt XML API sicher verwenden und Antworten auswerten.

Die Bandbreitenfelder sind im Beispiel von PolicyType und ImplementationOn abhängig, nicht gleichzeitig für jede Policy erforderlich:

• Strict mit Total: TotalBandwidth.
• Committed mit Total: GuaranteedBandwidth und BurstableBandwidth.
• Strict mit Individual: UploadBandwidth und DownloadBandwidth.
• Committed mit Individual: GuaranteedUploadBandwidth, BurstableUploadBandwidth, GuaranteedDownloadBandwidth und BurstableDownloadBandwidth.

Im Beispiel muss die jeweilige Burstable-Bandbreite grösser als die zugehörige Garantie sein. Die Individual-Zweige nennen in ihren Kommentaren nur User, Firewall und Application; WebCategory erscheint bei Total, nicht bei Individual. Das ist keine Bestätigung einer Individual-WebCategory-Kombination und auch kein nachgewiesenes Laufzeitverbot. ImplementationOn mit Total/Individual ist zudem nicht dasselbe Feld wie BandwidthUsageType mit Individual/Shared; gleichlautende Tokens sind keine austauschbaren Einstellungen.

Beispiel und Parametertabelle stimmen nicht durchgehend überein: Das Beispiel nennt 2–2560000 KB, die Tabelle 2–10240000. Daraus folgt keine universelle Obergrenze für den Build. Für BandwidthUsageType zeigt das Beispiel Individual/Shared, die Tabelle dagegen Shared Bandwidth Usage Type mit on/off. PolicyBasedOn verwendet im Beispiel benannte Tokens, während Policy Based On in der Tabelle als Integer mit Default 0 beschrieben ist. Weder die Token-Umsetzung noch ein sicherer Auslassungs-Default werden hier daraus abgeleitet.

Auch Schedule-Details haben zwei nicht eindeutig zusammengeführte Darstellungen: Das Beispiel zeigt SchedulebasedPolicyRuleList mit Rule, DetailId, PolicyType, den bedingten Bandbreitenfeldern und Schedule; zusätzlich steht DetailId am Policy-Objekt. Die Tabelle nennt Implementation On als Array mit 6/7, Policy Type als Array mit 8/11, die Bandbreitenlisten bandwidthlist, grntdbandwidthlist, burstbandwidthlist, upbandwidthlist, downbandwidthlist, grntdupbandwidthlist, grntddownbandwidthlist sowie qosdetailnamelist und ScheduleDetail. Die numerischen Enums werden hier nicht auf benannte Tokens abgebildet; Reihenfolge, Detailidentität und Update-/Auslassungsverhalten werden nicht erraten.

Vor einer API-Änderung muss API help des installierten Builds diese offenen Limits, Feldnamen und Schedule-Strukturen klären. Solange der Vertrag unklar ist, keine Schreibanfrage aus dem Beispiel zusammensetzen. Vorzustand, Zuweisungen und Schedule-Details sichern; nach einer freigegebenen Änderung Objekt und Details getrennt zurücklesen und die Shaping-Wirkung im betroffenen Zeitfenster prüfen. Die Referenz führt für Add und Update jeweils XML-Status 200, 500 und 502 auf. Die Referenz verwendet die unaufgelösten Symbole Message.QOSAddSuccess, Message.QOSAddFail, Message.QOSEditSuccess, Message.QOSEditFail und Message.QOSRecordExist; die zugehörigen Meldungstexte sind nicht aufgelöst. Die Symbole sind keine aufgelösten Meldungstexte oder HTTP-Codes. Ein Status allein bestätigt weder alle Details noch die Wirkung. Bei Abweichungen Antwort und Ist-Zustand sichern und nicht blind wiederholen; nur die eigene Änderung auf den gesicherten Stand zurückführen.

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 die Aktion Allow verwenden.
5. Die Application-Regel mit Save speichern und anschliessend auch den Application Filter mit Save 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. Eine Kategorie wird direkt mit Edit geöffnet. Für eine einzelne Anwendung wird zuerst die Kategorie mit Expand aufgeklappt und danach bei der Anwendung Edit gewählt. Anschliessend wird Teams Guarantee ausgewählt und mit Save gespeichert.

Eine Policy auf einer einzelnen Anwendung hat Vorrang vor einer Policy auf ihrer Kategorie. Die allgemeine Shaping-Beschreibung nennt bei mehreren gleichzeitig passenden Ebenen die Reihenfolge Anwendung, Anwendungskategorie, Webkategorie, Benutzer, Gruppe und zuletzt Firewall-Regel. Bei einer zusätzlichen Rules-Policy bleibt die folgende Dokumentationsabweichung zu beachten.

Die Zuweisung unter Traffic shaping default aktiviert das anwendungsbasierte Shaping noch nicht; dazu ist zusätzlich Apply application-based traffic shaping policy in der tatsächlich getroffenen Firewall-Regel erforderlich. Bei einer gleichzeitig gesetzten Rules-Policy ist die Dokumentation jedoch nicht eindeutig: Für Traffic shaping default wird eine Übersteuerung durch die Firewall-Regel beschrieben, während die allgemeine Shaping-Beschreibung Anwendungen vor Firewall-Regeln einordnet. Daraus lässt sich keine verlässlich belegte Ausnahme abhängig vom Zustand des Schalters ableiten. Für einen eindeutig prüfbaren Einstieg verwendet man nur eine Shaping-Ebene und kontrolliert die Wirkung mit erkannter Application ID, Regelzuordnung und gemessener Datenrate. Werden Ebenen kombiniert, darf ihre Vorrangwirkung nicht ungeprüft vorausgesetzt werden.

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. Die allgemeine Shaping-Beschreibung nennt die Reihenfolge Anwendung, Anwendungskategorie, Webkategorie, Benutzer, Gruppe und zuletzt Firewall-Regel. Bei gleichzeitig zugewiesenen Policies bleibt die Vorrangwirkung wegen der abweichenden Übersteuerungsangabe für Traffic shaping default zu klären. 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.

Einzelne Anwendung begrenzen oder Kategorie garantieren

Für eine reine Obergrenze bleibt der Ablauf gleich, aber Rule type wird auf Limit gesetzt. Ein Beispiel für eine bereits erkannte Zoom-Anwendung ist eine Policy Zoom Limit mit Policy association > Applications, Rule type > Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) und Bandwidth usage type > Shared. 1000 KBps entsprechen 8 Mbit/s; dieser frei gewählte Startwert ist keine Zoom-Empfehlung und muss zur gemessenen Leitung und gewünschten Gesprächsqualität passen. Disable bedeutet hier, dass keine separaten Upload- und Download-Limits gesetzt werden, nicht dass Shaping deaktiviert ist. Unter Applications > Traffic shaping default wird Conferencing mit Expand geöffnet und bei Zoom meetings mit Edit die Policy zugewiesen. Im Application Filter wird über den Smart Filter Zoom die passende Anwendung ausgewählt. Filterregel, Filter und Firewall-Regel werden gespeichert; in der Firewall-Regel bleiben der passende Filter und Apply application-based traffic shaping policy erforderlich. Bei ausreichendem angebotenem Traffic prüft man, ob die Datenrate am gewählten Limit bleibt und die erkannte Application ID wirklich zu Zoom gehört.

Für eine gemeinsame Garantie einer ganzen Anwendungskategorie wird die Applications-Policy stattdessen direkt der Kategorie zugewiesen. Beispielsweise öffnet man Remote Access unter Traffic shaping default mit Edit und weist eine Guarantee-Policy mit Shared zu. Im Application Filter wird eine Regel mit Category > Remote access erstellt; danach werden die Regel und der Filter gespeichert und in der getroffenen Firewall-Regel der Filter sowie der Shaping-Schalter gesetzt. Alle von dieser Policy erfassten Anwendungen teilen den Pool, sie erhalten nicht jeweils die volle Garantie. Garantie und Limit werden aus der verfügbaren Kapazität und den tatsächlich benötigten gleichzeitigen Sitzungen gewählt. Eine Kategoriezuweisung erlaubt keine zuvor gesperrten Remote-Access-Anwendungen; bestehende Zugriffsvorgaben bleiben massgebend.

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.

Eine Rules-Policy kann so auch VPN-Verbindungen, einzelne Hosts, Hostgruppen oder Services formen. Für Traffic aus einem VPN wird in der passenden Regel Source zone > VPN verwendet; für IP- oder MAC-Hosts beziehungsweise Hostgruppen werden unter Source networks and devices die gewünschten Objekte gewählt. Services grenzen die Ports und Protokolle ein. Diese Kriterien bestimmen, welcher Traffic die Regel überhaupt trifft, bevor Shape traffic wirkt. Man beschränkt eine bestehende produktive Regel nicht nur für einen Shaping-Test unbedacht, sondern prüft vorher, welche erlaubten Verbindungen dadurch aus der Regel fallen würden.

Traffic Shaping auf weitere Objekte anwenden

Policy association bestimmt bereits beim Erstellen, wo eine Policy ausgewählt werden kann: Applications, Web categories, Users oder Rules. Im UI-Ablauf lässt sich eine Policy danach nicht in einen anderen Typ umwandeln; daraus wird keine API-Typmigration abgeleitet. Ein optionaler Schedule begrenzt ihre zeitliche Gültigkeit, ersetzt aber weder die Objektzuweisung noch den Funktionstest. Beim Erstellen findet man Add schedule weiter unten in der Policy: Mit Add werden die gewünschten Zeitangaben gesetzt, danach wird die Policy mit Save gespeichert. Ob mit oder ohne Schedule: Erst die Zuweisung zu Anwendung, Kategorie, Benutzer oder Regel macht die Policy wirksam. Bei einem zeitabhängigen Fehler kontrolliert man zusätzlich, ob der Test innerhalb des konfigurierten Zeitfensters stattfindet.

Webkategorien formen

Für eine Website oder Kategorie wird eine Policy mit Policy association > Web categories erstellt und unter Web > Categories der betreffenden Kategorie zugewiesen. Die Kategorie muss in einer wirksamen Web Policy vorkommen. In der tatsächlich getroffenen Firewall-Regel werden diese Web Policy und Apply web category-based traffic shaping aktiviert. Eine gespeicherte Kategoriezuweisung allein formt noch keinen Traffic.

Für nur eine bestimmte Website ist eine eigene Kategorie nachvollziehbarer als eine breite bestehende Kategorie. Als Beispiel erstellt man eine Policy Website Limit mit Web categories, Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) und Shared. Die 8 Mbit/s sind eine anpassbare Beispielobergrenze, keine allgemeine Web-Vorgabe; alle dieser Policy zugewiesenen Kategorien teilen den Pool. Eine Limit-Policy garantiert keine Mindestbandbreite.

1. Unter Web > Categories > Add eine Kategorie wie Example Website erstellen, Classification > Productive, die Policy Website Limit und Configure category > Local auswählen.
2. Unter Domain/keyword die Beispieldomain www.example.com mit der Plus-Schaltfläche hinzufügen und mit Save speichern. Im Betrieb wird sie durch die tatsächlich gewünschte Domain ersetzt. Ein zusätzliches Keyword wie example ist nur sinnvoll, wenn auch eine breitere Keyword-Zuordnung beabsichtigt ist; es wird nicht blind aus einem Beispiel übernommen.
3. Unter Web > Policies die wirksame Web Policy öffnen und mit Add eine passende Regel ergänzen. Unter Activities > Show only > Web categories die neue Kategorie wählen und mit Apply selected items übernehmen. Vor Save die bestehende Zugriffserlaubnis und Regelreihenfolge prüfen; Shaping ist kein Grund, gesperrte Websites freizugeben.
4. In der tatsächlich getroffenen Firewall-Regel unter Security features > Web filtering diese Web Policy auswählen, Apply web category-based traffic shaping aktivieren und die Regel speichern.

Anschliessend mit einer erlaubten Website aus der Kategorie prüfen, ob die erwartete Firewall-Regel und Webkategorie greifen und die Datenrate bei ausreichendem Traffic am Limit bleibt. Eine nicht zur Kategorie gehörende Website dient als Gegenprobe. Bei einem unerwarteten Treffer werden Domain-/Keyword-Zuordnung, Web-Policy-Regelreihenfolge und andere Shaping-Zuweisungen kontrolliert.

Webkategorien per XML API zuweisen

Für wiederkehrende Kategoriezuweisungen beschreibt die XML-Referenz WebFilterCategory mit QoSPolicy. Das Feld verweist auf die vorhandene Bandbreitenrichtlinie; für diesen Ablauf muss sie zu Web categories passen. Es ist weder eine Web Policy noch eine Allow-/Block-Aktion. Vor dem Schreiben Kategorieinhalt, bisherige Shaping-Zuweisung und Web-Policy-Referenzen sichern. Zugriff, explizite Operation, Build-Vertrag und XML-Status werden unter XML API sicher verwenden und Antworten auswerten erklärt. Die folgenden Objektbeziehungen sind keine ausführbare Request-Vorlage.

Bei ConfigureCategory verwendet Local die Hierarchie DomainList/Domain und KeywordList/Keyword; External verwendet URLList/URL für eine externe Kategorienliste. Eine externe Listen-URL ist nicht die Geschäfts-Domain, deren Traffic begrenzt werden soll. Herkunft, Aktualisierung und Inhalt der Liste prüfen und die beiden Eingabewege nicht ungeprüft mischen. Die Tabelle führt zusätzlich 0 auf, ohne dessen Bedeutung eindeutig zu erklären; daraus keinen Ersatz für die beiden benannten Wege ableiten.

Classification klassifiziert die Kategorie, erlaubt oder blockiert aber keinen Zugriff. Die Enum-Tabelle nennt Productive, Unproductive, Acceptable und Objectionable, während die Beschreibung teilweise andere Bezeichnungen verwendet. Keine übersetzten Klassifikationsnamen als API-Werte einsetzen; bei unklarem Vertrag zuerst API help des installierten Builds prüfen und nicht schreiben. Die Referenztabelle kennzeichnet QoSPolicy als Pflichtfeld mit maximal 50 Zeichen und ohne Komma; das Beispiel zeigt None. Dieses Beispiel ist kein belegter Laufzeit-Default und keine Bestätigung, dass ein ausgelassenes Feld die bisherige Zuweisung erhält oder entfernt. Für den Shaping-Fall die bestehende, passend zugeordnete Policy und ihren tatsächlich gespeicherten Namen prüfen.

Auch nach einer API-Zuweisung bleibt der UI-Ablauf oben vollständig erforderlich: Die Kategorie muss in der wirksamen Web Policy verwendet werden, und diese Policy sowie Apply web category-based traffic shaping müssen in der tatsächlich getroffenen Firewall-Regel gesetzt sein. Klassifikation, Kategorieinhalt, Zugriff und Bandbreite bleiben getrennte Entscheidungen. Mit einer erlaubten Website aus der Kategorie, einer Nicht-Treffer-Gegenprobe und einem weiterhin gesperrten Ziel prüfen, dass nur die beabsichtigte Bandbreitenzuweisung geändert wurde. Eine gespeicherte Kategorie ist noch kein Nachweis für wirksames Shaping.

Die Kategorieantworten unterscheiden sich je nach Operation. Die folgenden Werte sind XML-Statuscodes und unveränderte, unaufgelöste Referenzsymbole, keine HTTP-Codes oder hier bestätigten Meldungstexte:

Bei den Detailantworten Kategorieobjekt und jede benötigte Domain-, Keyword- beziehungsweise Listenmenge getrennt zurücklesen: Ein XML-2xx-Code bedeutet nicht automatisch, dass alle Details gespeichert wurden. Der gemeinsame Symbolname für die beiden Add-Erfolgscodes erklärt ihren Unterschied nicht. Die Symbole mit «MaxFive» belegen keinen universellen aktuellen Grenzwert von fünf Einträgen; den zulässigen Umfang aus der Build-Hilfe klären. Vor einer Löschung Web-Policy-Referenzen prüfen und danach feststellen, welche Kategorien tatsächlich verbleiben; bei einer Mehrfachauswahl keinen pauschalen Lösch-Erfolg annehmen.

Vor jedem Retry Antwort, Ist-Zustand und Audit Trail sichern. Danach Kategorieinhalt, QoSPolicy und Referenzen mit dem dokumentierten Vorzustand vergleichen und nur die noch notwendige eigene Korrektur planen. Eine teilweise gespeicherte Änderung nicht blind erneut anlegen, aktualisieren oder löschen. Für den Rückweg nur die eigene Kategorie-/Policy-Zuweisung auf den gesicherten Stand setzen; für geänderte Bandbreitenwerte bleibt in diesem UI-Runbook die Ersatz-Policy der sichere Ablauf. Die dokumentierte QoSPolicy-Update-Operation ist davon zu unterscheiden und unterliegt den oben erläuterten ungeklärten API-Verträgen.

Benutzer, Gruppen und WAF-Regeln

Eine Policy mit Policy association > Users wird unter Authentication > Users oder Authentication > Groups zugewiesen. In der Firewall-Regel aktiviert man Match known users und wählt die betreffenden Benutzer beziehungsweise Gruppen aus; die tatsächlich erkannte Identität muss zu dieser Auswahl passen. Für eine WAF-Regel wird dagegen eine Rules-Policy unter Advanced settings > Traffic shaping der Regel mit Action > Protect with web server protection zugewiesen.

Die allgemeine Shaping-Beschreibung nennt bei mehreren Ebenen die Reihenfolge Anwendung, Anwendungskategorie, Webkategorie, Benutzer, Gruppe und zuletzt Firewall-Regel. Die oben erläuterte abweichende Angabe für Traffic shaping default bleibt bei kombinierten Zuweisungen zu beachten. Deshalb wird mit einem echten Flow, dem erkannten Benutzer beziehungsweise der Application ID und der tatsächlich getroffenen Regel geprüft, welche Policy wirkt.

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 im UI erstellt man eine neue Policy-Version mit konservativ geänderten Werten, statt die bestehende Policy zu bearbeiten. 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

Mit NC-178197 wurde in SFOS 22.0 MR2 Build 546 ein Fehler behoben, 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.