Technical Tip: Security Policy re-evaluation (NGFW policy-based mode)

[Serxhio]

Description	This article describes the expected behavior for re-evaluating traffic when Security Policies are changed in NGFW policy-based mode.
Scope	FortiGate, NGFW Policy mode
Solution	In NGFW policy mode, incoming (new) traffic is assessed in two separate stages: Traffic is first assessed by the kernel against the SSL Inspection & Authentication Policy list (config firewall policy). Assuming an appropriate SSL policy match is found, the traffic is then assessed by the IPS Engine's Policy Match Engine (PME). See also: Technical Tip: How to check NGFW policy matching In the latter stage, the PME is assessing to determine which Security Policy (config firewall security-policy) will be matched for a given traffic flow. This process has the PME aggregate a list of feasible policy matches (based on the Source and Destination IP/port/protocol tuple), followed by scanning the traffic to identify it based on the filters in the policy (e.g. Application Signatures, URL Category, Service), and finally it matches the traffic to a specific Security Policy. This generates a session entry that the given traffic flow will continue to be matched to until it expires due to idle-timeout (all protocols) or when the session is explicitly ended (TCP only). However, if an administrator modifies the configuration (such as adding or changing Security Policies), it is often desirable for the FortiGate to re-assess existing sessions and potentially match them to new policies. In NGFW profile-based mode this behavior is very straightforward: all sessions can be dirtied and re-evaluated by changes to Firewall Policies. However, in the NGFW policy-based mode the behavior is more nuanced: If an existing traffic session is already matched to a Security Policy with the Deny action (including both admin-created Deny policies and the implicit-deny policy), then the traffic will NOT be re-evaluated when changes are made to the configuration (e.g. adding an Accept policy above or even deleting an explicit Deny policy). In order to force re-evaluation, the session must be manually cleared by the administrator (see: Technical Tip: Using filters to clear sessions on a FortiGate in the CLI). For existing traffic matched to an Accept policy, there is further nuance: Before v 6.4.6 and v7.0.1, only Security Policies filtered based on Application signatures would be re-evaluated on config change. Additionally, only non-hardware-offloaded sessions were supported. As of v6.4.6,v 7.0.1, and later these restrictions were lifted such that both offloaded and non-offloaded sessions with the Allow action could be re-evaluated (and there is no longer a requirement for the policy to filter based on Application). This is tracked in the Resolved Issues section under Issue #654356. Example: Traffic matching to an Accept Policy, then a Deny Policy. Consider an example with a valid session that is matching a Security Policy with the Accept action: host_A (IP 10.122.4.123) ngfwid=1 Notice how the ngfwid field (third row from the bottom) is marked with 1, which matches the aforementioned Security Policy ID. In the following screenshots, Security Policy #1 is modified to remove the 'host_A' Address object from the Source. This change triggers the traffic to fall through to the implicit-deny policy (ngfwid=0:( ngfwid=0  Even if host_A is added back to Security Policy #1, the traffic will not be re-evaluated and will still stick to the implicit deny policy (resulting in no traffic flow until the session is reset or manually cleared by the administrator). This behavior is by design for NGFW policy-based mode. This is less of an issue for TCP traffic (since the protocol has mechanisms for detecting and resetting stalled connections), but it can be a major issue for connection-less protocols like UDP or ICMP (which may just keep this block session active by continuing to send traffic blindly). As noted above, the session must either be re-established by the endpoints (e.g. resetting the TCP connection and starting a new one, or allowing UDP/ICMP traffic idle long enough for the session to expire) or the session entry must be manually cleared from the session table. New sessions will be freshly-evaluated against the current Security Policy list and will be able to match different policies.