SonicWall Gen 7 & SonicOS 7 — RFDPI and How Traffic Is Processed

① The Gen 7 lineup & SonicOS 7 — one OS, four form factors

The single most important idea: SonicWall Gen 7 is not four different products — it is one operating system and one inspection engine in four sizes. Every Gen 7 box runs SonicOS 7.x, and every box scans traffic with the same RFDPI engine. Skills transfer across the whole line.

The four families

The form factors are: the TZ series (desktop boxes for SMB and branch offices, often with integrated wireless), the NSa series (rack-mount mid-size to enterprise campus, higher port density and throughput), the NSsp series (large enterprise and data center — very high multi-gigabit throughput, redundant power, expansion modules and clustering / high availability), and the NSv series (a fully virtual firewall for public cloud and private VM estates — same SonicOS 7, same RFDPI, no hardware). All are multi-core platforms.

② RFDPI — what reassembly-free, single-pass inspection means

RFDPI stands for Reassembly-Free Deep Packet Inspection, and it is the heart of every SonicWall. It is a single-pass, stream-based scanner: it inspects every byte of every packet across all ports and all protocols — but without proxying the connection or buffering the whole file first.

Why 'reassembly-free' matters

Classic proxy or buffer-and-scan designs must hold the file before they can check it — that adds latency, eats memory, and caps how many connections the box can handle. RFDPI scans the data as it flows, so no reassembly = low latency + full scanning at scale. Just as important, it runs the security engines together in one pass, not as separate sequential scans: Gateway AV, Anti-Spyware, IPS, Application Control and DPI-SSL all look at the same stream once.

③ How a packet flows — and where the cloud takes over

Follow a packet. It arrives at an interface, the firewall applies access policy, and the content is streamed into RFDPI. In that single pass the engine runs Gateway AV (malware), Anti-Spyware, IPS (exploits and attacks), and Application Control (what app/whom). If the traffic is encrypted, DPI-SSL decrypts it first — including TLS 1.3 — so the rest of the engines can actually see inside. A clean stream gets a verdict and is forwarded; a malicious one is dropped and logged.

RFDPI is fast but it is the inline brain. For files it cannot judge, SonicWall hands off to the cloud: the Capture ATP sandbox, whose patented RTDMI (Real-Time Deep Memory Inspection) engine forces malware to reveal its weaponry in memory — catching fileless, encrypted and zero-day attacks that signatures miss. RTDMI is the cloud counterpart to on-box RFDPI (covered in depth in a later lesson).

④ Managing & sizing it — SonicOS 7 objects and honest throughput

You drive all of this from SonicOS 7. The modern dashboard is organised into five sections — Device, Network, Object, Policy and Monitor — and it uses an object-based policy model: you define reusable objects (addresses, services, zones) once in Object, then reference them in Policy rules, so the same definition drives consistent rules everywhere.

Size by the honest number

The classic mistake is sizing on the big raw firewall throughput figure, which is measured with inspection off. Real traffic needs the engines on, so size by threat-prevention / DPI throughput with all engines (and DPI-SSL) enabled, plus your expected connection count. Pick the family (TZ → NSa → NSsp → NSv) that meets that inspected number with headroom, and use NSsp clustering when one box is not enough.