🛡️ NGFW from First Principles

This is the “why before the how.” Before touching any code, we build a mental model of what a firewall actually is, how firewalls evolved into today’s Next-Generation Firewall (NGFW), and the vocabulary you need to read the rest of this track. No prior firewall knowledge assumed.

Table of Contents

• The Core Problem: Trust Boundaries
• The Four Generations of Firewalls
• What Makes a Firewall “Next-Generation”?
• The Three Planes
• Anatomy: A Packet’s Journey Through an NGFW
• The Performance Problem (and Why Data Planes Exist)
• Where NGFWs Are Deployed
• Glossary
• Key Takeaways
• What’s Next

The Core Problem: Trust Boundaries

Every network has places where traffic you control meets traffic you don’t. Your office LAN meets the public internet. A telecom subscriber’s data meets the outside world. A cloud VPC meets a partner network.

At that boundary you want to answer one deceptively simple question for every packet:

“Should this be allowed through — and if so, is it safe?”

A firewall is the device that sits on that trust boundary and enforces the answer. It is, at heart, a policy enforcement point: a place where an organization’s rules about what traffic is permitted get applied to real packets in real time.

Analogy. Think of a firewall as security at a building entrance. The earliest version just checks an ID badge (are you on the list?). A better one remembers who’s already inside so they can come and go. The most advanced one also x-rays every bag, recognizes what you’re carrying, and stops known threats — all without making the queue grind to a halt. That progression is the history of firewalls.

The Four Generations of Firewalls

Firewalls got smarter in distinct steps. Each generation kept everything the previous one did and added a deeper layer of understanding.

Each generation adds more context and inspects deeper into the packet — culminating in the NGFW, which folds all of these capabilities into a single engine.

Generation 1 — Packet Filter (stateless)

The first firewalls examined each packet in isolation and matched it against a static list of rules (an Access Control List, or ACL). Rules looked at only the outermost fields:

• Source / destination IP address
• Source / destination port
• Protocol (TCP, UDP, ICMP…)

A rule reads like “allow TCP to 10.0.0.5 port 443; deny everything else.” This works at Layer 3/4 of the OSI model.

The fatal limitation: it has no memory. It cannot tell whether a packet is the start of a brand-new connection or a reply to something you already allowed. To let replies back in, admins had to open wide, permanent holes — which attackers love.

Generation 2 — Stateful Firewall

The breakthrough was connection tracking. A stateful firewall keeps a flow table (also called a state table or session table): a record of every active connection, keyed by the classic 5-tuple (source IP, source port, destination IP, destination port, protocol).

Now the firewall can reason about sessions, not just packets:

• When an inside host opens a connection out, the firewall notes it.
• Return traffic that matches an existing entry is automatically allowed — no permanent hole needed.
• Packets that claim to be “replies” but match no known session are dropped.

This is still Layer 3/4, but it is dramatically safer. Stateful inspection remains the foundation underneath every modern firewall, including the NGFW.

Generation 3 — Application / Proxy Firewalls

Generation 2 knows that a session exists but nothing about what’s inside it. Application-layer firewalls (often built as proxies) went deeper: they terminate the connection, understand a specific application protocol (HTTP, FTP, SMTP…), and inspect the actual payload at Layer 7.

The trade-off: a proxy typically understands one protocol at a time, and terminating/re-originating every connection is heavy and hard to scale. Powerful but narrow.

Generation 4 — Next-Generation Firewall (NGFW)

The NGFW’s insight: fold all of the above — stateful tracking plus deep, multi-protocol payload inspection plus a suite of security services — into one high-performance engine that runs inline at line rate. That is where we are today, and it’s what the rest of this track builds.

The one-line history: filter packets → remember sessions → understand applications → do all three at once, fast, in one box.

What Makes a Firewall “Next-Generation”?

“NGFW” is a capability bar, not a single feature. A firewall earns the label by combining most of the following in one system:

A few of these are worth pinning down early because they show up constantly in the code:

• DPI is the umbrella term for reading beyond L3/L4 headers into the actual bytes of the application data.
• IPS (Intrusion Prevention System) is DPI put to a specific use: comparing traffic to a database of attack signatures and taking action (drop/alert). An IDS only alerts; an IPS sits inline and can block. Open-source engines like Snort and Suricata are the classic examples.
• App-ID answers “what application is this?” independent of port numbers — because modern apps happily run over port 443 to hide.
• NAT and IPsec are not “security inspection” per se, but an NGFW is the natural place to do them because it already sits on the trust boundary and already tracks every flow.

The mental shortcut: a stateful firewall asks “is this session allowed?” An NGFW additionally asks “what is actually inside this session, and is it dangerous?” — and can encrypt, translate, and log it on the way through.

The Three Planes

To understand any firewall (or router, or telco gateway), split it into three planes. This single model is the backbone of the entire architecture and maps directly onto the code you’ll read later.

The management plane decides policy, the control plane sets up sessions, and the data plane moves and inspects every packet at line rate.

1. Data Plane — “moves and inspects the traffic”

The data plane (or forwarding plane / fast path) is where the actual packets flow. It runs on every single packet, so it must be blisteringly fast. Its jobs: parse headers, match policy, track state, run DPI/IPS, do NAT, encrypt for VPN, and forward. If the data plane is slow, the whole firewall is slow.

2. Control Plane — “sets up and tears down sessions”

The control plane handles the signaling and negotiation that configures the data plane but does not touch every packet. Examples: negotiating VPN keys (IKE), learning routes, resolving neighbors (ARP/ND). It runs occasionally and then programs the data plane with the results (routes, security associations, tunnel definitions).

3. Management Plane — “how operators run the box”

