Firewall Types for CISSP 2026 — Packet Filtering vs Stateful vs Proxy vs NGFW

Overview

The Four Firewall Generations

Each generation adds intelligence. CISSP tests your ability to match a scenario to the right firewall type and identify what each can and cannot do.

🔴

Packet Filtering

Examines each packet in isolation against ACL rules based on IP addresses and port numbers. Fast, simple — but completely stateless. No memory of past packets.

Layer 3/4 Stateless ACL rules 1st Gen

🔵

Stateful Inspection

Tracks the state of every active TCP/UDP connection in a state table. Return traffic is only allowed for connections the firewall knows are established. Detects SYN floods and port scans.

Layer 3/4 State table Connection tracking 2nd Gen

🟢

Application Proxy

Terminates the client connection, fully inspects application-layer content, then creates a new connection to the server. Hides the internal network. Understands HTTP, FTP, DNS, SMTP.

Layer 7 Break-and-inspect Hides internals 2.5 Gen

🟣

Next-Gen Firewall (NGFW)

Integrates stateful inspection with application identification, user identity, integrated IPS, SSL/TLS inspection, URL filtering, and threat intelligence. Sees applications regardless of port.

All layers App-ID IPS + SSL 3rd Gen

⚡ What Each Firewall Can and Cannot Inspect

Packet Filter

🔴

IP + Port only

No payload, no state

Stateful

🔵

IP + Port + State

No payload content

App Proxy

🟢

Full L7 payload

Protocol-aware

NGFW

🟣

App + User + Threat

Decrypts SSL too

💡

Generation = Inspection Depth: Each firewall generation adds a layer of intelligence. Packet filtering sees headers. Stateful adds connection memory. Proxy adds content understanding. NGFW adds application identity, user context, and threat intelligence — all at wire speed. On the CISSP exam, identify the minimum firewall type needed to satisfy each scenario requirement.

How It Works

Inside Each Firewall Generation

Select a firewall type to see its OSI layer position, inspection logic, and key CISSP concepts.

🔴 Packet Filter

🔵 Stateful

🟢 App Proxy

🟣 NGFW

🔴 Packet Filtering — Stateless ACL Inspection

Every packet is examined in complete isolation. The firewall has no memory of previous packets. It simply checks each packet's header fields against a set of rules (Access Control List) and either permits or denies it.

🌐 Inbound Packet

Header only

→

🔴 Check ACL Rules

Src IP · Dst IP · Src Port · Dst Port · Protocol

→

✅ PERMIT

Rule matched — allow

❌ DENY

No match → implicit deny

Example ACL Rule Table (processed top-to-bottom, first match wins):

#	Action	Protocol	Src IP	Dst IP	Dst Port
1	PERMIT	TCP	ANY	10.0.0.5	443
2	PERMIT	TCP	ANY	10.0.0.5	80
3	DENY	ICMP	ANY	10.0.0.0/24	—
4	DENY	ANY	ANY	ANY	ANY

Rule 4 is the implicit deny — all traffic not explicitly permitted is dropped. This is a firewall best practice.

OSI Layers — Where Packet Filtering Operates

7 Application Layer

❌ Not inspected

6 Presentation Layer

❌ Not inspected

5 Session Layer

❌ Not inspected

4 Transport Layer

✅ Src/Dst Port · TCP/UDP

3 Network Layer

✅ Src/Dst IP · Protocol

2 Data Link Layer

Passed through

Key Weaknesses

IP Spoofing

Cannot verify that source IP address is genuine — attackers can forge headers

Port Abuse

Can't verify traffic on port 443 is actually HTTPS — any traffic can use port 443

No State Tracking

Return traffic must be explicitly permitted — or dangerous blanket rules are needed

Fragmentation Attacks

Attackers can split malicious payloads across fragments; filter only sees first fragment's headers

🔵 Stateful Inspection — Connection State Tracking

A stateful firewall maintains a state table — a record of every active TCP/UDP session. When a packet arrives, it's checked against both the ACL rules AND the state table. Return traffic is automatically permitted for established connections — no blanket inbound rules needed.

