A firewall decides which traffic is allowed to pass. That has been true since the late 1980s, and everything since has been an argument about how much context the decision should include.
Understanding that progression makes modern products much easier to evaluate, because each generation was solving a specific failure of the one before.
Generation One: Packet Filters
The original firewalls looked at each packet in isolation: source address, destination address, protocol, port. Allow or deny.
This is cheap and fast and it has an obvious hole. It cannot tell the difference between a packet that is part of a connection you initiated and a packet that arrived on its own claiming to be a reply.
You can still write this style of rule with iptables and nftables on Linux, which is exactly why the mentorship teaches them in Week 2. Writing rules by hand makes every commercial product afterwards legible.
Generation Two: Stateful Inspection
Stateful firewalls track connections. They remember that you initiated an outbound session and allow the return traffic for that session specifically, then close the entry when the connection ends.
That closed the obvious hole and is still the foundation of everything since. The remaining limitation is that a stateful firewall reasons about ports, and port numbers stopped being a reliable indication of what is actually happening.
Once nearly everything moved to port 443, allowing web traffic meant allowing almost anything.
Generation Three: Next Generation
The next generation firewall adds identity and application awareness. It identifies the application by inspecting traffic rather than trusting the port, so a rule can say allow this specific application rather than allow port 443.
It integrates with your directory so a rule can reference a user or a group rather than an IP address, which is much closer to how policy is actually meant to read.
It includes intrusion prevention, malware inspection, URL filtering, and threat intelligence feeds in the same device.
And it can decrypt TLS in order to see any of that, which is the tradeoff at the center of modern firewalling.
TLS Inspection, Honestly
Almost all traffic is encrypted. Without decryption, a next generation firewall is largely back to being a stateful firewall with reputation lookups.
Decryption means the firewall terminates the session, inspects it, and re-encrypts it. That requires deploying your own certificate authority to every managed device, and it means the firewall now holds plaintext for everything it inspects.
It also has real limits. Certificate pinning breaks it, some applications refuse to work through it, and there are legal and privacy obligations around inspecting employee traffic that vary by jurisdiction.
Most organizations decrypt selectively, excluding categories such as banking and health, and accept the gap.
The Products
Palo Alto Networks, Fortinet FortiGate, Check Point, Cisco Secure Firewall, and Sophos are the names you will meet most often.
On the open source side, OPNsense and pfSense are both capable and both excellent for a home lab. Snort and Suricata provide the intrusion detection and prevention piece.
Web Application Firewalls Are a Different Thing
A WAF sits in front of a specific web application and inspects HTTP requests for attack patterns such as SQL injection and cross site scripting. A network firewall protects a network. A WAF protects an application.
A WAF is a useful layer and it is not a substitute for fixing the application. It is a filter in front of the bug, and filters can be bypassed. See the OWASP Top 10.
Common options include Cloudflare, AWS WAF, and the open source ModSecurity with the OWASP Core Rule Set.
Where the Real Failures Are
Almost no firewall failure is a failure of the technology. They are failures of the ruleset.
Rules accumulate for years. Someone opens something temporarily for a project, the project ends, the rule stays. Nobody knows who owns it or whether it is still needed, so nobody removes it.
Overly broad rules are the norm: any to any on a range of ports, added under time pressure. Shadowed rules sit below a broader rule and never match. Rules reference objects that no longer exist.
The result is a policy nobody fully understands, which is functionally a policy nobody controls.
Keeping a Ruleset Healthy
Every rule needs an owner, a business reason, and a review date recorded when it is created. Adding that discipline later is nearly impossible.
Review regularly, using hit counters to find rules that have matched nothing in a year. Those are either unnecessary or protecting something that is gone.
Order matters for both performance and correctness. Specific rules above general ones, and an explicit deny at the end that is logged.
Log denies. A firewall that silently drops traffic is discarding one of the better sources of detection data. Send it to the SIEM.
And patch the firewall itself with urgency. Internet facing security appliances have been a recurring source of exploited vulnerabilities, and the CISA Known Exploited Vulnerabilities catalog is full of them.
Learn This at HackRange
Writing iptables and nftables rules by hand in Week 2 is the reason students can read a commercial firewall policy later without guessing.