|
Schedules in FortiGate are useful for the status of the policy based on the requirements. Once the FortiGate time exceeds the end time configured in the Schedule, the Firewall policy that uses that schedule must become inactive, and new sessions should not match the policy. For more information about the behaviour of the schedule, refer to this article: Technical Tip: How to apply a schedule to a firewall policy.
In some instances, the FortiGate does not honor the time and does not make the security policy inactive. This leads to matching the incorrect policy in the FortiGate. For example, below is a configuration for the Schedule in the FortiGate
config firewall schedule recurring
edit "Lab"
set start 14:30
set end 07:00
set day sunday monday tuesday wednesday thursday
next
end
There are 2 Firewall policies configured in the FortiGate. One of the policies is using the above-mentioned schedule. As per this configuration, the Policy ID 1 must be active between 2:30 PM to 7:00 AM from Sunday to Thursday, and it should be inactive after 7:00 AM and match the Policy ID 2.
config firewall policy
edit 1
set name "With_Schedule"
set srcintf "port2"
set dstintf "port1"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "Lab"
set service "ALL"
set logtraffic all
set nat enable
next
edit 2
set name "Without_Schedule"
set srcintf "port2"
set dstintf "port1"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
set logtraffic all
set nat enable
next
end
The forward traffic logs in the FortiGate show that new sessions that are created after the scheduled end time still match the Policy ID 1, which is mentioned above.
Flow debug on the FortiGate shows that traffic is matching Policy ID 1, as it has not been made inactive.
FG421F-7 # 2026-01-14 07:23:48 id=65308 trace_id=99 func=print_pkt_detail line=5862 msg="vd-root:0 received a packet(proto=6, 10.110.18.185:1024->8.
8.4.4:443) tun_id=0.0.0.0 from port2. flag [S], seq 1353126896, ack 1132708156, win 512"
2026-01-14 07:23:48 id=65308 trace_id=99 func=init_ip_session_common line=6047 msg="allocate a new session-00649280"
2026-01-14 07:23:48 id=65308 trace_id=99 func=iprope_dnat_check line=5281 msg="in-[port2], out-[]"
2026-01-14 07:23:48 id=65308 trace_id=99 func=iprope_dnat_tree_check line=824 msg="len=0"
2026-01-14 07:23:48 id=65308 trace_id=99 func=iprope_dnat_check line=5293 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-000
00000"
2026-01-14 07:23:48 id=65308 trace_id=99 func=__vf_ip_route_input_rcu line=1990 msg="find a route: flag=00000000 gw-10.5.191.254 via port1"
2026-01-14 07:23:48 id=65308 trace_id=99 func=iprope_fwd_check line=768 msg="in-[port2], out-[port1], skb_flags-02000000, vid-0, app_id: 0, url_cat_
id: 0"
2026-01-14 07:23:48 id=65308 trace_id=99 func=__iprope_tree_check line=535 msg="gnum-100004, use addr/intf hash, len=3"
2026-01-14 07:23:48 id=65308 trace_id=99 func=__iprope_check_one_policy line=2033 msg="checked gnum-100004 policy-1, ret-matched, act-accept"
2026-01-14 07:23:48 id=65308 trace_id=99 func=__iprope_user_identity_check line=1807 msg="ret-matched"
2026-01-14 07:23:48 id=65308 trace_id=99 func=__iprope_check line=2281 msg="gnum-4e20, check-00000000a4677e7a"
2026-01-14 07:23:48 id=65308 trace_id=99 func=__iprope_check_one_policy line=2033 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
2026-01-14 07:23:48 id=65308 trace_id=99 func=__iprope_check_one_policy line=2033 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
2026-01-14 07:23:48 id=65308 trace_id=99 func=__iprope_check_one_policy line=2033 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
2026-01-14 07:23:48 id=65308 trace_id=99 func=__iprope_check line=2298 msg="gnum-4e20 check result: ret-no-match, act-accept, flag-00000000, flag2-0
0000000"
2026-01-14 07:23:48 id=65308 trace_id=99 func=get_new_addr line=1213 msg="find SNAT: IP-10.5.128.164(from IPPOOL), port-61441"
2026-01-14 07:23:48 id=65308 trace_id=99 func=__iprope_check_one_policy line=2251 msg="policy-1 is matched, act-accept"
This issue matches a reported issue in FortiOS versions 7.2 and 7.4, and the issue ID is 1002269. The issue is fixed in FortiOS versions 7.4.5, 7.6.0, and above.
One of the workarounds is to configure a dummy schedule in the FortiGate. This dummy schedule need not be added to any Firewall policy. The end time and start time for the dummy schedule should be configured based on the delays observed in matching the correct policy. For example, if the Firewall starts to match the policy with a schedule with a delay of 30 Minutes and stops matching it with a 30 Minute delay, then create a dummy schedule similar to the example below.
edit "Lab"
set start 18:00
set end 08:00
set day sunday monday tuesday wednesday thursday friday saturday
next
end
edit "Lab_Dummy"
set start 17:30
set end 07:30
set day sunday monday tuesday wednesday thursday friday saturday
next
end
|
