FortiGate
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.
Atul_S
Staff & Editor
Staff & Editor
Article Id 339863
Description This article describes the way FortiGate handles an inbound packet without offloading.
Scope FortiGate.
Solution

Functionality can be largely divided into stages:

 

Stage 1: Parsing and Integrity Check.

 

  • The network access and transport layers in the TCP/IP stack are the first ones to scan the received packet at the FortiGate.
  • Denial of Service policies and Internet checksum are inspected to identify any malicious header value.
  • Denial of Service validation occurs at the beginning of stage 1 to isolate any event related to threat posture for service interruption, such as malicious TCP FIN packets.
  • Internet checksum inspection ensures the correct length for protocols such as OSPF, BGP, IGMP, or L2TP; packets that do not meet the criteria will not be passed to the next phase.
  • After verifying the headers, incoming IPsec packets that match configured tunnels are decoded by the IPsec engine using the correct keys. Once unscrambled, these packets proceed to the next stage of processing.

 

Stage 2: Admission Control.

 

  • Check against quarantine list and telemetry protection, captive portal authentication. Once all these checks are done, the packet is handed over to Kernel.
  • Destination NAT to specify if the dest IP for the incoming packet has to be changed before route lookup.
  • Route lookup is carried out once the layer 3 info is validated based on SRC and DST. This check forms the basis of firewall policy lookup at a later stage.
  • Parallel to route lookup, the SD-WAN rule defines route selection, load balance, and failover checks carried using ISDB and application control in the below sequence:
  1. Application control is used to verify the packet against ISDB entry.
  2. If App control identifies the packet/session as a known app within ISDB, the SD-WAN rule is applied.
  3. If App control fails to identify the packet/session as a known app within ISDB, the SD-WAN implicit rule is applied.

 

  • Once the SD-WAN and route lookup stage passes, the packet is handed over for policy lookup and session mgmt with the below checks:
  1. TCP flags checks to identify the TCP state to form the basis for session table entries and their establishment.
  2. MSS/MTU, flow control, and checksum check carried out.
  3. Layer 5 info extracted from the header to initiate session helper.

 

  • Once a session is established for a given flow of packets, an IPv4 policy lookup is carried out followed by a user and device identification check.
  • For a FortiGate self-generated traffic or mgmt traffic, a local-in policy check is carried out and a relevant internal daemon is called out to internal daemon like newcli and fdsmgmtd.


Stage 3: Unified Management.

 

  • Once the IPv4 policy is matched, the packet is moved to layers 5, 6, and 7 for inspection, and SSL offloading and is subjected to unified threat management.
  • The UTM handling inspection depends upon the inspection architecture of the given policy whether to carry out a direct filter approach (DFA for flow) or a buffer (proxy) approach which maintains a dual TCP state(one each with user and server).
  • Signature-based scan(eg. Botnet, Trojan, CinC, etc), VoIP, DLP, Email, Web, Antivirus, app control, ICAP, etc carried out.


Once the UTM checks are completed, packets are then handed out to Kernel again where it applies the routing and SNAT decision. Before exiting the packet, traffic shaping and WAN optimization checks mark the final check for a normal packet. However, in the case of tunnel packets, encryption and encapsulation are carried out.