Set up Sophos Firewall surfing and network traffic quotas

A Surfing quota limits the usable internet time of an authenticated user. A Network traffic quota, by contrast, limits the amount of data transferred. Both policies are assigned to a user or group and are suitable, for example, for training rooms, guests, or clearly defined usage packages.

For temporary guests, account creation, validity, Captive Portal, and cleanup are planned separately. The full lifecycle is covered in Create and securely manage guest users on Sophos Firewall; this article focuses on quotas.

The short path for a controlled introduction is:

1. Decide whether to limit time consumption, data volume, or both.
2. Create a new pilot policy under Profiles > Surfing quota or Profiles > Network traffic quota.
3. Assign the policy to a small pilot group under Authentication > Groups or to one test user under Authentication > Users.
4. Reauthenticate the user and verify the recognized identity under Current activities > Live users.
5. Use a user-based firewall rule with Log firewall traffic for the test.
6. Open the user under Authentication > Users and review consumption with View usage.
7. Test the limit, the next cycle, and rollback before adding more users.

⚠️ Reset user accounting resets both consumed surfing time and network traffic counters. This changes state and is not a general diagnostic button. Before a reset, document the user, current values, time, and reason. A shared production quota is likewise not edited directly; use a separate pilot policy for testing.

Choose the function that fits the requirement

Four similarly named functions solve different tasks:

• Access Time allows or blocks users during fixed time windows. It does not count consumption.
• Surfing quota gives a user a consumable time allowance for internet access.
• Network traffic quota gives a user a consumable data allowance.
• Traffic shaping limits or prioritizes bandwidth. A low data rate is not a data quota.

A Web Policy also offers a Quota action for time-limited access to specific web categories. This policy quota belongs to web proxy logic and is not the same feature as the user-based surfing quota in this article.

A quota creates neither a firewall rule nor a user identity. The firewall must recognize the user, the network path must be allowed, and the test traffic must match the expected rule. Only then can the quota be validated meaningfully.

For the separate web-category quota, Policy quota status shows the time remaining for each user and web policy within a 24-hour period. To perform an approved reset there, select the affected users and choose Reset. First record the user, policy, and remaining time; afterward, check the display and an allowed test request. Do not confuse this reset with Reset user accounting: an exhausted web-category quota is not a reason to clear the user’s surfing and data counters.

Plan the example and prerequisites

The continuous example uses a small pilot group with two separate policies:

• Group: Quota_Pilot
• Test user: quota-pilot
• Surfing quota: Students_InternetTime
• Cycle type: Cyclic (repeat access)
• Cycle hours: 24
• Maximum access time: 02:00
• Network traffic quota: Students_DataVolume
• Restriction: Total network traffic
• Cycle type: Cyclic
• Cycle period: Day
• Quota per cycle: 5000 MB
• Maximum quota: Unlimited

These are deliberately small documentation examples: each 24-hour cycle provides two hours of internet time, and each day provides 5000 MB of data volume. Adapt names, time, data volume, cycle, and overall limit to the actual usage agreement. Small test limits must not be copied into a production-only policy without checking their impact.

Before configuration, verify the following:

1. The pilot user can sign in with the intended authentication method.
2. The username and source address appear under Current activities > Live users.
3. For AD users, the Group field under Authentication > Users is correct.
4. A suitable user-based firewall rule allows the test traffic and has Log firewall traffic enabled.
5. Existing surfing quota, network traffic, access time, and traffic shaping assignments are documented.
6. The previous state and an alternative test user are known.

If the user is not visible as a Live User, correct authentication first. A quota cannot reliably assign unknown traffic, or traffic handled only by IP, to a normal user allowance.

Create a surfing quota

A surfing quota counts consumed internet time. In the SFOS 22 help, the same object is documented under both Profiles > Surfing quota and Web > Surfing quotas. Use the entry shown in WebAdmin on the deployed build.

You can also use existing default quotas; open an existing surfing quota with Edit. Consider the impact on every assigned user and group.

Choose Cyclic or Non-cyclic

