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.

Instead of creating a custom schedule, you can use an existing default schedule if its type and actually configured days, times, and date boundaries, where applicable, match the approved need. Check the values under Profiles > Schedule rather than inferring them from the name. If no default schedule fits, create a custom recurring or one-time schedule.

The right control point depends on the objective:

• If the entire network path should be open only at certain times, put the schedule in the firewall rule.
• If only a web or application action should change within an open path, assign the schedule to the relevant policy rule.
• If a user’s or group’s internet access should be allowed or blocked by time, an access time policy is usually clearer.
• A One-time schedule can only be assigned to a firewall rule.

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. In the recurring guest-access example, the zone and network are separate match fields:

• Recurring: Guest_BusinessHours, Monday through Friday, 07:30 to 18:00
• Firewall rule: Guest_to_WAN_BusinessHours
• Source zones: the dedicated guest zone, Guest in this example
• Source networks and devices: net_Guest_10.50.0.0_24
• Destination zones: WAN
• Destination networks: 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. The maintenance example assumes an inbound path that already works and has been tested. If the internal server is published to the internet, DNAT and the associated firewall rule must be configured correctly independently of the schedule; see Publish a server with DNAT or PAT.

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.

After saving, assign the schedule to the intended control point. Until then, it has no effect.

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 and select IPv4.
2. For a new rule, open Add firewall rule > New firewall rule, or edit an existing, already documented rule.
3. Set Action to Accept, and limit Source zones and Source networks and devices to the guest network.
4. Set Destination zones to WAN and Destination networks to Any. If only specific destinations are required, use a narrower destination object.
5. Select only the required Services, HTTP and HTTPS.
6. Under During scheduled time, select Guest_BusinessHours.
7. Assign suitable web, application, and IPS policies.
8. Turn on Log firewall traffic.
9. Check the rule position and save.

For a private guest network, a suitable SNAT rule must also exist unless the upstream routes the private source addresses. Check the NAT rule separately because Sophos Firewall also evaluates NAT rules on a first-match basis. A missing or incorrect NAT match is not fixed by the schedule. This example permits only HTTP and HTTPS; DNS resolution required for name-based access must work through a separately permitted and tested path.

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, create a dedicated one-time schedule:

1. Open Profiles > Schedule > Add.
2. Set Name to Vendor_Maintenance_2026-09-15, and record the ticket, owner, and purpose under Description.
3. Set Recurrence type to One-time.
4. Set both the start date and end date to September 15, 2026.
5. Set Start time to 22:00 and Stop time to 23:30.
6. Check the values again against the approved window and the firewall time zone, then save with Save.
7. Assign the schedule under During scheduled time to the already tested, tightly scoped maintenance rule.

The rule remains as a configuration object after the time window, but it does not match outside the schedule. The ticket 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 DNAT example, the permission must contain Source zones WAN, the confirmed address under Source networks and devices, the internal zone DMZ under Destination zones, Destination networks 10.20.30.40, the HTTPS service, logging, and the correct rule position. The firewall rule matches the translated internal destination after DNAT. Any as the source network or service remains unnecessarily risky even during a short window.

Use schedules in policies

Recurring schedules can also be used in other areas:

• Web policy: A rule within the web policy can be limited by time.
• Application policy: An application filter rule can have a schedule.
• Traffic shaping policy: Under System services > Traffic shaping > Add > Add schedule, assign a schedule to the bandwidth rule. It can then take effect through a user, firewall rule, web category, or application entry.
• Access time policy: A recurring schedule determines when Allow or Deny applies to assigned users and groups.
• Rogue AP scan: On appliances with integrated wireless, select the schedule under Wireless > Rogue AP scan > General settings > Schedule system-triggered scan at. The scan briefly disconnects clients, so the time window must account for this interruption.

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. After Sync now, Current time does not refresh immediately in the view; reload WebAdmin before diagnosing the time as still incorrect. The time and time zone shown on the firewall determine schedule evaluation.

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. All the time is not a universal rollback because it removes the time restriction completely.

To change an existing schedule, open Profiles > Schedule, clearly identify the intended schedule, and click Edit. The change affects all uses of this time object. Check the changed days, times, and date boundaries, where applicable, against the approval, save with Save, and repeat the validation described above before, during, and after the time window.

The rollback depends on what changed. If the schedule itself was edited, restore its documented previous values; if only the assignment was changed, reassign the unchanged previous schedule. Selecting an edited object again does not restore its timing. Disable or remove a newly created firewall rule in a controlled manner; for an existing rule, restore its action, match fields, policies, logging, and position to the documented previous values. If DNAT or SNAT was changed for the path, those rules and their positions are also part of the rollback.

A typical rollback is:

1. Keep the existing admin session and alternative management access open.
2. Depending on the starting point, restore the documented previous schedule values or reassign the unchanged previous schedule; disable the new rule or restore every changed rule field.
3. Compare associated NAT rules, rule position, and status with the documented previous values.
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 maintenance work.

Frequently asked questions