FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Description This article reports a no correct functionality when touching ‘max-size’ under log memory on FortiGate, that may un-expectedly cause FortiManager to trigger a FortiGate reboot when installing a Policy Package change.
Solution The potential reboot reported in description happens if it is running verison 5.6 with FortiManager version 5.6.
Contest.
It can happen that customer needs to adjust the FortiGate ‘max-size’ log memory. On version 5.6 changing this value requires reboot. Normally customer avoid reboot during business hours and logically choose option no to not apply the max-size he was about to modify.
# config log memory global-setting (global-setting) set max-size 70000 To apply the change, system reboot is required. By choosing to continue system will be rebooted after setting is saved. Do you want to continue? (y/n)n
(global-setting) end
No reboot has been triggered.
Customer go ahead and starts to apply config changes on Policy Package related to any VDOM on this FortiGate. Once he has done, he applied the changes.
Issue.
Immediately after the changes have been applied, the Fortigate reboots. From event log it’s clear the reboot is cause by ‘log memory global-settings’ changes. Explanation.
Somehow the autoupdate feature imports in the unit DB the 'set max-size' even if customer typed no. When somebody creates a change on PolicyPackage and install it using wizard, it is also installing the unit DB diff into the FortiGate. Result is the reboot.
Workarounds.
1) If customer types by mistake a different set memory-size and apply y/n changes is not wanted, reset what it is already configure and then exit (for example using the Ctrl+C and key word abort). 2) A unit DB diff is present and revision history has a new revision # showing what ‘autosave’ feature imported from FortiGate to unit DB.
Solution.
Upgrade FortiManager to 6.0 trunk. The code has mainly change and this behavior is not present anymore.
Additional Info.
Version 6.2 and higher does not triggered any reboot anymore.
