Set up Sophos Firewall schedules for rules and policies

A schedule makes a Sophos Firewall rule or policy effective only during a defined time window. This is useful for business hours, guest access, or an approved maintenance window. The solution is only secure when the firewall time is correct, the appropriate schedule type is selected, and no broader rule takes over the same traffic outside the window.

The quick path for a time-controlled firewall rule is:

1. Under Administration > Time, check the current time and time zone.
2. Under Profiles > Schedule > Add, create a recurring or one-time schedule.
3. Open the affected firewall rule and select the schedule under During scheduled time.
4. Check the rule position, source, destination, service, and logging again.
5. Test a new connection before, during, and after the time window.
6. In Log Viewer, verify which Firewall Rule ID actually processes the traffic.

⚠️ A schedule does not make an overly broad rule secure. It only limits when that specific rule or policy is effective. Source, destination, services, users, protection features, and rule order must still be planned narrowly.

What a schedule controls

Sophos Firewall uses schedules as reusable time objects. They can limit firewall rules, web policies, application policies, traffic shaping policies, access time policies, and rogue AP scans by time.

The schedule itself does not allow or block any traffic. It only takes effect when it is assigned to a rule, policy, or scan. All the time means that no time restriction is intended.

Recurring or one-time

Two models are available under Recurrence type:

• Recurring: Repeats on the selected weekdays and at the selected times. This type is suitable for office hours or regular maintenance windows, for example.
• One-time: Applies between a start and end date at the defined times. This type is suitable for a single conference, temporary guest access, or one-off maintenance.

A one-time schedule can only be applied to firewall rules. Web, application, and traffic shaping policies, access time policies, and rogue AP scans require a recurring schedule.

With Expand, a recurring schedule can use different start and end times for individual weekdays. This is clearer than several almost identical rules as long as the business approval is the same on all days.

Schedule and access time are not the same

A schedule only describes days and times. An Access time policy, on the other hand, combines a recurring schedule with the Allow or Deny action and is assigned to users, groups, or guest users.

Set up Access Time for users and groups explains the complete assignment, user-over-group precedence, and the AD main-group boundary.

For a time-limited network path, the schedule belongs directly in the firewall rule. For time-dependent internet access by a user or group, an access time policy may be more appropriate. The two mechanisms should not be layered without a clear reason, because it then becomes difficult to identify which layer ends access.

Plan the time basis and example values

Schedules follow the firewall clock and time zone. Before configuration, check at least Current time and Time zone under Administration > Time. Configure Sophos Firewall system time and NTP explains how to verify NTP and the time zone cleanly.

Changing NTP servers is not a casual troubleshooting step: Sophos states that all IPsec connections reconnect when this is done. A read-only check of the existing time basis is sufficient for the initial schedule validation.

The following sample values make the process tangible:

• Recurring: Guest_BusinessHours, Monday through Friday, 07:30 to 18:00
• Firewall rule: Guest_to_WAN_BusinessHours
• Source: net_Guest_10.50.0.0_24
• Destination: WAN and Any
• Services: HTTP and HTTPS
• One-time: Vendor_Maintenance_2026-09-15, on September 15, 2026, from 22:00 to 23:30
• External example source: 198.51.100.25
• Internal example destination: 10.20.30.40
• Service: HTTPS

198.51.100.25 is a documentation address and must be replaced with the service provider’s fixed public address. Names, networks, date, and times are also sample values. Use the actually approved source, the narrowest destination, the required services, and the authorized time window.

Create a recurring schedule

For the guest example, create a recurring schedule:

1. Open Profiles > Schedule.
2. Select Add.
3. Set Name to Guest_BusinessHours.
4. Under Description, document the purpose, owner, and time zone, for example Guest web access, Mon-Fri 07:30-18:00 Europe/Zurich, Owner IT.
5. Set Recurrence type to Recurring.
6. Select Monday through Friday.
7. Set Start time to 07:30 and Stop time to 18:00.
8. Leave Saturday and Sunday disabled.
9. For different daily times, use Expand and check each day individually.
10. Save with Save.

The saved schedule has no effect yet. Time control for the corresponding path is only enabled after it is assigned to a rule or policy.

Assign a schedule to a firewall rule

The actual permission remains a normal firewall rule. Understand and configure Sophos Firewall rules securely explains how match criteria, protection features, and rule order work together.

For the guest example:

1. Open Rules and policies > Firewall rules.
2. Create the Guest_to_WAN_BusinessHours rule or edit an existing, already documented rule.
3. Limit Source zones and Source networks and devices to the guest network.
4. Under During scheduled time, select Guest_BusinessHours.
5. Set Destination zones to WAN and exclude internal destinations.
6. Select only the required Services.
7. Assign suitable web, application, and IPS policies.
8. Turn on Log firewall traffic.
9. Check the rule position and save.