📦 Incoming Packet

→

🔵 Check State Table
Is this part of an established session?

→

✅ In table → ALLOW

Established session

📋 Not in table → Check ACL

New connection attempt

Connection State Table (Live Example)

Src IP	Dst IP	Src Port	Dst Port	Protocol	State
192.168.1.10	203.0.113.5	54231	443	TCP	ESTABLISHED
192.168.1.25	8.8.8.8	45123	53	UDP	ESTABLISHED
192.168.1.33	172.16.0.1	62100	80	TCP	SYN_SENT
❌ BLOCKED: Unsolicited ACK from 198.51.100.9 → 192.168.1.10:443 — No matching entry in state table

The last row shows stateful inspection catching an unsolicited ACK — a common technique used to map open ports. Packet filtering would not detect this.

OSI Layers — Where Stateful Inspection Operates

7 Application Layer

❌ Payload not inspected

6 Presentation

5 Session Layer

✅ Connection state tracking

4 Transport Layer

✅ TCP flags · SYN/ACK/FIN

3 Network Layer

✅ Src/Dst IP

2 Data Link

⚠️

SYN Flood Vulnerability: A stateful firewall's state table has finite memory. An attacker sending thousands of SYN packets (but never completing the 3-way handshake) fills the state table with SYN_SENT entries until it overflows — a SYN flood / DoS attack. Mitigations: SYN cookies, connection rate limiting.

🟢 Application Proxy — Break, Inspect, Re-connect

The proxy acts as a full intermediary. The client connects to the proxy, not the server. The proxy inspects the entire application payload, then (if clean) creates a brand-new connection to the destination. The server only ever sees the proxy's IP — never the client's.

1

Client → Proxy: Client initiates TCP connection to the proxy (not the destination server)

↓

2

Proxy receives full request: Terminates the connection. Reads the complete HTTP/FTP/SMTP message at Layer 7

↓

3

Deep content inspection: Validates protocol compliance, scans for malware, checks URLs, inspects headers and payload

↓

4

Proxy → Server: If clean, proxy creates a NEW TCP connection to the destination server using the proxy's own IP — client identity is hidden

OSI Layers + Two Types of Proxy

7 Application Layer

✅ Full content inspection

5 Session Layer

✅ Circuit-level gateway variant

4 Transport

✅ Connection termination

3 Network

Transparent

Circuit-Level Gateway (Layer 5)

Validates TCP handshake only. Once session is established, allows data to flow without further inspection. Does NOT inspect payload.

Application-Level Gateway (Layer 7)

Fully understands the application protocol (HTTP, FTP, SMTP). Can filter by URL, strip attachments, enforce protocol compliance.

🎯

CISSP Exam Signals for Proxy: "hides internal IP addresses," "terminates and re-initiates connections," "inspects HTTP content," "strips malicious attachments," "protocol-aware inspection." The proxy firewall is the only type where external servers see the firewall's IP, not the client's — this provides network address privacy.

🟣 Next-Generation Firewall — All Layers, All Context

An NGFW is not a single technology — it's a platform that integrates multiple security functions at wire speed. The defining feature is application identification (App-ID): it can identify Facebook, BitTorrent, or Skype traffic regardless of port number.

🟣

User Identity (LDAP/AD) — Policy based on WHO, not just IP. "Allow Finance team to access Salesforce."

🔐

SSL/TLS Inspection — Decrypts encrypted traffic, inspects for malware/data exfiltration, re-encrypts. Catches threats hiding in HTTPS.

🛡️

Integrated IPS — Detects and blocks exploits, vulnerability probes, malware signatures in-line at the firewall.

📱

Application Identification (App-ID) — Identifies the application using deep packet inspection regardless of port. Blocks BitTorrent on port 443.

🔵

Stateful Inspection — Full connection state tracking (inherited from 2nd gen)

🔴

Packet Filtering — IP/port ACL rules (inherited from 1st gen)

OSI Layers — NGFW Inspects Everything

7 Application Layer

✅ App-ID · URL filter · AV

6 Presentation Layer

✅ SSL/TLS decrypt

5 Session Layer

