A firewall decides which traffic gets to move and which gets dropped. That is the whole idea, though the machinery behind that decision has grown a lot since the first packet filters. If you run a home router, a small office network, or a cloud VPC, you already have at least one firewall in the path, and probably more than you think. Knowing what each type does, and where rules actually apply, saves you from the two classic mistakes: leaving something wide open, or blocking your own users with a rule nobody remembers writing.
What a Firewall Actually Does
Every firewall makes the same basic judgment about each packet or connection: allow, deny, or log. Direction matters. Rules apply to traffic entering an interface (inbound), leaving it (outbound), or crossing between internal segments. Order matters even more. Firewalls read rules top to bottom, act on the first match, and stop. A permissive rule sitting above a restrictive one quietly cancels it.
Three defaults are worth internalizing:
- Most firewalls deny by default at the end of the list. Any traffic that matches nothing gets dropped.
- An "any source, any destination, allow" rule at the top is the same as having no firewall at all.
- With logging off, you have no way to tell whether your rules are doing what you intended.
One common confusion: NAT is not a firewall. Your home router translates addresses, and as a side effect it blocks unsolicited inbound connections. That is a useful accident, not a policy. It says nothing about what your devices are allowed to reach outbound or what they do once they are talking.
Packet Filtering: Cheap, Fast, and Blind
A stateless packet filter looks at each packet in isolation. Source IP, destination IP, protocol, source port, destination port, and nothing else. It is the bouncer who checks your ID and never remembers your face.
That is enough for simple jobs. Blocking a known-bad address, allowing inbound TCP 443 to a web server, keeping Telnet closed at the edge. It is also cheap, which is why it runs everywhere from consumer routers to cloud security groups.
The blind spot: a stateless filter cannot tell a legitimate reply from a forged packet pretending to be one. If you allow inbound traffic to a range of high ports so return traffic can get back in, you have opened a gap. That gap is exactly why stateful inspection exists.
Stateful Inspection: Remembering the Conversation
A stateful firewall builds a table of active connections. When an internal host opens a session with a web server, the firewall records it: source, destination, ports, sequence state. Return traffic matching that entry passes automatically. Anything arriving from outside that matches no existing session gets dropped.
The practical payoff is a simpler rule set. You write one rule that allows outbound 443, and the replies simply work. You do not need the awkward mirror rules that stateless setups demand, and you do not have to guess which high ports to leave open.
Sessions age out, though. If an idle SSH session or database link times out, the firewall drops it and the client hangs mid-command. Raise the timeout on that specific rule rather than widening the whole policy.
Next-Generation Firewalls: When Ports Stop Meaning Much
Port 443 used to mean web browsing. Now it carries video calls, file transfers, remote administration, and malware callbacks. A rule that allows 443 outbound allows all of it. Port-based filtering has run out of resolution.
Next-generation firewalls add layers on top of stateful inspection:
- Application identification — recognize the actual application regardless of port or protocol tricks.
- Deep packet inspection — examine payload contents for known attack signatures and protocol anomalies.
- Encrypted traffic inspection — decrypt, inspect, and re-encrypt, using a certificate the clients trust.
- Identity awareness — write rules for users and groups instead of IP addresses that move around.
- Intrusion prevention — catch exploit attempts in the middle of an established session.
- URL and DNS filtering — block categories or known-malicious domains before a connection completes.
The cost is processing power, and encrypted inspection is the hungriest of these features. Size the hardware for peak traffic with inspection turned on, not off, and consider bypassing inspection for categories where privacy or regulation makes decryption inappropriate.
Where the Firewall Fits in Your Network
There is rarely one firewall. Think in terms of layers, each answering a different question.
- Perimeter or edge — between your network and the internet. The classic deployment, and still the busiest.
- Internal segmentation — between VLANs: guest Wi-Fi to servers, OT equipment to the corporate LAN, finance to everything else.
- Host-based — software on the endpoint itself. Windows Defender Firewall, nftables on Linux, a local agent on a server. This is the only layer that travels with a laptop.
- Cloud — security groups and network ACLs in your provider, plus virtual appliances when you need real inspection.
- Remote access — VPN concentrators and zero-trust gateways that apply policy per user and per device rather than per subnet.
A useful assumption: traffic inside your network is not automatically trustworthy. Most intrusions spread sideways once they land, and internal segmentation is what slows that spread down. If a compromised laptop can reach your database servers directly, a perimeter firewall will not save you.
Writing Rules That Hold Up
Rule hygiene matters more than the brand on the box. A tidy policy on modest hardware beats a sprawling mess on an expensive appliance.
- Comment every rule. A ticket number, a date, and a name. Future you will not remember why it exists.
- Be specific about source, destination, port, and protocol. "Any" on both sides is how outages and incidents start.
- Place specific rules above general ones. Order is law, not a suggestion.
- Use address groups and objects instead of raw IPs, so one edit updates everywhere the object is used.
- Log denies, but do not log every allowed packet. The volume turns into noise and you will stop reading it.
- Review quarterly. Delete rules with no hits and no owner.
- Test from the outside before you declare the change finished. A rule that looks right in the console can still be wrong in the path.
A Sensible Starting Point
If you are building your first real policy, begin with default-deny inbound, allow outbound broadly, and then tighten outbound as you learn what your users and servers actually need. Turn on logging to a central location from day one, set an alert for configuration changes, and keep a copy of the config somewhere off the device. That way, if a rule change breaks something at a bad hour, you can put the working version back in minutes instead of reconstructing it from memory.
Then revisit it. Firewalls are not set-and-forget equipment. Networks grow, services move, and yesterday's necessary exception becomes today's forgotten hole. A short review every few months is the cheapest security work you will do all year.
Photo: Dan Nelson / Pexels
