FortiOS-6.4.x-Parallel Path Processing

FortiOS - Parallel Path Processing
Version 6.4.0
FORTINET DOCUMENT LIBRARY
https://docs.fortinet.com
FORTINET VIDEO GUIDE

https://video.fortinet.com
FORTINET BLOG
https://blog.fortinet.com
CUSTOMER SERVICE & SUPPORT

https://support.fortinet.com
FORTINET TRAINING & CERTIFICATION PROGRAM

https://www.fortinet.com/support-and-training/training.html
NSE INSTITUTE
https://training.fortinet.com
FORTIGUARD CENTER
https://fortiguard.com/
END USER LICENSE AGREEMENT

https://www.fortinet.com/doc/legal/EULA.pdf
FEEDBACK
Email: [email protected]
March 31, 2020

FortiOS 6.4.0 Parallel Path Processing
01-640-619132-20200331
TABLE OF CONTENTS
Change Log 4
Introduction 5
How this guide is organized 5
Parallel Path Processing 6
High-level list of processes that affect packets 6
Packet flow ingress and egress: FortiGates without network processor
offloading 8
Ingress 9
Admission control 9
Kernel 9
Destination NAT 9
Routing (including SD-WAN) 10
Stateful inspection/policy lookup/session management 10
Session helpers 10
User authentication 11
Device identification 11
SSL VPN 11
Local management traffic 11
UTM/NGFW 12
CP9 content processors 12
CP9 capabilities 12
Kernel 13
Egress 13
Packet flow: NP6 and NP6lite sessions 14
Packet flow: NP6 and NP6lite offloaded session 15
Access control list (ACL) 15
Packet flow: NTurbo 16
UTM/NGFW packet flow: flow-based inspection 17
UTM/NGFW packet flow: proxy-based inspection 19
UTM/NGFW packet flow: explicit web proxy 21
Comparison of inspection types 23
Mapping security functions to inspection types 23
More information about inspection methods 24
FortiOS 6.4.0 Parallel Path Processing 3

Fortinet Technologies Inc.
Change Log
Date Change Description
2020-03-31 Initial release.

Introduction
A FortiGate inspects network traffic from the IP layer up through the application layer of the TCP/IP stack. The
FortiGate uses security policies to do this inspection. Inspection steps depend on the FortiGate hardware such as
whether the FortiGate has network processors like the NP6 and content processors like the CP8 and CP9. It also
depends on the Unified Threat Management (UTM)/Next Generation Firewall (NGFW) inspection mode (flow-based or
proxy-based).
Before FortiOS 6.2.0, the inspection mode is based on the FortiGate or VDOM.
In FortiOS 6.2.0 and higher, the inspection mode is based on the security policy so you can
set a different inspection mode for each security policy.
This guide describes what happens to a packet as it travels through a FortiGate running FortiOS 6.2 and higher.
The FortiGate performs the following types of security inspection:
l Kernel-based stateful inspection, that provides individual packet-based security within a basic session state.
l Flow-based inspection, that takes a snapshot of content packets and uses pattern matching to identify security
threats in the content.
l Proxy-based inspection, that reconstructs content passing through the FortiGate and inspects the content for
security threats.
Each inspection component plays a role in the processing of a packet as it traverses the FortiGate en route to its
destination.
How this guide is organized
This guide contains the following sections:

l Parallel Path Processing introduces the concept of Parallel Path Processing.
l Packet flow ingress and egress: FortiGates without network processor offloading describes the overall packet flow
through a FortiGate with no network offloading (NP) hardware.
l Packet flow: NP6 and NP6lite sessions similar to the previous section, the first packet in a new session that can be
offloaded is processed in much the same way as on a FortiGate with no network processors.
l Packet flow: NP6 and NP6lite offloaded session describes the much simpler packet flow for a packet from an
offloaded session.
l UTM/NGFW packet flow: flow-based inspection describes how single pass UTM/NGFW processing occurs in a
flow-based firewall policy.
l UTM/NGFW packet flow: proxy-based inspection describes how UTM/NGFW processing occurs in a proxy-based
firewall policy.
l UTM/NGFW packet flow: explicit web proxy describes how Explicit web proxy processing occurs.
l Comparison of inspection types shows how different security functions map to different inspection types.

