Firewall and ACL Design — Stateless, Stateful, NGFW, and the Rules That Survive 5 Years

Last updated: May 1, 2026

Every enterprise has a firewall. Almost every enterprise also has a 4,000-rule legacy ACL that nobody fully understands, where rule 2,847 is “allow any-any from finance subnet, ticket #FRD-1239 from 2018.” This module is about avoiding that fate. The mental model is simple — match-then-action — but the design discipline is what separates a defensible firewall from a compliance bedtime story.

Stateless vs stateful — the fundamental distinction

A stateless filter (router ACL, AWS Network ACL, classic packet filter) inspects each packet independently. To allow inbound HTTP to a web server, you must explicitly allow inbound TCP/80 AND outbound TCP from ephemeral ports back to the client. Forget the second rule and the response is dropped. A stateful firewall remembers connections — once you allow the inbound SYN, the firewall automatically allows the corresponding return traffic. Stateful firewalls track the four-tuple plus TCP flags and timeouts, building a connection table that is the basis of all modern enterprise firewalls (Palo Alto, Fortinet, Check Point, AWS Security Groups, Linux nftables connection tracking).

When stateless still winsultra-high-throughput edge filtering (DDoS scrubbing, ISP edge), where building per-packet state is too expensive. For everything else, stateful is the default in 2026.

NGFW — Next Generation Firewall, what is actually new

Three things distinguish NGFWs from stateful firewalls:

Rule design — the 5 principles every architect follows

ACL ordering — the trap that catches every new admin

Imagine this Cisco ACL applied inbound on the internet interface: permit tcp any any eq 80; deny tcp any host 10.0.0.5; permit ip any any. The intent: “allow web to anywhere, block everything to the database server, allow everything else.” The reality: rule 1 already permitted TCP/80 to the database server. The deny is partially unreachable. Worse: rule 3 permits everything not blocked by rule 2. The internet has reachability to your database on every port except TCP/80 — opposite of intent.

Lessonwrite deny rules first, in order of decreasing specificity, then permit rules, then implicit deny. Use the firewall’s “rule-hit count” telemetry quarterly to identify rules that never match (suspect) and rules that match constantly (top of the list, performance).

TLS inspection — what you gain and what you break

NGFWs and proxies can decrypt TLS to inspect content, then re-encrypt before delivery. This requires installing the firewall’s root CA on every endpoint (it now signs intermediate certs on the fly for any domain). Benefits: malware C2 over HTTPS becomes visible, DLP can match on content, IPS rules apply to encrypted streams. Pitfalls:

Zone-based design — how NGFWs structure rules at scale

Modern firewalls organise interfaces into zones (Trust, Untrust, DMZ, Server, Mgmt) and rules are written zone-to-zone. A typical rulebase: Trust→Untrust = permitted with NGFW URL filtering and threat prevention; Untrust→Trust = denied except published services; Trust→Server = constrained per role; Server→Untrust = denied except specific egress (NTP, software-update CDNs, DNS); Mgmt→All = SSH/HTTPS to managed devices only, sourced from jump-hosts. The wins: a new server only needs the right zone assignment; rule count grows linearly, not quadratically; auditing is per-zone-pair rather than per-IP.

Cloud equivalentsAWS Security Groups + NACLs, Azure NSGs, GCP VPC firewall rules — all roughly zone-shaped if you use them deliberately.

Audit and change — the hardest part of firewall life

Firewall change is high-blast-radius. Process discipline: every rule change is a ticket; every ticket has a CR-style risk assessment; every change is reviewed by a second engineer; every change has a rollback plan. Tools that pay for themselves: Tufin / AlgoSec / FireMon for rule-base analytics, redundancy detection, and “what would break if I removed this rule” simulation.

For RBI/SEBI/IRDAI regulated entitiesregulators expect an annual firewall review log, evidence of rule-deletion (not just disabling), and segregation between change-makers and reviewers. Most audit findings on firewalls are not “the rule was wrong” but “the change process is undocumented” — process is the audit-defensible artefact, not the perfect rulebase.

Cloud-native firewalls — SGs, NSGs, and the patterns that work

AWS Security Groups, Azure NSGs, GCP firewall rules are stateful, identity-aware (ref by tag, label, or other SG), and apply at the workload level. Best practices:

Common audit findings on firewalls — what your auditor will write up

Egress filtering — the often-overlooked direction

