What Is a Firewall? How Network Traffic Filtering Actually Works

A firewall is a system that monitors network traffic and decides whether to allow or block it based on a set of rules. It sits between a trusted network (your machine, your server, your private subnet) and an untrusted one (usually the wider internet), enforcing a policy about what is allowed to pass.

Despite the dramatic name, a firewall is fundamentally a filter. It does not encrypt your data, scan for every kind of malware, or guarantee security on its own. It controls which connections are permitted, and that single job is one of the most effective controls in network security.

What a firewall actually does

Every packet crossing a network carries metadata: a source IP address, a destination IP address, a protocol (TCP, UDP, ICMP), and port numbers. A firewall reads this metadata and compares it against an ordered list of rules. Each rule says something like "allow inbound TCP traffic to port 443" or "block all inbound traffic from this address range."

Rules are evaluated in order, and the first match usually wins. Most firewalls end with a default-deny rule: anything not explicitly allowed is dropped. This "deny by default, allow by exception" posture is the cornerstone of sound firewall design, because it fails closed rather than open.

Because ports identify services, understanding them is central to firewall work. Port 443 is HTTPS, port 22 is SSH, port 53 is DNS. The transport protocol matters too, since TCP and UDP behave differently and a firewall treats them as separate rules. If you are reasoning about which addresses a rule covers, our Subnet Calculator helps translate CIDR notation like 10.0.0.0/8 into the actual range of hosts it includes.

Packet filtering vs. stateful inspection

The earliest firewalls were stateless packet filters. They examined each packet in isolation and made a decision with no memory of previous packets. This is fast but limited: the firewall cannot tell whether an incoming packet is a reply to a request your machine actually made, or an unsolicited probe from an attacker.

Stateful inspection solved this. A stateful firewall maintains a connection table that tracks the state of active sessions. When your server opens an outbound TCP connection, the firewall records it. Return packets matching that connection are allowed automatically, while packets that do not correspond to any known session are dropped. This is why you can usually make outbound requests freely while inbound connections stay tightly restricted, and it understands the TCP handshake well enough to know an established connection from a forged one.

Understanding the difference between connection-oriented and connectionless protocols helps here; our explainer on TCP vs. UDP covers why stateful tracking is straightforward for TCP and trickier for UDP.

Types of firewalls

Network firewalls

These protect an entire network segment and typically run on a dedicated appliance, a router, or a cloud gateway. They filter traffic between subnets and between your network and the internet, and they are the layer that enforces perimeter policy for an organization.

Host-based firewalls

These run as software on an individual machine. Examples include iptables and its successor nftables on Linux, and Windows Defender Firewall. They protect a single host regardless of what the surrounding network allows, which is valuable in shared or cloud environments.

Application-layer firewalls

A traditional firewall inspects packet headers up through the transport layer. An application firewall, including the Web Application Firewall (WAF), inspects the actual content of requests. A WAF can read HTTP requests and block patterns associated with SQL injection or cross-site scripting. This operates at a different layer than a network firewall and is complementary rather than a replacement.

Where firewalls fit in real deployments

On a cloud server, you almost always have at least two firewall layers. The cloud provider exposes security groups or network ACLs that filter traffic before it reaches your instance, and the instance itself runs a host firewall. Configuring both with a default-deny stance and opening only the ports a service needs is standard practice.

A typical web server allows inbound traffic on ports 80 and 443 and SSH on port 22 (often restricted to known administrator IPs), and denies everything else inbound. Outbound traffic is frequently left more permissive so the server can reach package repositories, DNS resolvers, and APIs. If a service depends on name resolution, remember that blocking outbound port 53 will break it; see what DNS is for why that lookup step is unavoidable.

Firewalls are not application-level access control

A common mistake is treating a firewall as a substitute for authentication or encryption. A firewall decides whether a connection is allowed, not who the user is or whether the data is private. Transport security is handled by TLS, as covered in what HTTPS is, and browser-side request policies like the same-origin restrictions in CORS and the directives in a Content Security Policy live entirely above the firewall. A firewall cannot enforce them and they cannot replace a firewall.

Common pitfalls

• Allowing too much. Opening 0.0.0.0/0 on a database or admin port exposes it to the entire internet. Restrict source addresses to exactly what is needed.
• Forgetting rule order. Because the first matching rule wins, a broad allow rule placed before a narrow deny rule will silently override it.
• Confusing inbound and outbound. Blocking inbound traffic does nothing to stop a compromised host from making outbound connections. Egress filtering is a separate, often-neglected control.
• Assuming a firewall replaces patching. If a service is exposed and vulnerable, allowing the connection at all is enough for an attacker. The firewall only limits which services are reachable.
• Locking yourself out. Applying a default-deny rule before adding the SSH allow rule, especially on a remote machine, can cut off your own access. Order the allow rules first and test before committing.

Why firewalls still matter

The internet is full of automated traffic that scans every reachable address for open ports and known weaknesses. A correctly configured firewall reduces your exposed surface to the minimum a service requires, so the vast majority of that traffic never reaches a process that could be exploited. It is not a complete security strategy, but it is a foundational layer that every network-connected system should have, working alongside encryption, authentication, and timely patching to form a defense in depth.

Frequently Asked Questions