Configure Application Traffic Shaping on Sophos Firewall

Application Traffic Shaping allows Sophos Firewall to prioritise or limit individual applications such as Microsoft Teams, VoIP, OneDrive, or backup services. The complete application-based workflow is:

1. Under System services > Traffic shaping, create a policy with Policy association > Applications.
2. Under Applications > Application filter, configure detection for the required application.
3. Under Applications > Traffic shaping default, assign the policy to the application or category.
4. Under Rules and policies > Firewall rules, select the Application Filter and enable Apply application-based traffic shaping policy.

A policy with Policy association > Rules in the Shape traffic field is a different method: It shapes all traffic that matches the firewall rule, not only the application selected in the Application Filter.

⚠️ Traffic Shaping does not create additional bandwidth. It distributes a bottleneck more predictably. If the connection is constantly saturated, capacity, backups, cloud synchronisation, and other sources of load still need to be investigated.

Traffic shaping limits a data rate, not the total amount of data transferred. For consumable time or data allowances, use surfing quota and network traffic quota instead.

Plan Prerequisites and Bandwidth

Before configuring Traffic Shaping, clarify the following:

• Application Control is required for application-based shaping. It is part of Web Protection and is also included in the Standard Protection bundle. Check the status under System > Administration > Licensing. A Rules policy, however, does not require application detection.
• The firewall detects the affected application, and the traffic passes through a known firewall rule.
• Logging is enabled for this rule.
• It is clear whether upload, download, or both directions are constrained and which WAN gateway or SD-WAN path is used.
• The intended effect is defined: Guarantee reserves minimum bandwidth and allows traffic up to the limit; Limit only sets a maximum.

Sophos displays shaping values in KBps, while speed tests usually use kbps or Mbps. 1 KBps equals 8 kbps. Therefore, 100 Mbps is approximately 12,500 KBps, and 20 Mbps is approximately 2,500 KBps.

Use stable measurements, not the provider’s advertised rate. If a nominal 100/20 Mbps connection reliably delivers only 80/15 Mbps, plan with approximately 10,000/1,875 KBps. Values above the actual bottleneck cannot control it effectively.

For asymmetric connections, enable Limit upload/download separately. Teams, VoIP, VPN, and cloud backups often suffer first when the upload is saturated. The global values under System services > Traffic shaping settings only apply to outbound traffic that the firewall forwards to the WAN zone. Individual traffic-shaping policies can instead apply to inbound and outbound forwarded traffic. QoS also does not apply to system-generated firewall traffic such as pattern updates or licence synchronisation.

Distinguish the Global Default from Individual Policies

Under System services > Traffic shaping settings, Total available WAN bandwidth defines the shared QoS capacity of all WAN links. Enter the sum of the bandwidth that is reliably available, in KBps, rather than only the contracted speed of one link. Show bandwidth usage shows how this capacity is distributed across priorities. These global values only affect forwarded outbound WAN traffic that doesn’t match an individual traffic-shaping policy.

With Optimize for real-time (VoIP), SFOS always prioritises real-time traffic first. If the option is disabled, policies that provide guarantees receive their guaranteed bandwidth first, and real-time traffic uses the remaining bandwidth. Enforce guaranteed bandwidth enables the Guarantee, Limit and Priority values from 1 to 7 from the Default Policy for traffic without its own policy. If Enforce guaranteed bandwidth is disabled, this traffic receives no guaranteed minimum bandwidth, only the capacity still available. For Priority, 1 represents the highest priority and 7 the lowest.

Don’t turn on these settings as a generic performance fix. First document the real bandwidth, existing guarantees, and intended priority. Otherwise, oversized guarantees compete for capacity that doesn’t physically exist.

Configure Application-Based Traffic Shaping

The following example prioritises traffic from up to four simultaneously active Teams video endpoints at a small site with a stable connection of approximately 80/15 Mbps. In its Teams bandwidth requirements, Microsoft recommends approximately 2,500 kbps upload and 4,000 kbps download per endpoint for a video meeting. The example values reserve this shared requirement but must be compared with local measurements and the actual number of simultaneously active endpoints.

Create a Traffic Shaping Policy

Under System services > Traffic shaping, create a new policy with values such as:

