How Firewalls Actually Block Traffic

Most people think firewalls are like digital bouncers—just standing at the door, checking IDs, and turning away the wrong crowd. That’s not entirely wrong, but it’s also not the full picture. The reality is a bit more interesting, and once you understand how firewalls actually work, you’ll see why they’re not just simple "yes" or "no" gates.

Let’s start with what a firewall actually does. At its core, a firewall is a piece of software or hardware that sits between your network and the outside world, inspecting every packet of data that tries to pass through. A packet is just a small chunk of data—think of it like a postcard with an address on it. The firewall reads that address and decides whether to let the postcard through, tear it up, or send it back.

But here’s the thing: firewalls don’t just look at where the packet is going. They also look at where it came from, what protocol it’s using, and even the contents inside. That’s what makes them powerful.

Packet Filtering: The Old-School Way

The simplest type of firewall is called a packet filter. It works by checking the header of each packet—the part that contains the source IP address, destination IP address, port number, and protocol type (TCP, UDP, etc.). If the packet matches a rule in the firewall’s configuration, it’s passed through. If not, it’s dropped.

For example, suppose you have a web server at IP 192.168.1.10 running on port 80 (HTTP). You can tell your firewall: "Allow incoming traffic to 192.168.1.10 on port 80, but block everything else." That’s a rule. When a packet arrives addressed to that IP and port, it gets through. If someone tries to connect to port 22 (SSH) on the same server, the firewall drops it.

Packet filtering is fast and efficient, but it’s also dumb in a way—it doesn’t understand context. It just looks at the address and port, like a mailroom clerk who only checks the zip code. If a hacker sends a malicious packet that looks like it’s from a trusted IP, the packet filter might let it through without question.

Stateful Inspection: Keeping Track of Conversations

Here’s where things get smarter. Most modern firewalls use stateful inspection. Instead of looking at each packet in isolation, they track the state of the connection. Think of it like this: when you start a conversation with someone, the firewall remembers that you initiated it. If a reply comes back from that person, the firewall knows it’s part of the same conversation and lets it through.

This is important because it prevents outsiders from pretending to be part of your conversations. For example, if you browse a website, your computer sends a request to that site’s server. The firewall notes: "This connection was initiated from inside the network." When the server responds, the firewall sees the reply and matches it to the stored state—it knows it’s legitimate. But if an external computer tries to send a packet that looks like a reply to a connection that never existed, the firewall drops it.

This is why stateful firewalls are called "stateful"—they maintain a state table of all active connections. It’s like a receptionist who keeps a list of who’s currently visiting, so they know who’s allowed to come back in.

Application Layer Inspection: Reading the Fine Print

Packet filters and stateful firewalls are good, but they don’t look at the actual data inside the packet. That’s where application layer inspection (also called deep packet inspection) comes in. This type of firewall looks beyond the header and examines the payload—the actual content of the packet.

For example, let’s say you have a web server. A packet filter would just check that the packet is going to port 80. But an application layer firewall can read the HTTP request inside and block specific content—like a SQL injection attack that tries to sneak malicious code into a database query. It might also block requests to certain URLs or prevent file uploads.

This is the kind of firewall that stops many modern cyberattacks. But it also comes with a cost—deep packet inspection is slower because it has to read and analyze every packet’s contents.

Real-World Example: How PythonSkillset Uses Firewalls

At PythonSkillset, we host tutorials and guides that get thousands of visitors a day. Security is no joke. We use a stateful firewall at the network edge to block all incoming connections except on ports 80 (HTTP) and 443 (HTTPS). That’s the first line of defense.

But that’s not enough. We also run an application-layer firewall on the web server itself, watching for attacks like cross-site scripting or command injection. For instance, if someone tries to send a request like curl http://pythonskillset.com/?cmd=rm%20-rf%20/, the application firewall catches it and rejects the request before any damage can happen.

And here’s a neat trick: we also log blocked traffic for analysis. Sometimes we see repeated attempts from the same IP address—like someone scanning for open ports. We can then add that IP to a temporary blocklist, preventing any further traffic from that address.

The Bottom Line

Firewalls don’t just block traffic randomly. They apply rules based on addresses, ports, connection states, and sometimes even the content inside the packets. The more layers of inspection you use, the better the protection—but you trade off speed for security.

If you’re building your own network, PythonSkillset recommends starting with a simple stateful firewall and then adding application layer protections where you need them most. Don’t try to block everything—just block what shouldn’t be there. That’s the real art of firewall management.