What a firewall is

A firewall is a security control that filters network traffic according to a set of rules. Instead of blindly letting data move between networks (for example, your device and the internet), it decides what traffic is allowed to pass and what is blocked.

Firewalls are typically deployed at a boundary: on an individual device, on a home or office router, or inside a network for segmenting access to particular services. The core idea is simple: network traffic becomes safer when you restrict it to what you actually need.

How a firewall works (the typical rule flow)

Most firewall decisions are based on attributes of the traffic, such as:

  • Source and destination IP addresses (or address ranges)
  • Transport protocol (commonly TCP or UDP)
  • Port numbers (e.g., 53 for DNS, 443 for HTTPS)
  • Connection direction (inbound vs. outbound)
  • Additional context, depending on the firewall type

A firewall evaluates these attributes against its rule set. If a rule matches and permits the traffic, it is allowed; otherwise it is blocked.

Stateless vs. stateful behavior

A useful distinction is whether the firewall is stateful.

  • Stateless filtering typically treats each packet independently. It may allow traffic to a port but not understand whether it belongs to an established session.
  • Stateful filtering tracks ongoing connections. If a connection was allowed to start, related packets can be permitted automatically, while unsolicited traffic is blocked.

In practice, stateful behavior often reduces the chance that legitimate return traffic gets blocked, but it still depends on correct rules and the firewall’s ability to recognize connection states.

Rule ordering and default posture

Firewalls commonly apply rules in a particular order and use a default action for anything that doesn’t match. Two limitations follow from that:

  1. A broad “allow” rule placed before a specific “block” rule can override the intent.
  2. A restrictive default block can break services if required traffic is not explicitly allowed.

Differences and limits: what firewalls can’t solve

A firewall is helpful, but it is not a complete security solution. Key limitations include:

Limited to network-level signals

Firewalls primarily reason about network metadata (addresses, ports, protocols, and sometimes connection state). They do not inherently understand application logic, user intent, or whether the data being carried is malicious.

Misconfiguration and rule complexity

Even a well-designed firewall can fail due to mistakes:

  • Allowing too much (e.g., broad inbound access)
  • Missing a required service rule (e.g., forgetting DNS or a specific port range)
  • Incorrect rule direction (inbound vs. outbound)
  • Confusing expectations about rule order

Encrypted traffic still needs correct permissions

Modern connections are often encrypted. A firewall may still decide based on destination/port and connection metadata without inspecting message contents. That means it can block traffic correctly, but it may not be able to “see” whether the encrypted payload is harmful.

It doesn’t replace patching or endpoint protection

If a service on a system has a vulnerability, allowing traffic to that service may still expose risk. Firewalls cannot fully compensate for unpatched software, weak authentication, or application flaws.

Because the exact capabilities vary by product and configuration, it’s safest to treat firewall coverage as “restricting network paths” rather than “making the system safe.”

Practical checks you can run

To confirm what your firewall is doing, use verification steps that focus on observable outcomes.

1) Check logs (if available)

Look for entries that indicate:

  • Allowed vs. blocked decisions
  • Which rule matched (or at least the reason category)
  • Source/destination and port/protocol

If you see unexpected blocks for a legitimate service, you may need to add a narrow allow rule. If you see unexpected allows, you likely need to tighten the rules.

2) Validate with targeted connectivity tests

Test only the specific traffic you care about:

  • Try reaching a service on the expected port from the appropriate direction (inbound or outbound).
  • Confirm failure when the firewall should block, and success when it should allow.

Avoid broad “everything works” validation. Instead, verify the particular ports/protocols your use case requires.

3) Review your rule logic

Focus on three checks:

  • Default action: Is everything not explicitly allowed blocked?
  • Ordering: Do broad rules unintentionally precede specific ones?
  • Direction: Does the rule cover the correct traffic direction?

This is often where “it doesn’t match my expectation” problems come from.

4) Confirm the boundary you actually control

A firewall only affects traffic paths that pass through it. If you have multiple enforcement points (device firewall, router filtering, server-side controls), rules may interact. Clarify which component is responsible for the traffic you are testing.

Several terms are often confused with firewalls:

  • Network segmentation: restricting where traffic can go inside a network.
  • Access control lists (ACLs): rule-based allowances that resemble firewall filtering.
  • Intrusion detection/prevention (IDS/IPS): detecting patterns of suspicious activity (and possibly blocking) based on deeper inspection.
  • Application-layer controls: security that understands application behavior, usually beyond basic port/protocol filtering.

A firewall is usually one layer in a broader defense approach.

When firewall troubleshooting changes the plan

If connectivity issues persist, the most productive pivot is to separate two questions:

  1. Is the firewall allowing or blocking the expected traffic?
  2. If it’s allowed, is the service actually running and reachable at the application layer?

If the firewall denies the traffic, rule review and log analysis are central. If the firewall allows it but the connection fails, the problem may be the service configuration, routing, DNS, or application-level security.

Because configurations vary widely, treat troubleshooting results as environment-specific and document what you changed before moving to the next check.