✅ User identity

4 Transport Layer

✅ State table · IPS

3 Network Layer

✅ IP · ACLs · routing

2 Data Link

✅ MAC · VLAN

🚨

NGFW ≠ WAF: A Web Application Firewall (WAF) is a separate, specialized appliance that protects web applications against OWASP Top 10 attacks (SQL injection, XSS, CSRF). A WAF understands HTTP sessions at a deeper level than even an NGFW. If the scenario says "SQL injection" or "XSS" or "protect a public-facing web application" — the answer is WAF, not NGFW.

Compare

Side-by-Side Comparison

All four firewall types across every CISSP-relevant dimension.

Criteria	🔴 Packet Filter	🔵 Stateful	🟢 App Proxy	🟣 NGFW
OSI Layer(s)Basics	Layer 3 & 4	Layer 3, 4, 5	Layer 5 or 7	Layers 2–7
State TrackingBasics	❌ Stateless — each packet independent	✅ State table tracks all sessions	✅ Full connection termination	✅ Full state + much more
Inspection BasisBasics	IP address, port, protocol flag	IP, port, TCP flags, connection state	Full application payload + headers	Application, user, content, threat intel
PerformanceBasics	⚡ Fastest — minimal overhead	🔶 Fast — slight table overhead	🐢 Slowest — full proxy overhead	🔶 Fast (hardware-accelerated ASICs)
Hides Internal Network?Basics	❌ No	❌ No (unless combined with NAT)	✅ Yes — server sees proxy IP only	🔶 Partial (NAT + App-ID)
Detects SYN FloodsCapabilities	❌ No	✅ Yes — sees half-open state entries	✅ Yes	✅ Yes + rate limiting
Inspects Payload ContentCapabilities	❌ No	❌ No	✅ Yes — full L7 content	✅ Yes — plus threat signatures
Application IdentificationCapabilities	❌ Port-based only	❌ Port-based only	🔶 Protocol-aware (HTTP/FTP/SMTP)	✅ App-ID regardless of port
SSL/TLS InspectionCapabilities	❌ No	❌ No	🔶 With additional config	✅ Built-in SSL decryption
User Identity PoliciesCapabilities	❌ IP-based only	❌ IP-based only	🔶 Some proxy auth	✅ LDAP/AD integration
Integrated IPSCapabilities	❌ No	❌ No	❌ No	✅ Yes — in-line threat prevention
CISSP Exam SignalsExam Signals	"ACL," "stateless," "IP/port rules," "high performance," "simple permit/deny," "router-based"	"state table," "connection tracking," "established sessions," "SYN flood," "return traffic," "dynamic rules"	"hides internal IPs," "terminates connection," "content inspection," "protocol-aware," "forward proxy," "strip attachments"	"application control," "App-ID," "user-based policy," "SSL inspection," "integrated IPS," "application regardless of port"
Common Exam TrapExam Signals	Assuming port 80 means HTTP — packet filter can't verify this	Thinking stateful inspects payload — it does NOT; only headers + state	Confusing circuit-level (L5, no payload) with application-level (L7, full content)	Choosing NGFW for SQL injection protection — use WAF instead for web app attacks

Real Examples

Firewall Types in the Real World

Six scenarios directly modeled on CISSP exam question formats.

🔴 Packet Filtering — Router ACLs at the Network Perimeter ▼

Scenario: An ISP router at a company's internet edge is configured with ACLs to block all inbound traffic except TCP port 443 (HTTPS) to the company's web server at 10.0.0.5, and to deny all ICMP to internal hosts.

Firewall type: Packet Filtering. These are stateless per-packet rules based on IP addresses and port numbers. The router has no concept of whether port 443 traffic is legitimate HTTPS or some other protocol tunneled on port 443.

Key limitation: If an attacker sends a TCP packet with source port 80 (impersonating a web server response), and the ACL permits inbound traffic from port 80, the packet filter cannot distinguish this from legitimate web traffic. This is the classic port-spoofing exploit of packet filters.

CISSP note: Packet filtering is the simplest, fastest, and cheapest firewall. Appropriate for high-throughput environments where performance matters more than deep inspection.