• Cyclic (repeat access): The time allowance is provided again in recurring cycles. Unused time does not carry over to the next cycle.
• Non-cyclic (one-time access): The time allowance is provided once. The user is disconnected after it is consumed.

In addition, Validity period limits how many days the policy remains valid. Maximum access time defines the usable time. When the maximum is reached, the user is disconnected even if the quota validity period has not expired.

If multiple surfing quotas apply to a user, the firewall restricts access as soon as the first of these policies reaches its limit. Review all direct and group-based quota assignments together; a more generous second policy does not override a limit that has already been reached.

Unlimited for Maximum access time removes only the consumption-time limit, not the separately configured validity. For one-time unlimited use over one week, for example, choose Non-cyclic (one-time access), set Validity period to 7 days, and set Maximum access time to Unlimited. This is a different requirement from two hours per 24-hour cycle.

For the pilot example:

1. Open Profiles > Surfing quota > Add. If the build shows the feature under Web > Surfing quotas, select Add there.
2. Set Name to Students_InternetTime.
3. Enter, for example, Pilot: 2h per 24h, Owner IT as the Description.
4. Set Cycle type to Cyclic (repeat access).
5. Set Cycle hours to 24.
6. Deliberately define the Validity period for the pilot, or select Unlimited only if no expiration boundary is required.
7. Set Maximum access time to 02:00.
8. Save with Save.

The saved policy does not yet have an effect. Only assignment to a user or group connects the time allowance to an identity.

Understanding SurfingQuotaPolicy in the XML API

For automation, the user-based time allowance is called SurfingQuotaPolicy. It is neither a Network traffic quota nor the Quota action in a Web Policy. Secure XML API access explains access protection, explicit write operations, and the distinction between HTTP transport and XML results. Before making a change, preserve the exact object name, all saved values, and user and group assignments; edit only a separate pilot policy.

The XML references for SFOS 22.0 and 23.0 list the following fields. Use the following field specifications for serialization:

• Name is required: a string with a maximum of 60 characters and no commas; UTF-8 is allowed. This also applies to Delete Surfing Quota Policy. Description is optional and limited to 255 characters. The Default column lists no values for these fields; do not infer a runtime default from this.
• CycleType appears in the sample as Cyclic/NonCyclic; a request would require exactly one confirmed value, not the slash-separated expression. However, the parameter table also specifies both String and the range 1–87840. Do not transfer this contradictory range specification to another field or interpret it as a numeric encoding of the cycle.
• CycleHours is described as an optional string for cycle hours, with no numeric range. CycleMinutes is described as a required Integer field with a maximum of four digits. In particular, this does not establish a confirmed range of 0–59 for this field. The sample also includes PerDay with Days/Weekly/Monthly/Yearly, but the parameter table does not explain this field. Therefore, do not convert the UI setting Cycle hours and the pilot’s cycle length into these XML fields without verification.
• For finite validity, Validity is described as a string with 0–3660 days. MaximumHours describes finite total surfing hours as a string with a maximum of seven characters; Minutes is the additional minute value, a string in the range 0–59. Validity in days and consumable time in hours/minutes remain separate limits; validity is not a time allowance.

A finite field excerpt, explicitly not a complete or ready-to-send request, illustrates this last distinction:

<Validity>7</Validity>
<MaximumHours>2</MaximumHours>
<Minutes>0</Minutes>

The example values represent seven days of validity and two hours of total surfing time with no additional minutes. They do not show the complete implementation of the cyclic UI pilot of “two hours per 24 hours.” Cycle fields, assignment, and an explicit operation are deliberately omitted. Choose the days and time allowance from the approved usage agreement; for complete serialization, first cross-check API help for the installed build against a pilot object retrieved through a read operation.

For unlimited values, the sample shows for Validity and MaximumHours the text Unlimited/{Days}; separate table rows for Validity and Maximum Hours, however, specify -11 and the empty string ''. This does not confirm that these representations are interchangeable, that empty fields preserve existing values, or that Maximum Hours with a space is an XML tag. The hours description also does not fit the placeholder {Days} at MaximumHours. As long as the cycle representation or Unlimited encoding remains unresolved, do not send a write request, and arrange for build-specific clarification.