Parallel Path Processing
Parallel Path Processing (PPP) uses the firewall policy configuration to choose from a group of parallel options to
determine the optimal path for processing a packet. Most FortiOS features are applied through Firewall policies and the
features applied determine the path a packet takes. Using firewall policies you can impose UTM/NGFW processing on
content traffic that may contain security threats (such as HTTP, email and so on). Many UTM/NGFW processes are
offloaded and accelerated by CP8 or CP9 processors. Using the policy configuration you can apply a range of protection
from basic IPS attack protection that looks for network-based attacks to full scale advanced threat management (ATM),
application control, antivirus, DLP and so on.
You can also create policies for traffic that does not pose security threats and bypass UTM/NGFW checking. This
control allows you to improve network performance without compromising security. On FortiGates with network
processors (for example the NP6) much of the traffic that does not require UTM/NGFW processing can be offloaded to
the NP6 processors freeing up FortiGate processing resources for other higher risk traffic.
In addition, many FortiGate models support NTurbo to offload flow-based UTM/NGFW sessions to network processors.
Flow-based sessions can also be accelerated using IPSA technology to enhance offloading of pattern matching to CP8
and CP9 content processors.
This chapter begins with an overview of packet flow ingress and egress and includes a section that shows how NP6
offloading optimizes packet flow for packets that don't require UTM/NGFW processing and for packets that use NTurbo
to offload flow-based UTM/NGFW processing.
Next this chapter breaks down how packets pass through UTM/NGFW processing both for a single-pass flow-based
UTM/NGFW processing and a proxy-based UTM/NGFW processing.
High-level list of processes that affect packets
In general packets passing through a FortiGate can be affected by the following processes. This is a complete high-level
list of all of the processes. Not all packets see all of these processes. The processes a packet encounters depends on
the type of packet and on the FortiGate software and hardware configuration.
l Ingress packet flow
l Network Interface
l TCP/IP stack
l DoS Policy
l IP integrity header checking
l IPsec VPN decryption
l Admission Control
l Quarantine
l FortiTelemetry
l User Authentication

Parallel Path Processing
l Kernel
l Destination NAT
l Routing (including SD-WAN)
l Stateful inspection/Policy Lookup/Session management
l Session Helpers
l User Authentication
l Device Identification
l SSL VPN
l Local Management Traffic
l UTM/NGFW
l Flow-based inspection
l NTurbo
l IPSA
l Botnet check
l Proxy-based inspection
l Explicit Web Proxy
l Kernel
l Forwarding
l Source NAT (SNAT)
l Egress packet flow

l IPsec VPN Encryption
l Traffic shaping
l WAN Optimization
l TCP/IP stack
l Network Interface

Packet flow ingress and egress: FortiGates without network
processor offloading
This section describes the steps a packet goes through as it enters, passes through and exits from a FortiGate. This
scenario shows all of the steps a packet goes through if a FortiGate does not contain network processors (such as the
NP6).

Packet flow ingress and egress: FortiGates without network processor offloading
Ingress
All packets accepted by a FortiGate pass through a network interface and are processed by the TCP/IP stack. Then if
DoS policies have been configured the packet must pass through these as well as automatic IP integrity header
checking.
DoS scans are handled very early in the life of the packet to determine whether the traffic is valid or is part of a DoS
attack. The DoS module inspects all traffic flows but only tracks packets that can be used for DoS attacks (for example,
TCP SYN packets), to ensure they are within the permitted parameters. Suspected DoS attacks are blocked, other
packets are allowed.
IP integrity header checking reads the packet headers to verify if the packet is a valid TCP, UDP, ICMP, SCTP or GRE
packet. The only verification that is done at this step to ensure that the protocol header is the correct length. If it is, the
packet is allowed to carry on to the next step. If not, the packet is dropped.
Incoming IPsec packets that match configured IPsec tunnels on the FortiGate are decrypted after header checking is
done.
If the packet is an IPsec packet, the IPsec engine attempts to decrypt it. If the IPsec engine can apply the correct
encryption keys and decrypt the packet, the unencrypted packet is sent to the next step. Non-IPsec traffic and IPsec
traffic that cannot be decrypted passes on to the next step without being affected. IPsec VPN decryption is offloaded to
and accelerated by CP8 or CP9 processors.
Admission control
Admission control checks to make sure the packet is not from a source or headed to a destination on the quarantine list.
If configured admission control then imposes FortiTelemetry protection that requires a device to have FortiClient
installed before allowing packets from it. Admission control can also impose captive portal authentication on ingress
traffic.
Kernel
Once a packet makes it through all of the ingress steps, the FortiOS kernel performs the following checks to determine
what happens to the packet next.
Destination NAT
Destination NAT checks the NAT table and determines if the destination IP address for incoming traffic must be
changed using DNAT. DNAT is typically applied to traffic from the internet that is going to be directed to a server on a
network behind the FortiGate. DNAT means the actual address of the internal network is hidden from the internet. This
step determines whether a route to the destination address actually exists. DNAT must take place before routing so that
the FortiGate can route packets to the correct destination.