🔵 Stateful Inspection — Enterprise Perimeter Firewall ▼

Scenario: An enterprise deploys a stateful firewall at the perimeter. The outbound policy allows employees to initiate HTTPS connections to the internet. An employee visits bank.com — the firewall records the session in its state table (src IP, dst IP, src port 54231, dst port 443, state: ESTABLISHED). When the web server's response arrives, the firewall matches it to the state table entry and allows it — no explicit inbound rule for port 443 is needed.

Detection of attack: That same hour, an attacker on the internet sends an unsolicited TCP ACK packet to port 443 on the employee's workstation. The stateful firewall checks its state table — no matching entry. The packet is dropped. A packet filter would require a blanket "allow inbound TCP port 443" rule, which could be exploited.

SYN flood scenario: A bot sends 50,000 TCP SYN packets in 10 seconds, never completing the handshake. The state table fills with SYN_SENT entries. Once full, legitimate new connections are dropped — DoS achieved. Mitigation: SYN cookies, connection rate limits.

CISSP note: Stateful inspection is the standard enterprise perimeter firewall. It's the baseline expectation unless a question specifies more advanced features.

🟢 Application Proxy — Corporate Web Proxy & Privacy ▼

Scenario: A financial firm deploys a forward HTTP/HTTPS proxy for all outbound web traffic. All employee browsers are configured to route web requests through the proxy (10.0.0.1:8080).

What the proxy does:
1. Employee requests https://example.com — their browser connects to the proxy, not example.com.
2. Proxy terminates the TLS connection, decrypts the request (SSL inspection), scans the content for malware/data exfiltration, checks the URL against a category block list (gambling, social media).
3. If clean, proxy creates a NEW TLS connection to example.com using its own IP address. example.com logs the proxy IP — never the employee's workstation IP.
4. Response is returned through the same path.

Privacy benefit: External web servers never see internal IP addresses. All traffic appears to originate from the proxy — protecting network topology from reconnaissance.

CISSP note: "Hides internal network addresses" is the unique identifier for proxy firewalls. If the scenario describes a firewall that terminates connections AND prevents internal IPs from being exposed to external hosts — it's a proxy.

🟣 NGFW — Application Control & SSL Inspection ▼

Scenario: A company deploys a Palo Alto Networks NGFW at the perimeter. The security team creates a policy: "Allow the 'Office365-base' application for all users. Block the 'bittorrent' application for all users. Block HTTPS traffic from the 'Finance' AD group to all social media categories."

Why a stateful firewall can't do this: BitTorrent often uses port 443 or dynamic ports. A stateful firewall sees "TCP port 443 — allow" and lets it through. The NGFW's App-ID identifies BitTorrent based on protocol fingerprinting, session behavior, and payload characteristics — regardless of port.

SSL inspection: 85%+ of enterprise traffic is encrypted. Without SSL inspection, an NGFW is effectively blind to most threats. The NGFW acts as a trusted MITM: decrypts using a corporate root CA certificate installed on all endpoints, inspects, re-encrypts. This requires the root CA to be trusted by client machines (pushed via GPO).

CISSP note: If the scenario says "identify application regardless of port," "user-based policy," "block specific application even on port 443," or "inspect encrypted traffic" — the answer is NGFW.

🟣 WAF — Protecting a Web Application (vs NGFW) ▼

Scenario: An e-commerce company hosts a public web application. A penetration tester demonstrates that entering ' OR 1=1 -- in a search field returns all customer records (SQL injection). The company needs protection against SQL injection, XSS, and CSRF attacks.

Why NGFW isn't enough: While an NGFW can inspect HTTP traffic, it doesn't understand the semantic context of web application attacks at the parameter level. A WAF (Web Application Firewall) is purpose-built to parse HTTP requests, understand application parameters, and detect OWASP Top 10 attack patterns.

WAF capabilities: Inspects URL parameters, POST body data, cookies, HTTP headers; blocks SQL injection patterns; stops XSS payloads; enforces valid session tokens (CSRF protection); rate-limits requests; can whitelist valid application inputs.