Check responses before another write attempt

For Add Surfing Quota Policy, Edit Surfing Quota Policy, and Delete Surfing Quota Policy, the operation, XML code, and reference symbol must be considered together. The references for SFOS 22.0 and 23.0 contain the same mappings:

Message.* entries here are literal, unresolved reference keys, not verified runtime messages. HTTP success is not XML operation success. Even an XML code of 200 does not replace reading back the saved target object: the name, cycle, validity, hours, and minutes must match the approved intended state. Only then validate the assignment and its effect using View usage, a fresh sign-in, and this article’s bounded consumption and limit test; saving alone does not prove enforcement.

For 500, 502, 504, an unclear response, or a timeout, first preserve the sanitized response and read the actual object state before considering any retry. For 502, check whether the desired object or a different object is already saved under the exact name; do not automatically switch from Add to Edit. For Delete with 504, check existing references and user/group assignments; do not remove dependent rules on speculation. Before an approved deletion, migrate assignments in a controlled manner, check dependencies again, and afterward confirm that exactly the pilot policy is absent and that the previous services still work. An error code proves neither an unchanged state nor that retrying is safe. An accounting reset is not a rollback for an API update or deletion.

Create a network traffic quota

A network traffic quota counts transferred data volume. It does not limit speed. A user can therefore consume the allowance quickly or slowly; an appropriate traffic shaping policy is additionally planned when a bandwidth limit is required.

Limit total traffic or upload and download separately

• Total network traffic: One shared allowance counts upload and download together.
• Individual network traffic (Upload & download): Upload and download receive separate limits. This fits only when the requirement genuinely treats the two directions separately.

There are also two cycle models:

• Cyclic: The allowance applies to each selected cycle. Available periods are Day, Week, Month, and Year. Unused data volume does not carry over.
• Non-cyclic: The allowance applies to a single cycle period.

Quota per cycle defines the allowance for each cycle. An optional Maximum quota adds an overall limit and must be higher than the cycle quota. When the cycle or overall limit is exhausted, the firewall disconnects the user. Reset user accounting is required to reconnect before the regular reset.

For the pilot example:

1. Open Profiles > Network traffic quota > Add.
2. Set Name to Students_DataVolume.
3. Enter, for example, Pilot: 5000 MB per day, Owner IT as the Description.
4. Set Restriction to Total network traffic.
5. Set Cycle type to Cyclic.
6. Set Cycle period to Day.
7. Set Quota per cycle to 5000 MB.
8. Leave Maximum quota set to Unlimited for this recurring example. If an overall limit is required, it must be higher than the cycle quota.
9. Save with Save.

The 5000 MB is an input value for this example, not a required value or conversion aid. In a real policy, derive the value from the approved allowance and enter it in the unit expected by WebAdmin. A separate upload/download policy instead receives its own justified value for each direction.

Default network traffic policies are also available; open existing policies with Edit. For a finite Maximum quota, clear the corresponding Unlimited checkbox and enter a value higher than the cycle quota. Reopen and check the values after saving; do not change a shared production policy for a pilot test.

Assign quotas to a group or user

Use a group as the normal operating method

For users with the same allowance, a group policy is easier to operate than many individual values:

1. Open Authentication > Groups.
2. Create the Quota_Pilot group or edit a clearly scoped pilot group.
3. Select Students_InternetTime for Surfing quota.
4. Select Students_DataVolume for Network traffic.
5. Do not change other access time, traffic shaping, remote access, or portal values incidentally.
6. Save.
7. Reauthenticate the pilot user and verify the group actually in use.

Manage Sophos Firewall user groups safely explains how local and imported groups, the main group, and user overrides interact. The actual AD import remains in Connect Active Directory to Sophos Firewall.

Check the user override and rule selection together

Under Authentication > Users, Surfing quota and Network traffic can be set differently for an individual user. However, the documentation describes precedence differently: the user-creation guide generally gives the user policy precedence, while the users overview makes it dependent on selection in rules and policies. It specifies group values when only the group is selected, and user values when both the user and their group are selected. Do not therefore assume an override takes effect unconditionally.

