Firewall Types Explained: Packet Filtering, Stateful, NGFW, and WAF (2026)

A packet filtering firewall examines each network packet in isolation and compares it against an access control list (ACL). Each packet is checked against rules that specify: source IP address, destination IP address, source port, destination port, and protocol (TCP or UDP). If the packet matches a permit rule, it is forwarded. If it matches a deny rule or no rule at all, it is dropped. The decision is made independently for every single packet — there is no memory of previous packets and no concept of a "connection."

Packet filtering is implemented in router ACLs (Cisco IOS access-list commands), Linux iptables with simple rules, and basic firewall configurations. It is still widely used today — not as a primary firewall, but as a fast first-pass filter at network boundaries before traffic reaches more sophisticated controls.

• Can stop: Port scans reaching closed ports, connections from blocked IP ranges, traffic on prohibited protocols, traffic to services not in the ACL, basic IP spoofing (with anti-spoofing rules)
• Cannot stop: Attacks through permitted ports (SQL injection on port 443 looks identical to legitimate HTTPS), IP spoofing where the source IP is in a permitted range, fragmented packet attacks (some packets bypass ACLs if fragmented correctly), return traffic attacks (no state tracking — cannot verify a packet is a legitimate TCP response)

Stateful inspection was introduced by Check Point in 1994 and solved the fundamental problem with packet filtering: a stateless firewall has no way to know whether an inbound packet is a legitimate response to an outbound request or an unsolicited attack packet. A stateful firewall maintains a connection state table — a record of every active TCP/UDP session crossing the firewall.

When a client initiates a TCP connection (SYN), the firewall records the session: source IP, source port, destination IP, destination port, and the current TCP state (SYN_SENT). When the server responds (SYN-ACK), the firewall verifies this packet matches an existing entry in the state table and updates it to ESTABLISHED. Return traffic matching an established session is automatically permitted without requiring a separate inbound rule. This eliminates the need for open inbound rules for return traffic — a major security improvement over packet filtering.

• SYN flood protection — SYN packets without corresponding ACKs are tracked. Flood conditions trigger SYN cookies or rate limiting. Packet filtering has no concept of "too many SYNs."
• No inbound rules for return traffic — stateful firewalls only need outbound permit rules. Return traffic is automatically permitted if it matches an established session. Packet filtering requires explicit inbound rules for return traffic, creating security gaps.
• TCP sequence number validation — verifies that TCP sequence numbers in packets are within the expected range for the session, blocking TCP session hijacking attempts.
• FTP, SIP helper inspection — protocols that open dynamic ports for data transfer (FTP's data channel, SIP's media streams) are handled by application layer helpers that track the negotiated secondary ports and permit only those — without opening broad port ranges.
• Still blind to payload — stateful inspection operates at Layer 3–4. It knows a valid TCP session on port 443 is established. It cannot see that the HTTPS payload contains a SQL injection string.

Linux iptables / nftables (with connection tracking module), Windows Firewall with Advanced Security, Cisco ASA (now Secure Firewall), older Check Point appliances, pfSense / OPNsense (open-source), and Fortinet FortiGate at basic configuration. Most modern deployments use these as the base layer of an NGFW rather than as standalone stateful firewalls.

The term "next-generation firewall" was defined by Gartner in 2009 to describe a new class of firewall that moved beyond stateful inspection to include deep packet inspection (DPI), application awareness, and integrated intrusion prevention. By 2026, NGFW is simply what most people mean when they say "firewall" — the stateful-only firewall is increasingly a legacy device.

Where stateful inspection tracks TCP sessions at Layer 4, DPI reads the actual content of each packet's payload. It reassembles TCP streams and inspects the application-layer data — the HTTP headers, the DNS query payload, the TLS certificate, the SMTP commands. This is what enables all the higher-level capabilities below.

Traditional firewalls identify applications by port. An NGFW identifies the actual application regardless of port — Skype on port 80, BitTorrent on port 443, Dropbox disguised as HTTPS. Palo Alto Networks' App-ID is the most advanced implementation: it identifies over 3,500 applications by analysing protocol behaviour, payload signatures, and traffic patterns. This prevents the common bypass technique of using non-standard ports or tunnelling traffic over common protocols.

