Rule scheduling and time

Time-based firewall rules apply only during configured time windows. OPNsense supports them via schedules that can be attached to rules. A rule with a schedule of “business hours” matches only during business hours; outside that window, the rule does not match and traffic falls through to the next rule.

Time-based rules are occasionally the right tool and frequently the wrong one. The right tool for “users cannot reach X after hours” is usually an authentication or authorisation control, not a firewall schedule. The schedule introduces fragility — clock skew, DST, timezone mismatches, and human error in specifying the schedule all turn into “the rule does not work” tickets.

This lesson covers how to configure time-based rules, when scheduling is the right choice, the operational pitfalls, and how to diagnose a rule that fails because of a schedule mismatch.

How OPNsense schedules work

A schedule in OPNsense is a named time window that can be attached to a firewall rule. The schedules are defined under Firewall → Schedules. Each schedule has:

• A name (used to attach the schedule to a rule).
• A description.
• A start date and time.
• An end date and time (or no end, for a recurring schedule).
• A list of recurring time slots (e.g. weekdays 09:00–17:00).

A schedule can be one-shot (a single time window) or recurring (daily, weekly, monthly). The recurring schedules are the ones typically used for “business hours” rules.

When a schedule is attached to a rule, the rule matches only during the schedule’s active windows. Outside those windows, the rule is treated as if it did not exist — traffic falls through to the next rule.

$ pfctl -s rules | grep -A 1 'scheduler'

@200 pass in quick on igb0 inet proto tcp from 192.0.2.0/24 to 203.0.113.10 port = 22
@201 block drop in on igb0 inet from any to any

When scheduling is the right tool

Three scenarios where scheduling is the right choice:

Perimeter blocks during specific windows

The operator wants to block a specific service (e.g. peer-to- peer traffic, gaming traffic) during business hours to enforce a productivity policy. The schedule is attached to the block rule. Outside business hours, the block does not apply.

The trade-off: the operator is using the firewall as a productivity policy enforcement point. This is the right tool when no other layer is doing the job; it is the wrong tool when a content filter or endpoint agent is already in place.

Maintenance windows

The operator wants to permit specific traffic only during a planned maintenance window. For example, a remote administrator is given access to a server only during a four- hour window on Saturday night. The schedule is attached to the permit rule.

The trade-off: the schedule makes the access explicit and temporary. The operator does not need to remember to remove the rule; the schedule does it automatically.

Compliance-mandated access windows

A compliance regime mandates that certain access is permitted only during specific windows. For example, a PCI-DSS scope suggests that administrative access to cardholder data environments is permitted only during change windows.

The schedule is the compliance artefact. The auditor can see the schedule and verify that the access is bounded.

When scheduling is the wrong tool

Three scenarios where scheduling is the wrong choice:

“Users should not access X after hours”

The right tool for this is an authentication or authorisation control. The user logs in, the system checks their role, the role determines whether they can reach X. If the user is authorised, they get access regardless of time; if not, they are refused.

The schedule-based version of this requires the firewall to have a list of users (or user groups) with different schedules. The schedule is fragile (clock skew, DST, timezones) and the firewall is not the right place for the authorisation decision. The right place is the application or an identity-aware proxy.

“Block traffic from a known-bad source permanently”

The right tool is a permanent block rule with the source IP or alias. Schedules imply “this is temporary”. A permanent threat deserves a permanent block.

“Restrict access to specific users during business hours”

The right tool is a role-based access control on the application or service. The firewall does not know about users; it knows about source IPs and ports. Trying to express user-based access on the firewall means mapping users to IPs, which is fragile (laptop moves, DHCP lease changes, guest network).

Operational pitfalls

Four pitfalls recur with scheduled rules.

Clock skew

A scheduled rule depends on the firewall’s clock. If the firewall’s clock is wrong, the rule activates at the wrong time. The most common cause is NTP not configured or NTP servers unreachable.

The fix: configure NTP on the firewall with multiple servers (e.g. time.cloudflare.com, pool.ntp.org). Verify with ntpq -p that the firewall is synchronised.

$ ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*time.cloudflare 10.10.8.4        3 u  142  256  377    1.234   -0.123   0.456
+ntp.pool.org    194.58.202.20    2 u  247  256  377   12.345    0.234   1.123
-deutschland.dem 131.188.3.220    2 u  131  256  377   23.456    2.345   3.456

DST transitions

Most scheduled rules are configured with a specific local time (e.g. “weekdays 09:00–17:00”). During DST transitions, the local time jumps forward or backward by an hour. The schedule must account for this.

OPNsense stores schedules in the local timezone of the firewall. The schedule’s “weekdays 09:00–17:00” is interpreted in the firewall’s timezone. If the firewall’s timezone is set to a region that observes DST, the schedule automatically adjusts. If the firewall’s timezone is set to UTC, the schedule does not adjust — but the operator’s mental model might assume local time.

The fix: configure the firewall’s timezone explicitly (System → Settings → General → Time zone). Verify the timezone matches the schedule’s intent.

Timezone mismatches

A scheduled rule defined as “weekdays 09:00–17:00” with the firewall in UTC is different from the same schedule with the firewall in “Europe/Berlin”. The operator who sets up a schedule in their local timezone and then deploys the firewall to a different timezone sees the schedule fire at the wrong times.

The fix: standardise on UTC for firewall schedules. The operator’s mental model is local time but the firewall’s clock is UTC. Document the conversion and verify after every timezone change.

Schedule edge cases at the boundary

The schedule is checked at the moment PF evaluates the rule. If a connection is established just before the schedule ends, the connection continues to flow because the state entry exists. PF does not terminate established connections when the schedule ends.

The implication: a user who opens a connection at 16:59 keeps the connection past 17:00 when the schedule ends. The user can continue using the service until they close the connection or the state times out. This is usually the desired behaviour, but it surprises operators who expected the connection to drop at 17:00 sharp.

Diagnosing a scheduled rule that does not work

The most common “my scheduled rule does not work” tickets:

1. The schedule is wrong. Check the schedule definition: is the time window correct? Are the weekdays correct? Is the start/end date in the future?
2. The clock is wrong. Check date on the firewall. If the clock is wrong by hours, the schedule fires at the wrong times. Fix NTP.
3. The timezone is wrong. Check the firewall’s timezone under System → Settings → General. If the timezone differs from the operator’s expectation, the schedule fires at the wrong times in the operator’s local time.
4. The rule is in the wrong order. A scheduled rule above a more-specific rule may not produce the expected effect. Verify with pfctl -s rules that the scheduled rule is positioned correctly.
5. The state is cached. An existing connection matches the state, not the scheduled rule. Clear the state with pfctl -k state to verify the scheduled behaviour for a new flow.
6. The schedule is not actually attached to the rule. Check the rule’s “Schedule” field in the GUI. A common mistake is to define a schedule and forget to attach it to the rule.

Production patterns

Three patterns make scheduled rules manageable in production.

Document the schedule

Every scheduled rule has a corresponding comment in the configuration that documents the schedule’s intent. The comment includes the timezone, the time window, and the operator who created the schedule. When the operator leaves or the rule is reviewed, the next operator can understand the intent without having to interpret the schedule.

Pair the schedule with logging

A scheduled rule should have logging enabled for the window where it is active. The log shows when the rule matched, which allows the operator to verify the schedule is firing at the expected times.

Test the schedule at the boundaries

Before relying on a scheduled rule in production, test it at the boundaries: just before the schedule starts, just after, and during the schedule window. Verify that the rule behaves as expected at each transition.

Summary

• Schedules are named time windows that can be attached to rules. The rule matches only during the active window.
• Schedules are the right tool for perimeter blocks during specific windows, maintenance windows, and compliance- mandated access windows.
• Schedules are the wrong tool for identity-based access control — the firewall does not know about users.
• Operational pitfalls: clock skew, DST transitions, timezone mismatches, state caching across schedule boundaries.
• Verify the firewall’s clock and timezone before relying on a schedule.