For the pilot, document the actual user/group selection in the affected rule or policy and both quota values. With a fresh sign-in, View usage, and a bounded test flow, establish which value takes effect on this build and path. If the display and expected limit disagree, stop the rollout; do not broaden a production rule or reorder groups as a quick fix. Then restore the previous assignments and rule selection and check again.

If a group change does not affect one user, inspect that user’s object first. An override is suitable for a documented exception or pilot, but can create hidden exceptions over time. To return to the group policy, restore the user to the previous inherited state in a controlled manner.

Only the main group counts for Active Directory

For AD users, surfing quota and network traffic do not use Other group memberships. The applicable value comes from the Main Group shown in the Group field under Authentication > Users, or from an explicit user policy.

The order under Authentication > Groups > Reorder can change the Main Group and therefore affect several policies at once. It must not be moved as a quick quota fix. After a planned group change, reauthenticate the user and verify the Main Group again.

Clientless Users are excluded

Clientless Users support neither surfing quota nor network traffic. For a fixed device without user sign-in, plan the network path, schedule, and, where needed, traffic shaping in a narrow firewall rule. User quotas are not used as an IP-based substitute.

Review consumption and validate the limit

View usage in WebAdmin

For consumption data, Sophos requires a user-based firewall rule with Log firewall traffic enabled. Then:

1. Reauthenticate the pilot user.
2. Verify the username and source address under Current activities > Live users.
3. Open Authentication > Users and select the pilot user.
4. Open View usage.
5. For surfing quota, review allotted time, expiration, and consumed internet time.
6. For network traffic, review Cycle renewal, upload, download, and allotted quota.
7. Generate a small allowed test transfer and review the change again.
8. In Log Viewer, correlate user, Source, Destination, Service, Firewall Rule ID, Action, and timestamp.

The monthly view additionally shows source IP, start, stop, duration, upload, and download. A consumption value alone does not prove that the intended path and correct rule were used. Therefore, combine View usage, Log Viewer, and a real test flow. Test a Sophos Firewall rule reliably explains the rule validation.

Read the separate areas in View usage carefully:

• Policy information: For AD, Group shows only the Main Group. Time allotted to user is the assigned surfing time, Surfing quota expiry date is its expiration date, and Internet usage time is consumption since the start or last reset. Data transfer cycle renewal shows renewal for a recurring data quota; non-recurring quotas show N.A..
• Usage information: Upload network traffic and Download network traffic show total consumption and consumption for the current session. Here, Allotted means the maximum assigned data quota.
• Current cycle usage information: For recurring quotas, Cycle upload network traffic and Cycle download network traffic refer only to the current daily, weekly, monthly, or yearly cycle. Here, Allotted means the cycle quota, not the overall maximum. To view historical sessions, select the required month from the list in View usage.

User-side review in the User Portal

The user view under Internet usage is separate from the administrative View usage:

• Policy information shows the user group, assigned surfing hours, surfing quota expiry date, data cycle renewal date, and internet time already consumed. For a guest account, it also shows the account expiry; account expiry and quota consumption answer different questions.
• Usage information shows the assigned, consumed, and remaining data allowance for upload and download.
• Monthly usage shows monthly surfing time and data transfer, helping users review past consumption rather than only the current remaining allowance.

Not every user sees every field: the account type and assigned policies determine what is displayed. A missing guest account expiry for a regular account is therefore not evidence of a quota error. This user view is for reviewing consumption, not for changing the policy or resetting counters.

In the User Portal, under Internet usage, a user can review allotted and consumed surfing time, cycle renewal, and upload, download, and remaining allowance depending on account type and policy. This reduces support queries but does not replace the administrator’s validation of assignment, Main Group, rule, and logs.

Test the consumption limit in a controlled manner

Use a separate pilot policy with a deliberately small but sufficient allowance for a limit test. The test must not affect a production group.

