What a firewall is (and what it isn’t)

A firewall is a security control that examines network traffic and allows or blocks communication based on rules. In everyday terms: it sits at a network boundary (or between internal segments) and decides which packets and connections are permitted.

A firewall is not the same as encryption or a VPN. Encryption protects the contents of traffic, while a firewall focuses on whether traffic should be allowed to flow. Firewalls also don’t automatically “make you safe”; their effectiveness depends on correct policy design, correct placement, and correct configuration.

How firewalls work: the main building blocks

Most firewalls make decisions in two steps: matching and action.

  1. Matching: The firewall looks at attributes such as source/destination IP addresses, ports, transport protocol (for example TCP or UDP), and sometimes higher-layer information.
  2. Action: Based on the rules, it allows, blocks, or sometimes logs traffic.

Firewalls commonly handle traffic in a few broad ways:

  • Stateless packet filtering: Decisions are made per packet using a rule match. If packets don’t carry enough context for a “session,” the firewall may require explicit rules for both directions.
  • Stateful inspection: The firewall tracks connection state (a “session” view) so that replies that belong to an allowed connection are treated as expected, without you writing separate rules for every direction.
  • Application-aware inspection (policy with deeper context): Some firewalls can understand certain application behaviors or protocols and enforce more specific rules. This can increase precision but also increases complexity and the chance of false positives/negatives.

In practice, you typically combine these ideas: address/port rules for breadth, state for session correctness, and optional deeper inspection for higher-layer control.

Key limitations and common blind spots

A firewall’s power is also its constraint: it can only decide based on what it can see and what your rules allow.

Common limitations include:

  • Rule mistakes and overly permissive policies: A single “allow all” (or broad allow) rule can undermine the intended protection.
  • Default-deny vs. default-allow: The default behavior matters. If the firewall defaults to allow, you must be careful to block what you mean to restrict.
  • Traffic that isn’t well-represented by simple rules: Some modern protocols use dynamic ports, encrypted application payloads, or behavior that doesn’t map cleanly to classic port-based filtering.
  • Assumptions about visibility: If the firewall is not placed where traffic flows (or if traffic bypasses it through alternative paths), the firewall cannot enforce policy.
  • Internal threats and lateral movement: A firewall placed only at the perimeter may not stop threats moving inside the network; internal segmentation and host controls often matter too.

Also, “more inspection” is not always better. Deep inspection can reduce false assumptions, but it can also add operational overhead and require careful tuning.

Practical checks to validate that a firewall is doing what you expect

Because policies can be subtle, you should validate behavior rather than rely only on configuration files.

Use a small set of checks that directly test the assumptions behind your rules:

  1. Confirm which ports/services are actually exposed.

    • From a test machine on the relevant network, verify whether the expected ports are reachable.
    • If a service is listening on a port you didn’t intend, firewall rules may be irrelevant if the service becomes reachable through an allowed path.

  2. Check allow/deny behavior with known test cases.

    • Test an expected-allowed connection and a clearly expected-blocked connection.
    • Keep the test scope narrow: one protocol (TCP or UDP), one destination, one service.

  3. Look for evidence the firewall is applying the policy.

    • Many firewalls can log rule matches or events. Verify that traffic generates the expected log entries (or counters) rather than silent success.
    • If you see the traffic succeed without logs where you expected filtering decisions, review placement and policy order.

  4. Account for state and session direction.

    • In stateful setups, reply traffic may be automatically permitted as part of an established session.
    • Validate both directions by testing a full connection, not just a single packet.

  5. Be cautious with encrypted application traffic expectations.

    • If the firewall’s decision depends on payload visibility, encrypted payloads may limit what it can distinguish. In that case, your controls may rely more heavily on IPs/ports and metadata.

Clear criteria for “working”

A firewall is behaving as expected when:

  • Allowed traffic reaches the intended service under the intended conditions.
  • Blocked traffic fails in a repeatable way.
  • Observed behavior aligns with your rule intent (including stateful/session behavior).
  • The firewall is positioned so that the tested traffic actually passes through it.

If any of these criteria fail, the most likely root causes are misplacement, incorrect rule order, incorrect addresses/ports/protocols, or an assumption mismatch between “what the rule is about” and “what the protocol actually does.”