Traditional firewalls operate on IP addresses. An NGFW integrates with Active Directory, LDAP, or RADIUS to map IP addresses to user accounts. Policies can be written as: "Allow Marketing group to access social media on port 443, deny Engineering group on the same policy." When a user's IP changes (DHCP reassignment), the policy follows the user identity, not the IP.

NGFWs include an intrusion detection and prevention system inline — inspecting traffic for known attack signatures (Snort/Suricata rule sets), protocol anomalies, and behavioural patterns. When an attack signature matches, the IPS can block the traffic in real time (prevention mode) or alert and log it (detection mode). This consolidates two previously separate appliances (firewall + IPS) into one.

Over 90% of internet traffic is now encrypted with TLS. A firewall that cannot decrypt TLS is largely blind to modern attacks — malware C2 communications, data exfiltration, and HTTPS-delivered exploits all look like generic encrypted traffic. NGFW TLS inspection works by acting as a trusted man-in-the-middle: the firewall terminates the TLS connection from the client, inspects the decrypted payload, then re-encrypts and forwards to the destination. This requires deploying the NGFW's CA certificate as a trusted CA on all managed endpoints.

• Can stop: Known malware signatures in traffic, C2 communications (known domains and IPs), application policy violations, URL category-based threats, TLS-encrypted attacks (with SSL inspection enabled), protocol anomaly-based attacks, many zero-day exploits via signature updates, DNS tunnelling, data exfiltration via known channels
• Cannot stop: Unknown zero-day attacks not yet in signature databases, attacks within encrypted traffic if TLS inspection is not deployed, SQL injection and XSS in web application payloads (these require a WAF that understands web application context, not just network traffic), insider threats using legitimate application sessions, advanced threats that evade signature detection

A Web Application Firewall operates exclusively at Layer 7 — it understands HTTP and HTTPS at a semantic level, not just as network traffic. While an NGFW sees "encrypted traffic on port 443," a WAF sees the actual HTTP request: the URI, query parameters, request headers, cookies, and POST body. This context is what enables it to detect web application attacks that are completely invisible to network-layer firewalls.

A WAF sits in front of web applications as a reverse proxy. All requests destined for the application are first received by the WAF, inspected, and either forwarded to the application (if clean) or blocked (if malicious). The application server only sees traffic that the WAF has cleared.

• SQL injection detection — pattern matching and heuristic analysis of SQL metacharacters, keywords (UNION SELECT, OR 1=1, DROP TABLE), and injection patterns in query parameters, POST bodies, headers, and cookies
• XSS detection — detection of JavaScript injection patterns, HTML event handlers, and script tags in user input before they reach the application
• CSRF protection — validation of anti-CSRF tokens, origin headers, and referrer validation for state-changing requests
• Rate limiting and DDoS mitigation — request rate limits per IP, per session, per endpoint; challenge-response (CAPTCHA) for suspicious traffic patterns
• Bot detection — distinguishing legitimate browsers and crawlers from automated attack tools through behavioural analysis, JavaScript challenges, and browser fingerprinting
• API security — schema validation (does this API request match the OpenAPI specification?), rate limiting per API key, detection of parameter pollution and mass assignment attacks
• OWASP Core Rule Set (CRS) — the open-source rule set used by ModSecurity and many commercial WAFs, covering all OWASP Top 10 vulnerability categories

The most common misunderstanding: organisations deploy an NGFW and believe their web applications are protected from SQLi and XSS. They are not. An NGFW sees HTTPS traffic on port 443 — with TLS inspection enabled, it can inspect the payload for known malware signatures and C2 patterns, but it has no semantic understanding of SQL syntax or HTML/JavaScript context. A WAF specifically understands web application attack patterns because it is designed to parse and understand HTTP at the application layer. Both are required for a complete web security posture — NGFW for network-layer control, WAF for application-layer protection.