Updated 10 hours ago
A firewall is a bouncer with a guest list. Every packet that wants to cross the network boundary has to pass the bouncer, who checks it against the list and makes a call: you're in, or you're out.
The entire system runs on one principle: first match wins. Understanding that principle unlocks everything else.
Every Packet Gets Checked
Network traffic arrives as discrete packets—small chunks of data with headers that identify where they came from, where they're going, which ports they're using, and what protocol they speak (TCP, UDP, ICMP).
The firewall intercepts each packet before it reaches its destination. It extracts the identifying information from the headers: source IP, destination IP, source port, destination port, protocol, connection flags.
This happens fast. Modern firewalls inspect millions of packets per second. The packet waits briefly while the firewall decides its fate, then either continues to its destination or vanishes.
First Match Wins
The firewall holds a ruleset—an ordered list of conditions and actions. When a packet arrives, the firewall starts at rule 1 and works down:
Does this packet match rule 1? No → check rule 2.
Does this packet match rule 2? No → check rule 3.
Does this packet match rule 3? Yes → take the action specified (allow or deny).
Stop checking.
The firewall stops looking once it finds a match. This "first match wins" behavior means rule order isn't a preference—it's the logic itself.
Consider this ruleset:
A packet from 192.168.1.50 heading to port 80 matches rule 1. Allowed. Done.
A packet from 192.168.1.50 heading to port 3306 (MySQL) skips rules 1 and 2, hits rule 3. Denied.
A packet from 10.0.0.5 heading to port 22 skips rules 1, 2, 3, matches rule 4. Allowed.
A packet from 8.8.8.8 heading anywhere skips everything until rule 5. Denied.
If you put rule 3 first, it would block all traffic from that subnet—including the web traffic you wanted to allow. Rule order is everything.
The State Table: Remembering Conversations
Basic packet filtering has a problem: when you visit a website, you send a request out, and the server sends responses back. Those responses are inbound traffic. If your firewall blocks unsolicited inbound traffic (as it should), how do the responses get through?
The answer is stateful inspection. The firewall doesn't just look at packets—it tracks connections.
When you initiate a connection to a web server, the firewall notes it: 192.168.1.50 started a conversation with 93.184.216.34 on port 443. This goes into the state table.
When packets arrive from that server, the firewall checks the state table first. Is this part of an existing conversation someone inside started? Yes → allow it through. The firewall remembers who started talking.
This is the magic that makes firewalls practical. Without stateful inspection, you'd have to leave ports open for every possible response—a gaping security hole. With it, you can block all unsolicited inbound traffic while still letting the Internet talk back to you when you ask it to.
Default Deny: When Nothing Matches
Every ruleset needs a final answer for packets that match nothing. This default policy is a fundamental security decision.
Default allow: Everything passes unless explicitly blocked. Convenient, dangerous. Every service you forget to block is exposed.
Default deny: Everything is blocked unless explicitly allowed. Inconvenient, secure. Every service you forget to allow simply doesn't work.
Most security professionals insist on default deny. The failure mode matters: if you forget a rule with default deny, something breaks (you notice, you fix it). If you forget a rule with default allow, something is exposed (you might not notice until it's exploited).
That final "Deny all" in the example ruleset is the default deny—the backstop that catches anything the specific rules didn't address.
Looking Deeper: Inspecting Content
Basic firewalls read headers—the envelope, not the letter. Deep packet inspection (DPI) reads the contents.
This matters because applications lie. Someone might run BitTorrent on port 443 to disguise it as HTTPS traffic. Header inspection sees "port 443, must be web traffic." DPI sees the BitTorrent protocol signatures inside the packets and blocks it anyway.
DPI also catches attacks hiding in legitimate traffic. A request to your web server on port 80 might look fine to header inspection, but DPI can recognize a SQL injection payload in the request body.
The trade-off is performance. Reading contents takes more processing than reading headers. Modern firewalls use specialized hardware to maintain speed, but there's always tension between inspection depth and throughput.
The Encryption Problem
Encrypted traffic is opaque. When everything is HTTPS, the firewall sees that communication is happening but not what's being said.
Some firewalls perform SSL/TLS inspection: they terminate the encrypted connection, decrypt the traffic, inspect it, then re-encrypt and forward it. This works but raises complexity and privacy concerns. The firewall is now a man-in-the-middle—by design.
Many organizations limit this inspection to specific high-risk scenarios where the security benefit justifies the overhead.
What the Logs Tell You
Firewalls generate logs as they work. These aren't just audit trails—they're intelligence.
Blocked traffic logs show you what's being attempted: attack patterns, scanning activity, unauthorized access efforts. Allowed traffic logs show you what's actually happening: who accessed what, when, from where.
These logs reveal both threats and normal patterns. When something changes—a new source of blocked traffic, unusual access patterns—the logs surface it.
Frequently Asked Questions About How Firewalls Work
Was this page helpful?