• Name: Teams Guarantee
• Policy association: Applications
• Rule type: Guarantee
• Limit upload/download separately: Enable
• Priority: 1 (highest priority)
• Upload Guarantee / Limit: 1,250 / 1,500 KBps
• Download Guarantee / Limit: 2,000 / 5,000 KBps
• Bandwidth usage type: Shared

1,250 KBps equals 10 Mbps, and 2,000 KBps equals 16 Mbps. With Shared, all applications or categories assigned to this policy share the same pool. Individual, in contrast, allocates the value only to the object to which the policy is first assigned, so don’t plan to reuse an Individual policy as a template for several objects. Do not spread high guarantee values across too many policies because their sum must remain within the bandwidth actually available. In this example, the guarantees equal the total recommended requirement for four Teams video endpoints. When bandwidth is available, they can use it up to the higher limits. The 12/40 Mbps limits deliberately leave capacity for other traffic on the measured 80/15 Mbps connection. These are starting values, not universal Teams requirements.

In the UI workflow described here, Traffic Shaping policies cannot be edited after creation. This UI restriction does not mean that the XML API does not document an update operation. If different values are required later, first document all assignments, create a replacement policy with a new name and initially migrate a limited scope. After validation, migrate the remaining assignments; remove the old policy only when no references to it remain. To roll back, reassign the old policy or None.

QoS policy: distinguish the UI workflow from the XML API contract

The XML API references for SFOS 22.0 and 23.0 explicitly document Add QoS policy / Update QoS policy for QoSPolicy and describe Add/Edit. This documents an API operation, but does not yet confirm an executable update contract for the installed build. The following object fields are not a complete request template. The safe UI replacement workflow remains the procedure for tuning. Access, explicit operations and response validation are explained in Use the XML API safely and interpret responses.

In the example, the bandwidth fields depend on PolicyType and ImplementationOn; they are not all required for every policy:

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

In the example, each burstable bandwidth value must be greater than its corresponding guarantee. The comments in the Individual branches mention only User, Firewall and Application; WebCategory appears under Total, not Individual. This neither confirms an Individual-WebCategory combination nor establishes a runtime prohibition. Moreover, ImplementationOn with Total/Individual is not the same field as BandwidthUsageType with Individual/Shared; identically named tokens are not interchangeable settings.

The example and parameter table are not consistently aligned: the example specifies 2–2560000 KB, while the table specifies 2–10240000. This does not establish a universal upper limit for the build. For BandwidthUsageType, the example shows Individual/Shared, whereas the table shows Shared Bandwidth Usage Type with on/off. PolicyBasedOn uses named tokens in the example, while Policy Based On is described in the table as an integer with a default of 0. Neither the token mapping nor a safe default when the field is omitted is inferred from this here.

Schedule details also have two representations that have not been unambiguously reconciled: the example shows SchedulebasedPolicyRuleList with Rule, DetailId, PolicyType, the conditional bandwidth fields and Schedule; DetailId also appears on the policy object. The table lists Implementation On as an array with 6/7, Policy Type as an array with 8/11, the bandwidth lists bandwidthlist, grntdbandwidthlist, burstbandwidthlist, upbandwidthlist, downbandwidthlist, grntdupbandwidthlist, grntddownbandwidthlist, as well as qosdetailnamelist and ScheduleDetail. The numeric enums are not mapped to named tokens here; ordering, detail identity and update/omission behaviour are not guessed.

Before an API change, API help for the installed build must clarify these unresolved limits, field names and schedule structures. While the contract remains unclear, do not assemble a write request from the example. Save the prior state, assignments and schedule details; after an approved change, read back the object and details separately and check the shaping effect within the affected time window. The reference lists XML statuses 200, 500 and 502 for both Add and Update. The reference uses the unresolved symbols Message.QOSAddSuccess, Message.QOSAddFail, Message.QOSEditSuccess, Message.QOSEditFail and Message.QOSRecordExist; the corresponding message texts remain unresolved. These symbols are not resolved message texts or HTTP codes. A status alone confirms neither all details nor the effect. If discrepancies occur, save the response and actual state and do not blindly retry; restore only your own change to the saved state.

Create an Application Filter

Under Applications > Application filter, create a filter that contains only the required traffic:

1. Assign a name such as Microsoft Teams.
2. Add an Application rule.
3. Search for microsoft teams in the Smart Filter.
4. Select the relevant Teams applications and use the Allow action.
5. Save the Application rule with Save, then also save the Application Filter with Save.

Do not treat Microsoft 365 as a single application by default. Teams, Exchange, SharePoint, and OneDrive generate different traffic and should initially be monitored separately. If the objective is detection and blocking rather than bandwidth, see Set Up and Test Sophos Firewall Application Control.

Assign the Policy to the Application

Under Applications > Traffic shaping default, locate Microsoft Teams or the relevant application category. Open a category directly with Edit. For an individual application, first open the category with Expand, then select Edit for the application. Select Teams Guarantee and confirm with Save.

A policy on an individual application takes precedence over a policy on its category. Where multiple levels match simultaneously, the general Shaping description states the order as application, application category, web category, user, group and finally firewall rule. If an additional Rules-Policy is present, the following discrepancy in the documentation must still be taken into account.

The assignment under Traffic shaping default does not yet enable application-based shaping; Apply application-based traffic shaping policy must also be enabled in the firewall rule that actually matches the traffic. However, if a Rules policy is assigned at the same time, the documentation is not unambiguous: the description of Traffic shaping default states that the firewall rule overrides it, whereas the general shaping description places applications before firewall rules. This does not establish a reliably documented exception dependent on the state of the toggle. For a clearly verifiable starting point, use only one shaping level and check its effect using the recognised Application ID, rule assignment and measured data rate. If levels are combined, their precedence must not be assumed without verification.

Enable the Firewall Rule

Under Rules and policies > Firewall rules, open the rule that actually handles the Teams traffic. In Other security features:

1. Under Identify and control applications (App control), select the Microsoft Teams filter.
2. Enable Apply application-based traffic shaping policy.
3. Save the rule and generate traffic.

The Applications policy is not selected in the Shape traffic field, but comes from Traffic shaping default. The general shaping description lists the order as application, application category, web category, user, group and finally firewall rule. Where policies are assigned simultaneously, clarify their precedence because the override statement for Traffic shaping default differs. Multiple levels should only be combined deliberately and tested with real traffic.

The rule order remains crucial: if the traffic already matches a more general rule higher up, neither the filter nor the shaping of the later rule is applied.

Limit an individual application or guarantee bandwidth for a category

For an upper limit only, the procedure remains the same, but Rule type is set to Limit. An example for a Zoom application that has already been recognised is a policy named Zoom Limit with Policy association > Applications, Rule type > Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) and Bandwidth usage type > Shared. 1000 KBps is equivalent to 8 Mbit/s; this freely chosen starting value is not a Zoom recommendation and must suit the measured connection capacity and desired call quality. Here, Disable means that no separate upload and download limits are set, not that shaping is disabled. Under Applications > Traffic shaping default, open Conferencing with Expand and assign the policy to Zoom meetings using Edit. In the Application Filter, use the Smart Filter Zoom to select the appropriate application. Save the filter rule, filter and firewall rule; the appropriate filter and Apply application-based traffic shaping policy remain required in the firewall rule. With sufficient offered traffic, check whether the data rate remains at the selected limit and whether the recognised Application ID really belongs to Zoom.

For a shared guarantee for an entire application category, assign the Applications policy directly to the category instead. For example, open Remote Access under Traffic shaping default with Edit and assign a Guarantee policy with Shared. In the Application Filter, create a rule with Category > Remote access; then save the rule and filter, and set the filter and shaping toggle in the firewall rule that matches the traffic. All applications covered by this policy share the pool; they do not each receive the full guarantee. Choose the guarantee and limit based on the available capacity and the concurrent sessions actually required. A category assignment does not permit previously blocked remote-access applications; existing access requirements remain authoritative.

Rule-Based Traffic Shaping for an Entire Rule

If all traffic of a clearly scoped firewall rule should receive the same values, a Rules policy is simpler:

1. Under System services > Traffic shaping, create a policy with Policy association > Rules.
2. Under Rules and policies > Firewall rules, open the affected rule.
3. Under Shape traffic, select the Rules policy.
4. Do not enable Apply application-based traffic shaping policy unless additional Applications policies are used.