Most enterprises spend significant effort on inbound firewall rules and almost none on outbound. This is exactly backwards from how attackers operate: post-compromise, the malware needs to phone home, exfiltrate, or download tooling — all outbound. Egress allow-list patterns:

Diagrams

Client (10.0.0.5:54321) ──── SYN  ──→  Web (203.0.113.10:443)
          │
          ▼
  Firewall connection table (CREATED):
  ┌──────────────────────────────────────────────────────┐
  │ src=10.0.0.5:54321  dst=203.0.113.10:443  STATE=SYN  │
  │ tcp_state=SYN_SENT  expiry=30s                       │
  └──────────────────────────────────────────────────────┘

Return SYN+ACK matches existing entry → automatically allowed.
No separate "return rule" required.
When connection closes (FIN/RST) or timeout → state torn down.

Rulebase (evaluated top-to-bottom, first match wins):
  1.  permit tcp any any eq 80                  ← matches first
  2.  deny   tcp any host 10.0.0.5  eq 80       ← UNREACHABLE
  3.  permit ip any any                          ← matches all else
  4.  (implicit deny)                            ← never reached

Packet: 1.2.3.4 → 10.0.0.5 port 80
  Rule 1 matches first → PERMIT (intent was to deny!)

Fix: deny rules first, in order of decreasing specificity.
  1.  deny   tcp any host 10.0.0.5  eq 80
  2.  permit tcp any any eq 80
  3.  permit ip any any

References & deeper reading

• NIST SP 800-41 — Firewall guidelines
• CIS Benchmarks (firewall configurations)
• pfSense Documentation
• OPNsense Documentation
• Linux nftables wiki
• AWS Security Group reference

FAQ

NGFW or open-source firewall?

NGFW (Palo Alto, Fortinet, Check Point) wins on app-id, integrated threat intel, and central management at scale; open-source (pfSense, OPNsense, nftables) wins on cost, transparency, and small deployments. Most large Indian enterprises run NGFW at the perimeter and open-source on internal segments. The choice is operational, not technical — pick what your team can keep running, patched, and reviewed.

Should we do TLS inspection?

Yes for managed corporate endpoints, no for personal/BYOD, and excluding banking/health/legal regardless. The DPDP Act 2023 requires that you publish what you inspect; without a clear acceptable-use disclosure you face employee privacy risk. Cloud-delivered SWG (Zscaler, Netskope, Cloudflare Gateway) often makes the operational lift smaller than on-prem NGFW SSL inspection.

How do I find unused rules?

Most firewalls expose hit counters. Disable rules with zero hits for 90 days, alert if anything breaks, then delete after another 30 days. Tufin/AlgoSec automate this, but a quarterly export to CSV and a sort-by-hit-count gets you 80% of the value for free.

What is the right firewall for an AWS VPC?

Security Groups for east-west, NACLs for stateless edge controls, AWS Network Firewall or 3rd-party NGFW (Palo Alto VM-Series, Fortinet) for L7 perimeter and TLS inspection. The mistake is treating NACLs as primary security — they are stateless and limited; SGs are where the actual policy lives.

Are firewall rule reviews mandatory under RBI / SEBI / IRDAI?

Yes. RBI Cyber Security Framework Annex 1 expects periodic firewall rule review with evidence; SEBI CSCRF references annual review; IRDAI ITC Handbook is similar. Auditors will ask for the review log, the changes made, and the segregation of duties between requester, approver, and implementer. Build the audit log into the change process from day one.

Can I autogenerate firewall rules from observed traffic?

Yes — Tufin, AlgoSec, FireMon, and cloud-native CSPMs do this. Capture a baseline of normal traffic, propose allow-rules. Always review proposed rules before applying; baselines capture both the legitimate and the malicious if both are present. Useful for greenfield segmentation; dangerous for greenfield trust.

What is "shadow IT" risk on firewall rules?

Engineering teams discovering they cannot reach a SaaS, then opening “outbound any” rules to fix the immediate problem. Five years later, the rules are forgotten and the perimeter is permeable. Mitigation: outbound default-deny + explicit allow-list of approved SaaS, plus a process for engineering to request additions through a ticket.

⚖️ Legal: Use any techniques described here only on networks you own or have explicit written authorisation to test. In India, unauthorised access is punishable under IT Act §66 (up to 3 years + fine). Pair offensive testing with a signed Statement of Work / Rules of Engagement; pair forensic activity with §65B-aligned chain of custody.