Sophos Firewall evaluates firewall rules from top to bottom. If the scheduled rule is not effective outside its schedule, a later, broader rule may allow the same traffic. A time-controlled allow rule therefore needs either a clearly separated match or a deliberately planned subsequent block logic. Validate the solution using the actual Firewall Rule ID, not just a successful page request.

One-time maintenance rule

For a single service-provider access window, select One-time under Profiles > Schedule > Add instead. Copy the start date, end date, and times from the approved maintenance window. Then assign the schedule to the narrow firewall rule under During scheduled time.

The rule remains as a configuration object after the time window, but it does not match outside the schedule. The ticket and owner should therefore also define whether the rule is disabled, deleted, or reused with a new schedule after completion.

A one-time rule is not a substitute for narrow criteria. In the example, the permission contains only the confirmed source address, destination host 10.20.30.40, required HTTPS service, logging, and correct rule position. A broad WAN source or Any as the service remains unnecessarily risky even during a short window.

Use schedules in policies

Recurring schedules can also be used in other areas:

• Web policy: Constraints specifies when a policy rule applies.
• Application policy: An application filter rule can have a schedule.
• Traffic shaping policy: The bandwidth rule is applied only during the selected schedule.
• Access time policy: A recurring schedule determines when Allow or Deny applies to assigned users and groups.
• Rogue AP scan: The scan can run at recurring times.

Time control of the policy and assignment of the policy are separate steps. A web or application policy only takes effect through the associated firewall rule. Set up and test Sophos Firewall Application Control explains application control in full, while Set up Sophos Firewall Web Protection with web policies covers web filtering logic.

Document multiple time layers in the same connection deliberately. A schedule in the firewall rule and a different schedule in a web or application policy can produce technically different results: the network path may remain open while only a specific web or application action changes.

Test time boundaries reliably

A saved configuration is not yet proof. Validation uses a new connection and the same test values before, during, and after the time window:

1. Document Current time and Time zone on the firewall.
2. Check the schedule type, weekdays, start time, and stop time.
3. Check the rule position and During scheduled time.
4. Shortly before the start, generate a defined test flow and record the expected block or fallback behavior.
5. Open a new connection after the start.
6. In Log Viewer, compare source, destination, service, Firewall Rule ID, action, and timestamp.
7. After the end, open another new connection and check which rule now applies.
8. For web or application policies, also check the policy, user, and policy action.

The complete process with Log Viewer, Packet Capture, and Rule ID is described in Test a Sophos Firewall rule cleanly.

Sophos does not generally document that every existing session is terminated immediately when a schedule ends. For security-critical access, therefore observe both a new connection after the boundary and an already running session. If existing sessions must end immediately, the schedule must not be treated as the only safeguard without real-world proof.

Narrow down errors systematically

Rule applies at the wrong time

First open Administration > Time and compare Current time and Time zone with the documented operating time. Then check the weekday, start time, stop time, and any per-day values configured with Expand. The admin browser’s time zone does not change the firewall time.

Traffic works outside the window

Use Log Viewer to identify the Firewall Rule ID that actually processed the traffic. A later general allow rule often takes over. In that case, correct the rule order and match logic instead of broadening the schedule. If no matching rule log appears, Packet Capture and the implicit drop-all rule #0 help narrow down the cause.

One-time is not available in a policy

This is the documented product limit: one-time schedules can only be assigned to firewall rules. Web, application, traffic shaping, and access time policies require a recurring schedule.

Schedule cannot be deleted

A schedule in use cannot be removed directly. First identify all dependent rules, policies, and scans. Then assign each dependency another suitable schedule or remove it in a controlled manner. Only delete the unused schedule afterward.

Policy changes, but the network path remains open

A policy schedule controls only the corresponding policy rule. If the entire network path must be closed outside the window, the firewall rule must also be limited by time and tested against later fallback rules.

Plan changes and rollback

Before a change, document the schedule name, type, days, times, time zone, all uses, and the position of affected firewall rules. For a safe return path, reassign the previous schedule rather than blindly selecting All the time.

A typical rollback is:

1. Keep the existing admin session and alternative management access open.
2. Assign the documented previous schedule to the affected rule or policy.
3. Confirm that the rule position and status remain unchanged.
4. Test with a new connection and the expected Rule ID.
5. Delete the new schedule only when no dependencies remain.
6. Update the ticket, owner, and test result.

For a one-time maintenance permission, include the planned cleanup in the ticket before activation. This prevents an inactive but undocumented rule from remaining after the appointment.

Frequently asked questions