What a firewall is and how it works

A firewall is a security control that mediates traffic between networks (for example, between the internet and your local network) by allowing, blocking, or restricting connections according to a policy. In practice, a firewall evaluates requests using criteria such as source and destination addresses, ports, transport protocol (TCP/UDP/ICMP), and—depending on the type—connection state or even higher-layer details like application commands.

Most firewall decisions follow a consistent pattern:

  1. Traffic arrives at a defined point (perimeter, host, or segment).
  2. The firewall inspects it.
  3. Rules determine whether the traffic is permitted, denied, or limited.
  4. Matching events are typically logged for troubleshooting and auditing.

Because firewalls must make decisions at wire speed, they rely on what they can see in the traffic at that layer. That is why limitations—especially around encryption—are central to understanding firewalls.

Packet-filtering firewalls

Packet-filtering firewalls (often called stateless firewalls) make decisions per packet using fixed rules. A rule might say: allow TCP traffic from certain source IP ranges to a specific destination port; deny everything else.

How it works (conceptually):

  • Each packet is checked against the rule set.
  • The firewall does not keep track of whether the packet belongs to an established session.
  • Replies may require explicit rules depending on how your policy is designed.

What they’re good at:

  • Simple, predictable control over basic network access.
  • Reducing exposure by blocking unnecessary ports and protocols.

Typical limitations:

  • Weakness against attacks that require understanding the “conversation” rather than a single packet.
  • Greater chance of over-permitting or over-blocking when rules get complex.
  • Limited visibility into application intent.

Stateful firewalls

Stateful firewalls maintain context about connections. Instead of evaluating packets in isolation, they track session state (for example, whether a TCP handshake has occurred) and use that context to make smarter decisions.

How it works (conceptually):

  • The firewall identifies traffic flows.
  • When a connection is established, it allows related packets that match the established state.
  • Unsolicited inbound packets are more likely to be blocked unless policy explicitly allows them.

What they’re good at:

  • Better handling of legitimate bidirectional traffic without requiring as many static “reply” rules.
  • More robust baseline protection for many common network behaviors.

Typical limitations:

  • State tracking is not the same as understanding application semantics.
  • If the firewall is configured too broadly, “allowed” traffic can include malicious sessions.
  • Stateful inspection can still struggle with threats carried inside encrypted or protocol-mimicking payloads.

Application-layer (proxy and deep inspection) firewalls

Application-layer firewalls (sometimes implemented as application proxies or as devices that inspect higher-layer protocols) evaluate traffic at the level of application protocols and, depending on the design, may interpret commands or requests.

How it works (conceptually):

  • The firewall examines protocol elements beyond IP/port and often beyond basic connection state.
  • It may validate that the request conforms to expected application behavior.
  • Some designs terminate and re-establish connections (proxy-like behavior), which can change what the endpoints perceive.

What they’re good at:

  • Detecting misuse patterns that cannot be inferred from ports alone.
  • Applying application-specific policies (for example, allowing only certain request types).

Typical limitations:

  • Coverage varies by protocol and configuration.
  • Encryption can reduce what the firewall can interpret; if the firewall cannot see the application details, its ability to enforce application rules may be limited.
  • Higher processing cost can affect latency or require careful capacity planning (exact impacts depend on implementation and environment, which can vary).

Differences that matter when comparing firewall types

A clear way to compare firewall types is by the decision boundary: what the firewall looks at to make an allow/deny choice.

  • Packet-filtering: decision based on packet headers (lowest-layer view).
  • Stateful: decision based on session/connection context plus packet headers.
  • Application-layer: decision based on application protocol behavior and request/command structure (highest-layer view).

From this perspective, deeper inspection generally provides more context, which can improve precision. However, deeper inspection also depends more strongly on what is observable (for example, encrypted vs unencrypted payloads) and on correct configuration.

Practical checks you can do to verify firewall coverage

Even without vendor-specific features, you can build confidence in your firewall posture by validating alignment between expected traffic and actual enforcement.

  1. Map intended flows to firewall policy. List which systems should accept inbound connections and which should initiate outbound connections, including the required ports and protocols.

  2. Check for rule intent, not just presence. Confirm that rules express the minimum required scope (specific addresses and ports rather than broad “allow” statements), and that the default action (implicit or explicit) is appropriate.

  3. Review logs for matched vs blocked traffic. Look for patterns such as repeated denies to services that should be reachable, or unexpected allows to services you did not plan to expose.

  4. Test with a controlled method. Use approved test traffic to confirm that permitted flows work and that prohibited flows fail. If the firewall relies on application-layer checks, validate with representative application requests, not only a basic connectivity test.

  5. Account for encryption visibility limits. If an application is encrypted end-to-end, understand what your firewall can realistically inspect. A firewall that only checks ports may appear to “allow” traffic even if it cannot assess the content.

  6. Look for gaps created by misconfiguration and complexity. Most real-world issues come from outdated rules, overlapping allow/deny rules, incorrect network ranges, or forgetting to update policy after infrastructure changes.

Firewalls are only one part of a broader defense approach. A few limitations are especially important:

  • Encryption reduces inspectability. Firewalls that need payload or application details may have less enforcement power when traffic is encrypted and the firewall cannot access the relevant content.
  • Policy complexity increases mistakes. As rule sets grow, it becomes easier to create unintended access.
  • Not all threats are purely “network-based.” Malware execution, stolen credentials, and application-layer logic flaws may require controls beyond firewall rules.

Related concepts that often get discussed alongside firewall types include:

  • Network segmentation: limiting how far traffic can move if a system is compromised.
  • Intrusion detection/prevention systems (IDS/IPS): focusing more on detecting malicious patterns than simply enforcing allow/deny rules.
  • Zero trust approaches: emphasizing continuous verification rather than relying solely on network location.

None of these replace firewall fundamentals; they address different parts of the problem.

Bottom line

Use the firewall type as a proxy for what decisions you can confidently enforce. Packet-filtering controls basic access, stateful inspection improves connection legitimacy handling, and application-layer inspection can be more precise but depends on what the firewall can observe.