Routing (including SD-WAN)
Routing uses the routing table to determine the interface to be used by the packet as it leaves the FortiGate. Routing
also distinguishes between local traffic and forwarded traffic. Firewall policies are matched with packets depending on
the source and destination interface used by the packet. The source interface is known when the packet is received and
the destination interface is determined by routing.
SD-WAN is a special application of routing that provides route selection, load balancing, and failover among two or
more routes. SD-WAN also supports using the Internet Services Database (ISDB) and Application Control to select a
route in the following way:
l SD-WAN uses Application Control to compare the first packet of a new session against the layer 4 ISDB.
l If Application Control can identify the new session as a known application, SD-WAN is applied to the session
according to the matching SD-WAN rule. SD-WAN then routes all of the packets in the session according to the
selected SD-WAN rule.
l If Application Control cannot match a new session with an application in the layer 4 ISDB, the implicit SD-WAN rule
is applied to the session.
As the session is being processed by the implicit SD-WAN rule, layer 7 Application Control attempts to identify the
application. If the application can be identified, the ISDB is extended by adding a layer 4 match record for the
application to the ISDB cache. New sessions can then be matched and routed by SD-WAN using both the ISDB and the
ISDB cache.
Stateful inspection/policy lookup/session management
Stateful inspection looks at the first packet of a session and looks in the policy table to make a security decision about
the entire session. Stateful inspection looks at packet TCP SYN and FIN flags to identity the start and end of a session,
the source/destination IP, source/destination port and protocol. Other checks are also performed on the packet payload
and sequence numbers to verify it as a valid session and that the data is not corrupted or poorly formed.
When the first packet of a session is matched in the policy table, stateful inspection adds information about the session
to its session table. So when subsequent packets are received for the same session, stateful inspection can determine
how to handle them by looking them up in the session table (which is more efficient than looking them up in the policy
table).
Stateful inspection makes the decision to drop or allow a session and apply security features to it based on what is found
in the first packet of the session. Then all subsequent packets in the same session are processed in the same way.
When the final packet in the session is processed, the session is removed from the session table. Stateful inspection
also has a session idle timeout that removes sessions from the session table that have been idle for the length of the
timeout.
See the Stateful Firewall Wikipedia article (https://en.wikipedia.org/wiki/Stateful_firewall) for an excellent description
of stateful inspection.
Session helpers
Some protocols include information in the packet body (or payload) that must be analyzed to successfully process
sessions for this protocol. For example, the SIP VoIP protocol uses TCP control packets with a standard destination port
to set up SIP calls. To successfully process SIP VoIP calls, FortiOS must be able to extract information from the body of
the SIP packet and use this information to allow the voice-carrying packets through the firewall.

FortiOS uses session helpers to analyze the data in the packet bodies of some protocols and adjust the firewall to allow
those protocols to send packets through the firewall. FortiOS includes the following session helpers:
l PPTP l MMS
l H323 l PMAP
l RAS l SIP
l TNS l DNS-UDP
l TFTP l RSH
l RTSP l DCERPC
l FTP l MGCP
User authentication
User authentication added to security policies is handled by the stateful inspection, which is why Firewall authentication
is based on IP address. Authentication takes place after policy lookup selects a policy that includes authentication.
Device identification
Device identification is applied if required by the matching policy.
SSL VPN
Local SSL VPN traffic is treated like special management traffic as determined by the SSL VPN destination port.
Packets are decrypted and are routed to an SSL VPN interface. Policy lookup is then used to control how packets are
forwarded to their destination outside the FortiGate. SSL encryption and decryption is offloaded to and accelerated by
CP8 or CP9 processors.
Local management traffic
Local management traffic terminates at a FortiGate interface. This can be any FortiGate interface including dedicated
management interfaces. In multiple VDOM mode local management traffic terminates at the management interface. In
transparent mode, local management traffic terminates at the management IP address.
Local management traffic includes administrative access, some routing protocol communication, central management
from FortiManager, communication with the FortiGuard network and so on. Management traffic is allowed or blocked
according to the Local In Policy list which lists all management protocols and their access control settings. You configure
local management access indirectly by configuring administrative access and so on.
Management traffic is processed by applications such as the web server which displays the FortiOS GUI, the SSH server
for the CLI or the FortiGuard server to handle local FortiGuard database updates or FortiGuard Web Filtering URL
lookups.
Local management traffic is not involved in subsequent stateful inspection steps.
SSL VPN traffic terminates at a FortiGate interface similar to local management traffic. However, SSL VPN traffic uses
a different destination port number than administrative HTTPS traffic and can thus be detected and handled differently.

UTM/NGFW
If the policy matching the packet includes security profiles, then the packet is subject to Unified Threat Management
(UTM)/Next Generation Firewall (NGFW) processing. UTM/NGFW processing depends on the inspection mode of the
security policy: Flow-based (single pass architecture) or proxy-based. Proxy-based processing can include explicit or
transparent web proxy traffic. Many UTM/NGFW processes are offloaded and accelerated by CP8 or CP9 processors.
Single pass flow-based UTM/NGFW inspection identifies and blocks security threats in real time as they are identified
using single-pass Direct Filter Approach (DFA) pattern matching to identify possible attacks or threats.
Packets are then subject to botnet checking to make sure they are not destined for known botnet addresses.
Proxy-based UTM/NGFW inspection can apply both flow-based and proxy-based inspection. Packets initially encounter
the IPS engine, which can apply single-pass flow-based IPS and Application Control (as configured). The packets are
then sent to the proxy for proxy-based inspection. Proxy-based inspection can apply VoIP inspection, DLP, Email Filter
(Anti-Spam), Web Filtering, Antivirus, and ICAP.
Explicit web proxy inspection is similar to proxy based inspection.
CP9 content processors
Most FortiGate models contain Security Processing Unit (SPU) Content Processors (CPs) that accelerate many
common resource intensive security related processes. CPs work at the system level with tasks being offloaded to them
as determined by the main CPU. Capabilities of the CPs vary by model. Newer FortiGate units include CP9 processors.
Older CP versions still in use in currently operating FortiGate models include the CP4, CP5, CP6, and CP8.
CP9 capabilities
The CP9 content processor provides the following services:

l Flow-based inspection (IPS, application control etc.) pattern matching acceleration with over 10Gbps throughput
l IPS pre-scan
l IPS signature correlation
l Full match processors
l High performance VPN bulk data engine
l IPsec and SSL/TLS protocol processor
l DES/3DES/AES128/192/256 in accordance with FIPS46-3/FIPS81/FIPS197
l MD5/SHA-1/SHA256/384/512-96/128/192/256 with RFC1321 and FIPS180
l HMAC in accordance with RFC2104/2403/2404 and FIPS198
l ESN mode
l GCM support for NSA "Suite B" (RFC6379/RFC6460) including GCM-128/256; GMAC-128/256
l Key Exchange Processor that supports high performance IKE and RSA computation
l Public key exponentiation engine with hardware CRT support
l Primary checking for RSA key generation
l Handshake accelerator with automatic key material generation
l True Random Number generator

l Elliptic Curve support for NSA "Suite B"

l Sub public key engine (PKCE) to support up to 4096 bit operation directly (4k for DH and 8k for RSA with CRT)
l DLP fingerprint support
l TTTD (Two-Thresholds-Two-Divisors) content chunking
l Two thresholds and two divisors are configurable
Kernel
Traffic is now in the process of exiting the FortiGate. The kernel uses the routing table to forward the packet out the
correct exit interface.
The kernel also checks the NAT table and determines if the source IP address for outgoing traffic must be changed
using SNAT. SNAT is typically applied to traffic from an internal network heading out to the internet. SNAT means the
actual address of the internal network is hidden from the internet.
Egress
Before exiting the FortiGate, outgoing packets that are entering an IPsec VPN tunnel are encrypted and encapsulated.
IPsec VPN encryption is offloaded to and accelerated by CP8 or CP9 processors.
Traffic shaping is then imposed, if configured, followed by WAN Optimization. The packet is then processed by the
TCP/IP stack and exits out the egress interface.

Packet flow: NP6 and NP6lite sessions
On FortiGates with NP6 or NP6lite processors, the first packet of a session determines if the session can be offloaded.
As long as there is no proxy-based UTM/NGFW, if your FortiGate includes NP6 processors, most sessions can be
offloaded to them.

Packet flow: NP6 and NP6lite offloaded session
After the first packet, subsequent packets in an offloaded session skip routing, UTM/NGFW, and kernel processors and
are just forwarded out the egress interface by the NP6 processor. As well, security measures such as DoS policies, ACL,
and so on are accelerated by the NP6 processor.
Access control list (ACL)
Access Control Lists (ACLs) use NP6 offloading to drop IPv4 or IPv6 packets at the physical network interface before the
packets are analyzed by the CPU. The ACL feature is available only on FortiGates with NP6-accelerated interfaces. ACL
checking is one of the first things that happens to the packet and checking is done by the NP6 processor. The result is
very efficient protection that does not use CPU or memory resources.

Packet flow: NTurbo
If your FortiGate supports NTurbo, many flow-based UTM/NGFW sessions can be offloaded to NP6 processors.
After the first packet, subsequent packets in an offloaded flow-based UTM/NGFW session skip routing, and kernel
processors. Flow-based UTM/NGFW operations are still handled by the CPU with IPSA offloading pattern matching to
CP8 or CP9 processors.
If a security threat is found the session is dropped. Otherwise, packets that are not blocked by UTM/NGFW are
forwarded out of the egress interfaces by the NP6 processor.
NTurbo is not compatible with DoS policies, session helpers, or and most types of tunneling. If any of these features are
present, flow-based UTM/NGFW sessions are not offloaded by NTurbo.

UTM/NGFW packet flow: flow-based inspection
Flow-based UTM/NGFW inspection identifies and blocks security threats in real time as they are identified using single-
pass architecture that involves Direct Filter Approach (DFA) pattern matching to identify possible attacks or threats.
If a firewall policy is configured for flow-based inspection, depending on the options selected in the firewall policy that
accepted the session, flow-based inspection can apply IPS, Application Control, Web Filtering, DLP, Botnet
checking, and AntiVirus. Flow-based inspection is all done by the IPS engine and as you would expect, no proxying is
involved.
Flow-based DLP is supported but not recommended. Flow-based DLP is not available from
the GUI, but can be configured from the CLI.
Sniffer-policy and interface-policy are supported only in flow-based inspection.

Proxy-policy is supported in mixed flow-based and proxy-based inspection mode; but the
inspection mode is assumed to be proxy-mode and is not configurable.
Before flow-based inspection can be applied the IPS engine uses a series of decoders to determine the appropriate
security modules to be applied depending on the protocol of the packet and on policy settings. In addition, if SSL
inspection is configured, the IPS engine also decrypts SSL packets. SSL decryption is offloaded and accelerated by CP8
or CP9 processors.
If your configuration includes SSL mirroring, the IPS engine copies decrypted application content, wraps it inside a TCP
packet (with IP and Ethernet headers), and sends it to the configured mirror interface. The TCP connection tuple is
carried over from the original SSL connection. For the Ethernet frame, destination address is broadcast
(FF:FF:FF:FF:FF:FF) and source address is all zeros.
All of the applicable flow-based security modules are applied simultaneously in one single pass, and pattern matching is
offloaded and accelerated by CP8 or CP9 processors. IPS, Application Control, Local URL Filtering, Botnet checking,
and flow-based DLP filtering happen together. Flow-based antivirus caches files during protocol decoding and submits
cached files for virus scanning while the other matching is carried out.
Flow-based inspection typically requires less processing resources than proxy-based inspection and since it is not a
proxy, flow-based inspection does not change packets (unless a threat is found and packets are blocked). Flow-based
inspection cannot apply as many features as proxy inspection (for example, flow-based inspection does not support
client comforting or some aspects of replacement messages).
IPS, Botnet checking, and Application Control are only applied using flow-based inspection. Web Filtering, DLP and
Antivirus can also be applied using proxy-based inspection.

UTM/NGFW packet flow: flow-based inspection

UTM/NGFW packet flow: proxy-based inspection
If a firewall policy is configured for proxy-based inspection then a mixture of flow-based and proxy-based inspection
occurs. Packets initially encounter the IPS engine, which uses the same steps described in UTM/NGFW packet flow:
flow-based inspection on page 17 to apply single-pass IPS, Botnet checking, and Application Control if configured in the
firewall policy accepting the traffic.
Sniffer-policy and interface-policy are supported only in flow-based inspection.

Proxy-policy is supported in mixed flow-based and proxy-based inspection mode; but the
inspection mode is assumed to be proxy-mode and is not configurable.
The packets are then sent to the FortiOS UTM/NGFW proxy for proxy-based inspection. The proxy first determines if
the traffic is SSL traffic that should be decrypted for SSL inspection. SSL traffic to be inspected is decrypted by the
proxy. SSL decryption is offloaded to and accelerated by CP8 or CP9 processors.
Proxy-based inspection extracts and caches content, such as files and web pages, from content sessions and inspects
the cached content for threats. Content inspection happens in the following order: VoIP inspection, DLP, Email
Filter (Anti-Spam), Web Filtering, AntiVirus, and ICAP.
If no threat is found the proxy relays the content to its destination. If a threat is found the proxy can block the threat and
replace it with a replacement message.
Decrypted SSL traffic is sent to the IPS engine (where IPS and Application Control can be applied) before re-entering
the proxy where actual proxy-based inspection is applied to the decrypted SSL traffic. Once decrypted SSL traffic has
been inspected it is re-encrypted and forwarded to its destination. SSL encryption is offloaded to and accelerated by
CP8 or CP9 processors. If a threat is found the proxy can block the threat and replace it with a replacement message.
The proxy can also block VoIP traffic that contains threats. VoIP inspection can also look inside VoIP packets and extract
port and address information and open pinholes in the firewall to allow VoIP traffic through.
ICAP intercepts HTTP and HTTPS traffic and forwards it to an ICAP server. The FortiGate is the surrogate, or “middle-
man”, and carries the ICAP responses from the ICAP server to the ICAP client; the ICAP client then responds back, and
the FortiGate determines the action that should be taken with these ICAP responses and requests.

UTM/NGFW packet flow: proxy-based inspection

UTM/NGFW packet flow: explicit web proxy
If the explicit web proxy is enabled on a FortiGate or VDOM, a mixture of flow-based and proxy-based inspection occurs.
One or more interfaces configured to listen for web browser sessions on the configured explicit web proxy port (by
default 8080) accept all HTTP and HTTPS sessions on the explicit proxy port that match an explicit web proxy policy.
Plain text explicit web proxy HTTP traffic passes in parallel to both the IPS engine and the explicit web proxy for content
scanning. The IPS engine applies IPS, Botnet checking, and application control content scanning. The explicit web
proxy applies DLP, web filtering, and AntiVirus content scanning.
If the IPS engine and the explicit proxy do not detect any security threats, FortiOS relays the content to a destination
interface. If the IPS engine or the explicit proxy detect a threat, FortiOS can block the threat and replace it with a
replacement message.
Encrypted explicit web proxy HTTPS traffic passes to the explicit web proxy for decryption. Decrypted traffic once again
passes in parallel to the IPS engine and the explicit web proxy for content scanning.
If the IPS engine and the explicit proxy do not detect any security threats, the explicit proxy re-encrypts the traffic and
FortiOS relays the content to its destination. If the IPS engine or the explicit proxy detect a threat, FortiOS can block the
threat and replace it with a replacement message. The explicit proxy offloads HTTPS decryption and encryption to CP8
or CP9 processors.
FortiOS uses routing to route explicit web proxy sessions through the FortiGate to a destination interface. Before a
session leaves the exiting interface, the explicit web proxy changes the source addresses of the session packets to the
IP address of the exiting interface. A FortiGate operating in transparent mode changes the source address to the
transparent mode management IP address. You can also configure the explicit web proxy to keep the original client IP
address.

UTM/NGFW packet flow: explicit web proxy

Comparison of inspection types
The tables in this section show how different security functions map to different inspection types.
Mapping security functions to inspection types
The table below lists FortiOS security functions and shows whether they are applied by the kernel, flow-based
inspection or proxy-based inspection.
Security Function Kernel Flow-based inspection Proxy-based inspection

(Stateful inspection)
Firewall Yes
IPsec VPN Yes
Traffic shaping Yes
User authentication Yes
Management traffic Yes
SSL VPN Yes
IPS Yes
Botnet checking Yes
AntiVirus Yes Yes
Application control Yes
Web filtering Yes Yes
DLP Yes Yes
Email filtering (anti-spam) Yes Yes
VoIP inspection Yes
ICAP Yes

Comparison of inspection types
More information about inspection methods
The three inspection methods each have their own strengths and weaknesses. The following table looks at all three
methods side-by-side.
Feature Stateful Flow Proxy
Inspection unit per session First packet Selected packets, single pass Complete content,
architecture, simultaneous configured inspection
application of configured methods applied in order
inspection methods
Memory, CPU required Low Medium High
Level of threat protection Good Better Best
Authentication Yes
IPsec and SSL VPN Yes
AntiVirus protection Yes Yes
Web filtering Yes Yes
Data Leak Protection (DLP) Yes Yes
Application control Yes
IPS Yes
Delay in traffic Minor No Small
Reconstruct entire content No Yes
For more information, see the Inspection Modes section in the FortiOS Administration guide in the Fortinet Document
Library.

Copyright© 2020 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., in
the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company names may be
trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance and
other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding
commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet’s
General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such
event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be
limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any commitment related to future deliverables, features or
development, and circumstances may change such that any forward-looking statements herein are not accurate. Fortinet disclaims in full any covenants, representations, and
guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most
current version of the publication shall be applicable.

FortiOS-6.4.x-Parallel Path Processing

Uploaded by

Copyright:

Available Formats

FortiOS-6.4.x-Parallel Path Processing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FortiOS-6.4.x-Parallel Path Processing

Uploaded by

Copyright:

Available Formats

FortiOS - Parallel Path Processing

FORTINET VIDEO GUIDE

CUSTOMER SERVICE & SUPPORT

FORTINET TRAINING & CERTIFICATION PROGRAM

END USER LICENSE AGREEMENT

March 31, 2020

FortiOS 6.4.0 Parallel Path Processing 3

Date Change Description

2020-03-31 Initial release.

FortiOS 6.4.0 Parallel Path Processing 4

How this guide is organized

This guide contains the following sections:

FortiOS 6.4.0 Parallel Path Processing 5

High-level list of processes that affect packets

l IP integrity header checking

l IPsec VPN decryption

FortiOS 6.4.0 Parallel Path Processing 6

l Routing (including SD-WAN)

l Stateful inspection/Policy Lookup/Session management

l Local Management Traffic

l Explicit Web Proxy

l Source NAT (SNAT)

l Egress packet flow

FortiOS 6.4.0 Parallel Path Processing 7

FortiOS 6.4.0 Parallel Path Processing 8

FortiOS 6.4.0 Parallel Path Processing 9

Routing (including SD-WAN)

Stateful inspection/policy lookup/session management

FortiOS 6.4.0 Parallel Path Processing 10

Device identification is applied if required by the matching policy.

Local management traffic

FortiOS 6.4.0 Parallel Path Processing 11

CP9 content processors

The CP9 content processor provides the following services:

FortiOS 6.4.0 Parallel Path Processing 12

l Elliptic Curve support for NSA "Suite B"

FortiOS 6.4.0 Parallel Path Processing 13

FortiOS 6.4.0 Parallel Path Processing 14

Packet flow: NP6 and NP6lite offloaded session

Access control list (ACL)

FortiOS 6.4.0 Parallel Path Processing 15

Packet flow: NTurbo

FortiOS 6.4.0 Parallel Path Processing 16

Sniffer-policy and interface-policy are supported only in flow-based inspection.

FortiOS 6.4.0 Parallel Path Processing 17

FortiOS 6.4.0 Parallel Path Processing 18

Sniffer-policy and interface-policy are supported only in flow-based inspection.

FortiOS 6.4.0 Parallel Path Processing 19

FortiOS 6.4.0 Parallel Path Processing 20

FortiOS 6.4.0 Parallel Path Processing 21

FortiOS 6.4.0 Parallel Path Processing 22

Mapping security functions to inspection types

Security Function Kernel Flow-based inspection Proxy-based inspection

IPsec VPN Yes

Traffic shaping Yes

User authentication Yes

Management traffic Yes

SSL VPN Yes

Botnet checking Yes