Introduction to NGFW & NGFW Architecture

NGFW vs Traditional Firewall

A next-generation firewall (NGFW) goes far beyond what traditional stateful firewalls could do. While a traditional firewall makes allow/deny decisions based on ports and protocols, an NGFW understands applications, users, and content — enabling much more precise security policy.

Capability	Traditional Firewall	NGFW (NGFW)
Traffic identification	Port and protocol	Application signature (Application ID)
User awareness	IP address only	User and group via user identification
SSL traffic	Passes through opaque	Can decrypt and inspect
Threat prevention	None built-in	IPS, AV, cloud sandbox integrated
URL control	None	75+ categories, URL database
File inspection	None	File type blocking, cloud sandbox sandbox

NGFW Architecture — Three Planes

NGFW separates its processing into three distinct planes. This separation ensures that heavy data-plane work does not degrade management responsiveness, and management activity does not impact packet forwarding performance.

Data Plane

The data plane is responsible for all packet processing. It handles packet forwarding, Application ID classification, user identification lookup, security policy evaluation, NAT, threat scanning, SSL decryption, and QoS marking. On hardware platforms, the data plane runs on dedicated network processing and security processing hardware.

Packet buffering and forwarding at line rate
Application ID processing via single-pass parallel processing (SP3)
Security policy lookup and action enforcement
Threat prevention scanning (AV, IPS, URL, cloud sandbox)
SSL decryption engine
NAT engine

Control Plane

The control plane manages the routing table, manages protocols like OSPF and BGP, handles HA synchronization, manages policy compilation, and provides the CLI and API management interface. It runs on a general- purpose CPU separate from the data plane.

Management Plane

The management plane provides the dedicated out-of-band management interface (MGT port). Administrative access via the web GUI, SSH CLI, and central management all use this plane. Importantly, management traffic never traverses the data plane, so even if the data plane is busy or congested, you can always reach the device for management.

Management Interface Best Practice

Always connect the MGT interface to a dedicated management network or out-of-band network. Never expose the management interface to the internet. Restrict access by source IP using permitted-IP lists on the MGT interface profile.

Single-Pass Parallel Processing (SP3)

Traditional security architectures chain multiple scanning engines sequentially — the packet goes through the firewall engine, then the IPS engine, then the AV engine, each processing it independently. This adds latency at every hop and increases resource consumption.

NGFW uses Single-Pass Parallel Processing (SP3) to scan the packet once across all engines simultaneously. Application ID, user identification, content inspection, and threat prevention all operate on the same single pass through the packet. This delivers higher throughput with lower latency.

→

Single pass means the packet is parsed once — network processing, security processing, and content scanning happen concurrently, not sequentially.

→

Parallel processing means dedicated hardware engines handle specific functions simultaneously — Application ID runs at the same time as AV scanning runs at the same time as URL categorization.

Core NGFW Differentiators

Application ID — Application Identification

Application ID identifies the application running on a connection regardless of port, protocol, or encryption. It uses four mechanisms: application signatures, application protocol decoding, heuristics, and behavioral analysis. This enables policies like "allow Salesforce but block Dropbox" even though both use TCP 443.

user identification — User Identification

User identification maps IP addresses to actual usernames and group memberships via integration with Active Directory, LDAP, or other identity sources. Policies can be written for groups like "allow Finance team to access SAP" rather than managing individual IP-based rules.

content inspection — Content Inspection

Content inspection is the umbrella for all content-based inspection: URL filtering, threat prevention (IPS, AV), cloud sandbox integration, file blocking, and data filtering. It operates on the actual content of the connection after Application ID has identified the application.

Device-ID

Device-ID extends policy granularity to IoT and unmanaged devices that cannot run an agent. It identifies device type, vendor, and OS version from network behavior and applies appropriate policy.

Interface Types

Interface Type	Layer	Description	Use Case
Layer 3	L3	Routes traffic; has IP address assigned	Standard routed deployment
Layer 2	L2	Switches traffic within a VLAN; no IP routing	Transparent deployment in existing L2 domain
Virtual Wire	L1	Bump-in-the-wire; no MAC or IP; transparent to network	Inline IPS without network change
Tap Mode	Passive	Receives mirrored traffic only; no inline blocking	Passive monitoring / visibility
HA Interface	N/A	Dedicated to HA heartbeat and state synchronization	High Availability only
Loopback	L3	Virtual interface with IP; never goes down	Management VIPs, BGP router-ID
Tunnel	L3	Virtual interface for VPN tunnel endpoints	IPSec and SSL VPN VPN

Security Zones

Every interface on a NGFW firewall must belong to a security zone. Zones define the security boundary for policy enforcement:

Traffic between different zones — always inspected and subject to security policy
Traffic within the same zone (intrazone) — permitted by default, but can be restricted with an intrazone rule
Traffic from/to an interface with no zone — blocked by default (implicit zone drop)

Zone names are meaningful to security engineers — common zone names include trust (internal), untrust (internet), dmz, vpn-tunnel, and management. The zone name appears in security policy rules, logs, and reports.

NGFW CLI Basics

cli

# Show system information (model, software version, serial)
show system info

# Show all interfaces and their status
show interface all

# Show routing table
show routing route

# Show active sessions
show session all

# Show session details for a specific session ID
show session id <id>

# Show security policy hits
show running security-policy

# Debug data plane (use with caution in production)
debug dataplane packet-diag set filter match source 10.1.1.1

# Clear the packet filter
debug dataplane packet-diag clear filter

# Show HA state
show high-availability state

# Show system resources (CPU, memory)
show system resources

central management Centralized Management

Central management is a platform for managing many firewalls from one place. Instead of logging into each firewall individually, administrators manage all devices from a single central management console.

Device Groups — organize firewalls into logical groups; push shared policies and objects to the group
Templates — push consistent network configuration (interfaces, zones, routing) to multiple devices
Managed Firewalls — override specific settings per device when needed
Log Aggregation — central management collects logs from all managed firewalls for centralized search and reporting
Role-Based Access Control — define granular admin roles across the central management hierarchy

central management vs Local Management

In a central management-managed deployment, local changes on individual firewalls can be overridden by the next central management push. It is a best practice to make all changes in central management and disable local admin access or make it read-only to prevent configuration drift.

Next Module