Security processors and hardware acceleration

A real-life situation

Harbourline Freight, a fictional company, replaces an old firewall with a mid-range FortiGate. File transfers between the data centre VLANs run at close to line rate and CPU load stays low. Then the team enables proxy-based antivirus on the same policy, and throughput drops while CPU load climbs. Nothing is broken. The sessions moved from the network processor back to the CPU, because proxy inspection needs the CPU to see every byte. Knowing what each processor does lets you predict changes like this before you make them, and size the firewall for the features you actually enable.

Why a firewall needs more than a CPU

A general-purpose CPU can do anything, but it does each thing one instruction at a time, and every packet costs it interrupts, memory copies and lookups. At tens of gigabits per second that adds up to millions of packets per second, most of which need the same simple work: match a session, rewrite an address, forward. An ASIC does that one job in dedicated circuits, in parallel, with predictable latency and far less power per packet.

The trade-off is flexibility. An ASIC only does what it was designed for, so a FortiGate splits the work: the CPU handles decisions and anything complex, and the ASICs handle repetitive work that can be described in advance. This split is why FortiGate data sheets show very different numbers for plain firewalling and for full inspection.

The processors in a FortiGate

The generation names are examples only. Fortinet releases new generations over time, and the exact functions differ between them, including "lite" variants used in smaller models. The per-model mapping is in the model's data sheet and in the FortiOS hardware acceleration guide.

Network processor (NP)

The NP sits in the data path between the front-panel ports and the CPU. Once the CPU has accepted a session, the NP can hold a copy of it and forward every later packet itself: it matches the session, applies the stored source or destination NAT, updates counters, and sends the packet out of the egress port. Depending on the generation, the NP can also:

• encrypt and decrypt IPsec traffic for offloaded tunnels;
• handle IPv6 and some multicast traffic;
• apply traffic shaping and some DoS anomaly protection;
• forward traffic between VDOMs over accelerated inter-VDOM links.

Treat this list as "may", not "does": check your NP generation before relying on any item.

Content processor (CP)

The CP isn't in the forwarding path. The CPU passes it work and gets results back. It accelerates the expensive maths of encryption (for example during SSL/TLS deep inspection or IPsec that the NP doesn't handle) and the pattern matching that IPS and related engines use to compare traffic with thousands of signatures. Which engines use the CP, and how, varies by CP generation and FortiOS release, so read it as "the CPU does inspection faster with a CP", not "the CP does inspection".

System-on-a-chip (SoC)

Desktop models put the CPU and cut-down NP and CP functions on a single chip. That keeps the price and power use low while still offloading common sessions. The limits (fewer offload features, lower total capacity) are part of why small and large models differ so much in inspected throughput, even when their plain firewall figures look close.

How a session gets offloaded

Learn more: Understanding FortiGate Firewall Packet Flow

Conditions for offload

• Both ports on the NP. The ingress and egress interfaces must be connected to the NP (or, on larger models with several NPs, to NPs that can exchange traffic). Some management or dedicated ports bypass the NP entirely.
• No CPU-only processing. Proxy-based inspection, explicit proxy, many session helpers (protocol ALGs) and traffic to or from the FortiGate itself keep the session on the CPU.
• Offload allowed. The policy setting auto-asic-offload is enabled by default; if it is disabled, matching sessions stay on the CPU.
• Supported by this generation. Some features (for example certain shaping or inspection combinations) can be offloaded on one NP generation and not on another.

What about flow-based inspection?

Flow-based inspection needs the IPS engine to see the session's data, so a fully offloaded session can't be inspected. FortiOS handles this differently by generation: some models can still send inspected traffic from the NP to the IPS engine more efficiently than through the normal kernel path, and some can use the CP for the pattern matching. Fortinet documents these as acceleration modes (you may meet the names nTurbo and IPSA). What is offloaded in each case is model specific; the hardware acceleration guide for your release is the reference.

IPsec offload

On models whose NP supports it, the CPU negotiates the tunnel (IKE is CPU work), then hands the security associations to the NP, which encrypts and decrypts ESP packets for offloaded sessions. The phase 1 setting npu-offload controls this and is enabled by default where supported. The tunnel's cipher matters: each NP generation supports a specific set of algorithms, and a tunnel using an unsupported one is encrypted by the CPU (with CP help where available).

What stays on the CPU

• The first packets of every session, and every policy decision.
• Proxy-based inspection, explicit web proxy and SSL/TLS handshakes (CP-assisted).
• Traffic to and from the FortiGate: management, routing protocols, IKE, FortiGuard updates, logging.
• Sessions on ports that aren't connected to an NP, and everything on a FortiGate VM.

Configuration

Offload works without configuration. The settings you meet are the ones that turn it off, usually for troubleshooting or to work around a specific limitation. Per policy:

Per IPsec tunnel:

These are CLI settings; the policy page in the GUI doesn't normally show them. Leave both enabled unless you have a specific reason.

Verification: is this session offloaded?

Find the session with a filter, then read the NPU fields:

FGT1 # diagnose sys session list
session info: proto=6 proto_state=01 duration=94 expire=3597 timeout=3600 ...
...
misc=0 policy_id=3 ...
npu_state=0x...
npu info: flag=0x81/0x81, offload=8/8, ips_offload=0/0, ...
...
total session 1

To see which ports belong to which NP, on models with that NP:

The diagnose npu tree has many more commands (statistics, session counts, drop counters), but they differ between NP generations. Use the hardware acceleration guide for your model rather than copying commands from another platform.

How offload changes troubleshooting

• Sniffer and debug flow see only the start. They run on the CPU. After the session is offloaded, later packets don't reach them.
• Counters can lag. Session and interface byte counts for offloaded traffic are updated from the NP, so some views show them later or less precisely.
• Policy changes can apply later. An offloaded session keeps forwarding until it is re-evaluated or times out.
• CPU load looks low. Low CPU doesn't mean little traffic. The NP may be carrying most of it.

What can go wrong

Throughput drops after enabling a security feature

A policy that ran at high speed slows down and CPU load rises after you enable proxy-based antivirus, or deep inspection on a large flow.

Traffic between two ports is slower than between others

Transfers between a particular pair of ports are much slower, and CPU load rises during them.

An IPsec tunnel is slow and loads the CPU

Site-to-site throughput is far below the data sheet's IPsec figure.

The sniffer shows only the first packets of a working connection

Users report no problem, but your capture stops after the handshake.

Design guidance for enterprises

• Plan port use with the NP mapping in mind: put high-volume flows on NP-connected ports, and on multi-NP models spread heavy links across NPs as the hardware guide recommends.
• Choose IPsec proposals that your NP can offload when site-to-site throughput matters.
• Separate bulk trusted traffic from user traffic in policies, so the bulk traffic can stay offloaded while users are inspected.
• Size by the inspected figures for the features you enable, not by the firewall figure, which assumes full offload.
• For VMs, size vCPUs and choose high-performance virtual NICs supported by your hypervisor; there is no NP to help.

Best practices

• Leave auto-asic-offload and npu-offload enabled unless you have a documented reason.
• Know which of your important sessions are offloaded before relying on sniffer or debug output.
• Use the model's hardware acceleration guide, not commands or limits from a different model.
• Watch CPU load after enabling any feature that can pull traffic back to the CPU.

Key takeaways

Check yourself

Next: use these limits to choose a model in Sizing a FortiGate.