1. Document the starting values in View usage.
2. Start a clearly bounded HTTP or HTTPS test flow.
3. Observe consumption and Log Viewer during the test.
4. Confirm that reaching the limit produces the expected disconnection.
5. After the disconnection, reopen View usage and document the counter value and time.
6. Test the next regular cycle or an explicitly approved reset.
7. Restore the pilot policy and previous assignment afterward.

Use Reset user accounting safely

Reset user accounting resets the user’s surfing time and network traffic consumption. With an exhausted network traffic quota, this reset is required if the user must reconnect before the next regular cycle. This procedure can’t restore the previous counter values; the values captured beforehand are evidence, not a backup that can be restored.

A controlled reset is:

1. Document the user, ticket, reason, current quota values, and time.
2. Check whether the regular cycle change can be awaited.
3. Make sure the correct user is selected.
4. Open the user under Authentication > Users.
5. Open View usage and preserve the starting values.
6. Trigger Reset user accounting only with the intended approval.
7. Reauthenticate the user and verify the new counters.
8. Check a small test flow, the Firewall Rule ID, and logs.

The reset does not correct a wrong Main Group, missing user recognition, or a blocking firewall or web policy. If those causes are not resolved first, the problem returns despite the counters having been reset.

Troubleshoot systematically

The quota does not appear to count

First check whether the expected identity and source address appear under Current activities > Live users. Then verify that the traffic matches a user-based firewall rule with Log firewall traffic. If logging is missing or the flow uses another rule, View usage may remain incomplete.

Next compare the group policy, user override, and, for AD, the Main Group. Do not reduce the quota prematurely merely to force a visible effect.

A group quota affects only some users

Do not assume an explicit user policy is an effective override without checking user/group selection. Under Authentication > Users, inspect both quota fields and the Main Group, as well as selection in the rule or policy actually matched. For AD, Other group memberships are not evaluated. Reauthenticate the user after a group change.

The user is disconnected unexpectedly

Under View usage, check whether Cycle quota, Maximum quota, or Maximum access time has been reached. Then inspect Access Time, Web Policy, firewall rule, and authentication separately. A Captive Portal can also appear because of wrong credentials or other authentication issues; the quota is not automatically the cause. Set up and test the Sophos Firewall Captive Portal explains the complete sign-in path.

Consumption does not match expectations

Check whether Total network traffic or separate upload/download limits are configured. Then compare monthly details, source IP, Firewall Rule ID, and the actual test transfer. A network traffic quota counts data volume, not only visible browser downloads; background traffic from the authenticated user can also contribute to consumption.

A reset helps only briefly

If the user is disconnected again soon after the reset, inspect policy values, cycle, maximum, user override, and actual consumption. Do not reset the counter repeatedly before understanding the cause.

Rollback and operation

A controlled rollback restores the previous policy assignments. An accounting reset that has already been performed remains in effect:

1. Restore the previous surfing and network traffic assignments for the pilot user or pilot group.
2. For AD, reauthenticate the user and verify the Main Group.
3. Document View usage and current consumption.
4. Reset accounting in a controlled manner only if this was agreed for the test.
5. Run a small test flow and verify the Firewall Rule ID and logs.
6. Remove pilot policies only when no user or group dependency remains.
7. Update the ticket, owner, limits, and test result.

In operation, every shared quota needs a clear name, a description, an owner, and a documented reason for the cycle, allowance, and overall limit. Validate changes with a pilot user, a positive consumption test, and a negative limit test.

Operational checklist

• Time consumption and data consumption were planned separately.
• Surfing quota and network traffic quota have clear names and owners.
• Cycle, Validity, Quota per cycle, and Maximum are justified.
• The policies are assigned to the correct group or user.
• User overrides were reviewed.
• For AD, the Main Group is correct; Other group memberships are not assumed.
• Clientless Users are not planned with user quotas.
• The pilot user appears as a Live User.
• The user-based firewall rule logs the test traffic.
• View usage, User Portal, Firewall Rule ID, and real consumption align.
• Reset user accounting is used only with documentation and approval.
• The previous state and rollback are documented.

Frequently asked questions