An Application Filter does not automatically restrict a Rules policy to that application. For this, either the firewall rule itself must be narrowly scoped by source, destination and services, or the application-based procedure must be used. DSCP marking is also not a substitute for shaping: DSCP marks packets for downstream devices, whereas the shaping policy on the firewall guarantees or limits bandwidth.

A Rules policy can therefore also shape VPN connections, individual hosts, host groups or services. For traffic from a VPN, use Source zone > VPN in the appropriate rule; for IP or MAC hosts or host groups, select the required objects under Source networks and devices. Services narrow down the ports and protocols. These criteria determine which traffic matches the rule at all, before Shape traffic takes effect. Do not restrict an existing production rule without due consideration merely for a shaping test; first check which permitted connections would no longer match the rule as a result.

Apply Traffic Shaping to Other Objects

Policy association determines at creation where a policy can be selected: Applications, Web categories, Users or Rules. In the UI workflow, a policy cannot subsequently be converted to another type; no API type migration is inferred from this. An optional schedule limits its validity period, but replaces neither the object assignment nor functional testing. During creation, Add schedule is available further down in the policy: use Add to set the required times, then save the policy with Save. With or without a schedule, the policy only takes effect once it is assigned to an application, category, user or rule. For a time-dependent fault, also check whether the test is taking place within the configured time window.

Shape Web Categories

For a website or category, create a policy with Policy association > Web categories and assign it to the relevant category under Web > Categories. The category must be included in an effective Web Policy. Enable this Web Policy and Apply web category-based traffic shaping in the firewall rule that actually matches the traffic. A saved category assignment alone does not yet shape any traffic.

For just one specific website, a dedicated category is more transparent than a broad existing category. As an example, create a policy named Website Limit with Web categories, Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) and Shared. The 8 Mbit/s is an adjustable example upper limit, not a general web requirement; all categories assigned to this policy share the pool. A Limit policy does not guarantee minimum bandwidth.

1. Under Web > Categories > Add, create a category such as Example Website, and select Classification > Productive, the policy Website Limit and Configure category > Local.
2. Under Domain/keyword, add the example domain www.example.com using the plus button and save with Save. In production, replace it with the actual required domain. An additional keyword such as example is only appropriate if a broader keyword match is also intended; it must not be copied blindly from an example.
3. Under Web > Policies, open the effective Web Policy and add an appropriate rule with Add. Under Activities > Show only > Web categories, select the new category and apply it with Apply selected items. Before Save, check the existing access permission and rule order; shaping is not a reason to allow blocked websites.
4. In the firewall rule that actually matches the traffic, select this Web Policy under Security features > Web filtering, enable Apply web category-based traffic shaping and save the rule.

Then use a permitted website from the category to check whether the expected firewall rule and web category match and whether the data rate remains at the limit with sufficient traffic. Use a website that does not belong to the category as a control test. If an unexpected match occurs, check the domain/keyword assignment, Web Policy rule order and other shaping assignments.

Assign web categories via the XML API

For recurring category assignments, the XML reference describes WebFilterCategory with QoSPolicy. The field refers to the existing bandwidth policy; for this workflow, it must be associated with Web categories. It is neither a Web Policy nor an Allow/Block action. Before writing, save the category content, the existing shaping assignment and the Web Policy references. Access, explicit operations, the build-specific contract and XML status are explained under Use the XML API safely and interpret responses. The following object relationships are not an executable request template.

For ConfigureCategory, Local uses the hierarchy DomainList/Domain and KeywordList/Keyword; External uses URLList/URL for an external category list. An external list URL is not the business domain whose traffic is to be limited. Check the source, updates and content of the list, and do not mix the two input methods without checking them first. The table also lists 0 without clearly explaining its meaning; do not infer that it is a substitute for either of the two named methods.

Classification classifies the category but does not allow or block access. The enum table lists Productive, Unproductive, Acceptable and Objectionable, while the description uses different terms in places. Do not use translated classification names as API values; if the contract is unclear, first check API help for the installed build and do not write. The reference table marks QoSPolicy as a required field with a maximum of 50 characters and no comma; the example shows None. This example is not an established runtime default and does not confirm that omitting the field preserves or removes the existing assignment. For shaping, check the existing policy with the appropriate association and its actual stored name.