Deployment: AWS WAF, Cloudflare, Imperva, F5 ASM. Can be deployed as a reverse proxy in front of the web server.

CISSP note: WAF = web application attacks (SQLi, XSS, CSRF). NGFW = network-level application control and threat prevention. These are different tools for different problems — both may be deployed together.

🔵 DMZ Architecture — Screened Subnet with Two Firewalls ▼

The screened subnet (DMZ) architecture is one of the most commonly tested network security designs on the CISSP exam.

Architecture:
Internet → [Outer Firewall] → DMZ (public servers) → [Inner Firewall] → Internal Network

Outer firewall rules: Permit HTTP/HTTPS from internet to web servers in DMZ. Block all direct internet access to the internal network.

Inner firewall rules: Permit only specific database queries from DMZ web servers to the internal database. Block all other DMZ-to-internal traffic.

Why two firewalls? If an attacker compromises the web server in the DMZ, they face a second firewall before reaching the internal network. Defense in depth.

Bastion host: A hardened server in the DMZ (or at the perimeter) deliberately exposed to the internet. Must have all unnecessary services removed, minimal attack surface, heavily monitored.

CISSP note: "DMZ" = publicly accessible servers isolated from the internal network. "Screened subnet" = the specific two-firewall architecture. "Bastion host" = hardened server exposed to untrusted network.

Practice Quiz

10 CISSP-Style Firewall Questions

Scenario-based items modeled on real exam format. Select the minimum firewall type that satisfies each requirement.

Question 1 of 10

QUESTION 1

Score: 0/0

0

/ 10

Decision Tool

Which Firewall Type?

Answer 3 questions to identify the right firewall generation for any CISSP scenario.

Does the scenario require inspecting application-layer content — the actual payload, application identity, or user identity?

Think: Is it enough to control traffic by IP/port? Or does the policy need to understand WHAT the traffic is (HTTP content, application type, who the user is)?

🟣

Yes — need application/content/user awareness

Inspect payloads, identify specific apps, enforce user-based policies, decrypt SSL

➡️

No — IP/port control is sufficient

Traffic control based on IP addresses, ports, and protocols only

Does the scenario need to hide internal IP addresses from external servers, or fully terminate and re-inspect each connection at Layer 7?

Think: Must external servers never see internal client IPs? Is deep protocol compliance inspection (HTTP content, attachment scanning) required?

🟢

Yes — full break-and-inspect / hide internal IPs

Proxy terminates connection, inspects content, creates new connection; server sees proxy IP

🟣

No — need App-ID, IPS, SSL inspection, or user policies

NGFW capabilities: identify apps on any port, integrated IPS, user-based rules

Does the scenario require tracking connection state — only allowing return traffic for established sessions, or detecting half-open connections?

Think: Does the firewall need to know if a packet is part of an existing conversation? Or is simple IP/port rule matching sufficient?

🔵

Yes — track connection state, only allow established sessions

State table, dynamic return traffic rules, SYN flood detection

🔴

No — simple IP/port ACL rules are sufficient

High speed, simple permit/deny, router-based ACLs

Memory Hooks

Mnemonics & Exam Memory Tricks

Click each card to flip and reveal the mnemonic.

🔴

Packet Filter

Click to reveal

"Check the
Label — Ignore
the Contents"

Packet filter reads the outside of the envelope (IP + port) but never opens it. Fast. Dumb. Stateless.

🔵

Stateful

Click to reveal

"I Remember
Every
Conversation"

Stateful = has memory. Tracks every TCP session. Return traffic auto-allowed for established connections. No payload.

🟢

App Proxy

Click to reveal

"I Read
Your Mail
Then Forward It"

Proxy opens the envelope, reads everything, rewrites the return address as its own, then re-sends. Server never sees you.

🟣

NGFW

Click to reveal

"I Know
What App,
Who, and Why"

NGFW knows the application (App-ID), the user (AD integration), and the threat (IPS). Even decrypts SSL to look inside.

🎯 The Ultimate Firewall Exam Cheat Sheet

