Description
This article provides some information concerning firewall-session-dirty. It provides guidance to help choose the best approach for a given environment.
Solution
Firewall-session-dirty is a mechanism to make sure that active sessions always stay relevant. Two distinct behaviors would cause an active session to be validated differently.
Available options:
Global Level:
- Check-all: Flush all sessions affected by the edited firewall policy and re-evaluate them as new. This is the default setting.
- Check-new: Keep existing sessions and check new connections only.
- Check-policy-option: Use the option selected in the firewall-session-dirty field of the firewall policy.
(The firewall policy-level setting is available only if the VDOM-level setting is set to check-policy-option).
Configuration:
config system settings
set firewall-session-dirty { check-all | check-new | check-policy-option }
end
Policy Level:
- Check-all: Flush all sessions affected by the edited firewall policy and re-evaluate them as new. This is the default setting.
- Check-new: Keep existing sessions and check new connections only.
Configuration:
config firewall policy
edit <id>
set firewall-session-dirty < check-all | check-new >
next
end
Note:
The session re-validation would not be triggered by changing the 'firewall-session-dirty' system setting. Only consequent firewall policy changes or route changes for new sessions would trigger the set behavior.
Scenario 1:
With firewall-session-dirty check-all, active sessions would be marked as dirty for further firewall policy validation or route changes.
Note that there may be a CPU penalty if there are more than 2,000 firewall policies. For more information refer to the related KB article.
Validation:
diagnose sys session list
Session detail snippet:
state=may_dirty
Event: [changes applied to firewall policy]
state=dirty may_dirty <----- Sessions marked 'dirty' for firewall policy validation or route changes.
[continuous traffic cause firewall policy and route re-validation>
state=may_dirty <----- Validation done. 'dirty' marker removed.
A firewall policy change event means to modify a parameter related to an active/established session.
For example, changing address object, service object, schedule, ...
A route change event could be a new route that has a better preference than the existing route for an active/established session.
Scenario 2:
With firewall-session-dirty check-new, active sessions would be marked as persistent, and no firewall policy validation or route change lookup for existing active sessions would occur.
config system settings
set firewall-session-dirty check-new
end
Validation:
diagnose sys session list
Session detail snippet:
state=persistent
This setting can restore even a VDOM configuration file without affecting established sessions.
To change the firewall-session-dirty option from the FortiManager: Go to Device Manager -> Device & Groups -> Select the FortiGate (for FortiGates without VDOM) and the VDOM (for FortiGate with VDOMs configured) to change the firewall-session-dirty option -> Select the 'CLI Configuration' TAB -> Select the '+' on the left of 'System' -> Select 'Settings' –> Scroll down the System settings list on the right until the firewall-session-dirty row makes it possible to compare and choose available options on the menu to the right.
To push to the FortiGate the configuration change click on the button the Install Device Settings (only) in the top horizontal bar and follow the Install Wizard
Related documents:
Technical Tip: Firewall policy sequence may cause high CPU during policy add/modify.
FortiGate CLI reference