The management plane is the human/operator interface: pushing configuration and policy, reading counters and statistics, raising alarms, shipping logs, and presenting dashboards to a Network Management System (NMS). It’s about the firewall rather than in the traffic path.

Why this split matters: it lets each plane scale and fail independently. The control plane can be centralized while the data plane is distributed to the edge; the management plane can go down without dropping a single packet. You’ll see this exact separation echoed in 5G core networks (control plane vs user plane), which is why the 5G/SASE notes rhyme with this section.

Anatomy: A Packet’s Journey Through an NGFW

Let’s follow one packet arriving from the outside, at a conceptual level (later modules trace the actual implementation node-by-node). This is the “happy path” pipeline shown in the data-plane band of the diagram above:

1. Ingress. The packet arrives on a physical port (NIC) and enters the data plane.
2. Parse & classify. Headers are decoded — Ethernet, IP, TCP/UDP — and the 5-tuple is extracted. The packet is now something the firewall can reason about.
3. Policy / ACL match. The packet is matched against the rule set. The outcome is a decision: allow, deny/drop, or allow but inspect further.
4. Stateful tracking. The firewall checks the flow table. Is this a new connection or part of an existing one? New allowed flows get an entry; unexpected packets get dropped.
5. Deep inspection (DPI / IPS / App-ID). If policy flagged the flow for inspection, the payload is examined: identify the application, scan against threat signatures, and take a verdict (pass or block). This is the “next-generation” step.
6. NAT. If the packet is allowed onward, addresses/ports may be translated so the private network can talk to the public one (and replies find their way back).
7. VPN / IPsec (optional). If the destination is reached over an encrypted tunnel, the packet is encrypted using keys the control plane negotiated earlier.
8. Egress. A forwarding (route) lookup picks the outbound interface, and the packet leaves.

Crucially, not every packet takes every step. Policy decides. A trusted, already-inspected flow might skip straight from classification to forwarding; a suspicious one gets the full DPI/IPS treatment; a blocked one is dropped at step 3 or 5. A large part of NGFW engineering is deciding, cheaply and early, how much work each packet deserves — and carrying that decision forward as the packet moves through the pipeline.

The Performance Problem (and Why Data Planes Exist)

Here is the tension that shapes every design choice in this track:

An NGFW must inspect traffic deeply (expensive) while forwarding it at line rate (tens of millions of packets per second, with a budget of only a few nanoseconds per packet).

A general-purpose operating system’s networking stack cannot hit those numbers. The traditional kernel path pays for:

• Interrupts on packet arrival (context switches are costly at these rates).
• Copying packets between kernel and user space.
• Per-packet processing that ignores modern CPU caches and pipelines.

So high-performance firewalls bypass the kernel and run the data plane in user space on dedicated CPU cores. The two technologies that dominate this space — and the two prerequisites for this track — are:

• DPDK (Data Plane Development Kit): a set of libraries and poll-mode drivers that let user-space code talk to the NIC directly, with no interrupts and no copies. The CPU polls for packets in a tight loop instead of waiting to be interrupted.
• VPP (Vector Packet Processing): a user-space forwarding framework (built on DPDK) that processes packets in vectors — batches — through a graph of nodes, instead of one packet at a time. Batching amortizes overhead and keeps code and data hot in CPU cache.

The performance techniques you’ll keep meeting:

If those terms are new, that’s exactly what the DPDK and VPP modules (and the 21 hands-on C exercises) build up. The NGFW is where they all come together into a real product.

Where NGFWs Are Deployed

The same NGFW capabilities show up at very different scales:

• Enterprise perimeter. The classic spot: between the corporate LAN and the internet.
• Data center / cloud edge. Guarding east-west and north-south traffic between segments, VPCs, or tenants.
• Telecom / mobile core. In a mobile network, subscriber traffic exits to the internet through the user-plane gateway (the UPF in 5G, PGW/Gi-LAN in 4G). Inserting an NGFW at that exit lets an operator apply DPI, threat prevention, and URL filtering to subscriber traffic. See Where NGFW fits in 5G/SASE.
• SASE (Secure Access Service Edge). A cloud-delivered model that bundles NGFW-style security with networking and delivers it as a service, close to users at the edge — the modern evolution of “a box at the perimeter.”

The common thread: wherever a trust boundary carries enough traffic that inspection must happen at line rate, you need an NGFW on a fast data plane.

Glossary

Key Takeaways

1. A firewall is a policy enforcement point on a trust boundary — it decides, per packet, allow / deny / inspect.
2. Firewalls evolved in four steps: packet filter → stateful → application/proxy → NGFW. Each kept the prior capabilities and inspected deeper.
3. Stateful inspection (a flow table keyed by the 5-tuple) is the foundation underneath every modern firewall.
4. “Next-generation” means combining DPI, App-ID, IPS, TLS inspection, VPN, NAT, and telemetry into one inline engine.
5. Every such device splits into three planes — data (per-packet), control (session setup), management (operations) — and this split is the backbone of the architecture.
6. A packet’s journey is classify → policy → state → deep inspection → NAT → VPN → forward, but policy decides how much of that each packet gets.
7. Deep inspection at line rate is impossible through the OS kernel, so NGFWs run their data plane in user space on frameworks like DPDK and VPP, using batching, core pinning, and huge pages.
8. NGFWs live wherever a high-traffic trust boundary exists — enterprise edge, data center, the mobile core’s user-plane exit, and SASE.

What’s Next

Now that the vocabulary and the mental model are in place, the next module maps these three planes onto a real NGFW platform — showing how VPP hosts the data plane, how an IPS and an IKE daemon attach to it, and how a management bridge exposes it to operators.