Even after an API assignment, the full UI workflow above remains necessary: the category must be used in the effective Web Policy, and both this policy and Apply web category-based traffic shaping must be set in the firewall rule that actually matches the traffic. Classification, category content, access and bandwidth remain separate decisions. Test with a permitted website from the category, a non-matching control website and a target that remains blocked to verify that only the intended bandwidth assignment has changed. A saved category is not yet evidence of effective shaping.

Category responses differ by operation. The following values are XML status codes and unchanged, unresolved reference symbols, not HTTP codes or resolved message texts:

For detail responses, read back the category object and each required set of domains, keywords or lists separately: an XML 2xx code does not automatically mean that all details have been saved. The shared symbol name for the two Add success codes does not explain their difference. The symbols containing “MaxFive” do not establish a universal current limit of five entries; check the build help to establish the permitted number. Before deletion, check Web Policy references, then determine which categories actually remain afterwards; do not assume that deletion has succeeded for every category in a multiple selection.

Before every retry, save the response, actual state and Audit Trail. Then compare the category content, QoSPolicy and references with the documented prior state, and plan only the correction still required for your own change. Do not blindly repeat an add, update or delete operation after a partially saved change. To roll back, restore only your own category/policy assignment to the saved state; for changed bandwidth values, the replacement policy remains the safe workflow in this UI runbook. The documented QoSPolicy update operation is distinct from this and is subject to the unresolved API contracts explained above.

Users, Groups, and WAF Rules

A policy with Policy association > Users is assigned under Authentication > Users or Authentication > Groups. In the firewall rule, enable Match known users and select the relevant users or groups; the identity actually recognised must match this selection. For a WAF rule, by contrast, assign a Rules policy under Advanced settings > Traffic shaping in the rule with Action > Protect with web server protection.

For multiple levels, the general shaping description lists the order as application, application category, web category, user, group and finally firewall rule. The differing statement for Traffic shaping default explained above must still be taken into account when assignments are combined. Therefore, use a real flow, the recognised user or Application ID and the rule that actually matches the traffic to check which policy takes effect.

Verify the Effect and Safely Adjust the Policy

After the change, do not rely on a speed test alone. Check whether:

• The traffic matches the expected firewall rule.
• Application Control logs show the expected application or Application ID.
• Reports such as Top Applications and the rule counters confirm the expected assignment.
• The affected direction is actually saturated during the test.
• Bandwidth, latency, packet loss, or call quality changes as expected.
• The test uses the same WAN gateway and SD-WAN path as production traffic.
• Feedback from users of real-time services confirms the technical measurements in practice.

For a reliable before-and-after comparison, use the same source, destination, direction, and, if possible, time period. Test Sophos Firewall Performance with iPerf and Speedtest explains suitable measurement methods. For multiple connections, also see Check Sophos Firewall SD-WAN Routing for Reply Packets and System Traffic.

For tuning in the UI, create a new policy version with conservatively adjusted values rather than editing the existing policy. Assign it first to a narrowly scoped application, category or rule, monitor logs and user feedback, and remove the old policy only after successful validation. The purpose, affected rule, values, owner and review date should be documented.

When Traffic Shaping Does Not Work as Expected

The Application Is Not Detected

First, verify that the correct Application Filter is selected in the firewall rule that the traffic actually matches. For broad or encrypted cloud services, use the detected Application ID in the Application Control log to confirm classification.

Shaping Makes No Difference

If the connection is not saturated during the test, there is no visible bottleneck to control. Other common causes include values above the actual bandwidth, the wrong direction, a broader firewall rule higher up, or a different SD-WAN path.

Application-based shaping also requires all three assignments to be correct: a policy with Applications, its assignment under Traffic shaping default, and the enabled option in the firewall rule. The option alone does not assign bandwidth.

Application Traffic Stops Intermittently

SFOS 22.0 MR2 Build 546 fixes NC-178197, which could cause application traffic to stop intermittently when an application-based bandwidth policy was applied. If this symptom occurs on SFOS 22.0 GA or MR1, check the firmware version before redesigning the policies and update to MR2 or a later approved version.

Microsoft 365 or the Guest Network Remains Problematic

Assess Microsoft 365 separately for Teams, Exchange, SharePoint, and OneDrive instead of blindly guaranteeing or limiting the entire category. For the guest network, verify that its traffic matches the intended rule and that both upload and download are limited where necessary.