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:
- Check-all: Flush all sessions and evaluate them anew. This is the default setting (If the firewall handles a huge number of sessions, flagging all sessions as dirty, and performing a firewall policy lookup for the sessions may result in high CPU utilization).
- Check-new: Keep existing sessions and check new connections only. This reduces CPU load and the possibility of packet loss.
- 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).
Policy Level:
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.
Configuration:
config system settings
set firewall-session-dirty { check-all | check-new | check-policy-option }
end
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 lis
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 lis
Session detail snippet:
state=persistent
This setting can restore even a VDOM configuration file without affecting established sessions.
Related article:
Technical Note: Firewall policy sequence may cause high CPU during policy add/modify.
