← Docs
Firewalls & Security updated July 3, 2026

Firewall policies: how rule evaluation actually works

Understand how firewalls evaluate rules from top to bottom, ensuring first match wins and why specific ordering is crucial.


Firewall Policies: How Rule Evaluation Actually Works

Firewall policies are evaluated in an ordered list of rules, processed top to bottom. The first rule that matches the packet determines its fate—either allowing or denying it. An implicit deny rule at the end ensures any unmatched packets are blocked.

flowchart TD
  P[Packet] --> R1{Matches rule 1}
  R1 -->|Yes| A1[Apply rule 1 action]
  R1 -->|No| R2{Matches rule 2}
  R2 -->|Yes| A2[Apply rule 2 action]
  R2 -->|No| Dr[Implicit deny drops it]

Anatomy of a Rule

A firewall rule consists of several components:

  • Match Criteria: Source address/zone, destination address/zone, service/port, sometimes user/application/schedule.
  • Action: Allow or Deny.
  • Options: Logging and Network Address Translation (NAT).

Modern firewalls often include advanced features like application signatures and identity-based rules.

Example Rule Structure

# Allow Bob to access the database server
src: 192.168.1.10, dst: 10.0.0.5, port: 3306, action: allow

# Deny all other traffic to the database server
src: any, dst: 10.0.0.5, port: 3306, action: deny

Ordering Discipline

To ensure rules work as intended:

  • Specific Rules Above General Ones: More specific rules should be placed before more general ones.
  • Deny-with-Log Before Broad Allows: Place deny-with-log rules before broad allow rules to catch unexpected traffic.
  • Implicit Deny Rule: An implicit deny rule at the end ensures any unmatched packets are blocked.

Example Order

# Allow Bob to access the database server
src: 192.168.1.10, dst: 10.0.0.5, port: 3306, action: allow

# Deny all other traffic to the database server
src: any, dst: 10.0.0.5, port: 3306, action: deny

# Log and drop unmatched packets (optional but recommended for visibility)
src: any, dst: any, action: deny, log: true

Statefulness

Modern firewalls track connections to manage stateful traffic:

  • Outbound Traffic: Rules allowing outbound traffic automatically permit return traffic.
  • Home Networks: Home networks often work with zero inbound allows because replies are tracked in the state table.

Stateless vs. Stateful ACLs

Stateless ACLs require explicit rules for both directions, while stateful firewalls handle returns implicitly.

Zones and Abstraction

Real firewalls use zones to group interfaces:

  • WAN: External network.
  • LAN: Internal network.
  • DMZ: Demilitarized zone.
  • IoT: Internet of Things devices.

Policies are written between these zones for clarity:

  • LAN→WAN Allow Web Traffic

    src: LAN, dst: WAN, port: 80, action: allow
    
  • IOT→LAN Deny All Traffic

    src: IOT, dst: LAN, action: deny
    

Debugging Blocked/Allowed Packets

To troubleshoot why a packet is blocked or allowed:

  1. Find the Matching Rule: Use policy lookup tools.
  2. Check Rule Order Above It.
  3. Inspect State Table: Ensure stateful connections are being tracked correctly.
  4. NAT Considerations: Check if NAT is affecting the packet before it reaches the policy.
  5. Review Logs: Examine logs from the final deny-log rule for visibility.

By following these principles, you can effectively manage and debug your firewall policies to ensure they meet your security needs.

Was this useful?

This doc is maintained by the humans who run BreadLab. Spotted an error? Tell us — we fix docs, not just typos.