If the question says…	Think…	Answer
"ACL," "permit/deny by IP and port," "stateless," "router-based," "no state tracking," "fastest option"	🔴 Header-only. No memory. No context.	Packet Filter
"state table," "established connections only," "SYN flood," "return traffic," "dynamic rules," "tracks sessions"	🔵 Has memory of every conversation.	Stateful Inspection
"hides internal IPs," "terminates connection," "content inspection," "forward proxy," "HTTP content filtering," "strips attachments"	🟢 Opens the envelope. Re-sends in its own name.	Application Proxy
"App-ID," "application regardless of port," "user-based policy," "SSL inspection," "integrated IPS," "identify BitTorrent on 443"	🟣 Knows app, user, and threat in one box.	NGFW
"SQL injection," "XSS," "CSRF," "OWASP Top 10," "protect web application," "application-layer web attacks"	Web app attacks need a specialist.	WAF (not NGFW)
"DMZ," "web servers between two firewalls," "screened subnet," "public servers isolated from internal"	Defense in depth architecture.	Screened Subnet / DMZ

🚨

The Three Most-Failed Firewall Questions:

1. Stateful ≠ Content Inspection. Stateful inspection tracks connection state (TCP flags, sequence numbers) but does NOT inspect the application payload. If a question asks about inspecting HTTP body content or blocking malware in traffic — stateful is not enough; you need a proxy or NGFW.

2. Proxy hides IPs; NGFW does not (by default). The defining characteristic of a proxy is that external servers only see the proxy's IP. If a question emphasizes "internal network addresses are never exposed to external hosts" — it's a proxy, not an NGFW.

3. NGFW ≠ WAF for web application attacks. SQL injection, XSS, and CSRF are web application layer attacks that require a WAF. An NGFW can identify applications and block threats at the network level, but is not purpose-built for parameter-level web app attack detection.

Packet Filtering · Stateful Inspection
Application Proxy · Next-Gen Firewall

The Four Firewall Generations

⚡ What Each Firewall Can and Cannot Inspect

Inside Each Firewall Generation

🔴 Packet Filtering — Stateless ACL Inspection

Example ACL Rule Table (processed top-to-bottom, first match wins):

OSI Layers — Where Packet Filtering Operates

Key Weaknesses

🔵 Stateful Inspection — Connection State Tracking

Connection State Table (Live Example)

OSI Layers — Where Stateful Inspection Operates

🟢 Application Proxy — Break, Inspect, Re-connect

OSI Layers + Two Types of Proxy

🟣 Next-Generation Firewall — All Layers, All Context

OSI Layers — NGFW Inspects Everything

Side-by-Side Comparison

Firewall Types in the Real World

10 CISSP-Style Firewall Questions

Which Firewall Type?

Mnemonics & Exam Memory Tricks

🎯 The Ultimate Firewall Exam Cheat Sheet

Ready to Pass the CISSP?
Get Everything You Need in One Place.

Packet Filtering · Stateful Inspection Application Proxy · Next-Gen Firewall

The Four Firewall Generations

⚡ What Each Firewall Can and Cannot Inspect

Inside Each Firewall Generation

🔴 Packet Filtering — Stateless ACL Inspection

Example ACL Rule Table (processed top-to-bottom, first match wins):

OSI Layers — Where Packet Filtering Operates

Key Weaknesses

🔵 Stateful Inspection — Connection State Tracking

Connection State Table (Live Example)

OSI Layers — Where Stateful Inspection Operates

🟢 Application Proxy — Break, Inspect, Re-connect

OSI Layers + Two Types of Proxy

🟣 Next-Generation Firewall — All Layers, All Context

OSI Layers — NGFW Inspects Everything

Side-by-Side Comparison

Firewall Types in the Real World

10 CISSP-Style Firewall Questions

Which Firewall Type?

Mnemonics & Exam Memory Tricks

🎯 The Ultimate Firewall Exam Cheat Sheet

Ready to Pass the CISSP?Get Everything You Need in One Place.

Packet Filtering · Stateful Inspection
Application Proxy · Next-Gen Firewall

Ready to Pass the CISSP?
Get Everything You Need in One Place.