February 4, 2025

Firewalling in 2025

Firewalls haven't fundamentally changed in concept — you're still deciding what traffic to allow and what to drop — but where they run and what they understand about traffic has evolved a lot. This is a quick look at the landscape: what the tools are, how they've changed, and what actually matters for most people running their own servers.

The Basics Haven't Changed

At the core, a firewall is still just a ruleset: match packets against criteria, decide pass or block. The criteria can be as simple as "drop everything incoming on port 23" or as complex as "allow established connections from this subnet except for traffic matching these application signatures." The fundamental model is the same one from the 90s.

What has changed is where that ruleset runs and how much it can see:

  • Packet filtering — the classic layer 3/4 approach. Looks at IP, port, protocol. Fast, simple, blind to content.
  • Stateful filtering — tracks connection state. Knows the difference between a new connection attempt and an established session. This is what all serious firewalls have done since the late 90s.
  • Application-layer / deep packet inspection — can see inside the traffic. Understands HTTP, DNS, TLS. More CPU-intensive, much more capable.

The Tools That Actually Matter

For anyone running a BSD or Linux system, the main players:

  • OpenBSD pf — clean syntax, tightly integrated with OpenBSD and FreeBSD. The configuration file reads like English compared to iptables. My preferred choice for BSD-based firewalls and routers.
  • nftables — the modern Linux kernel firewall, replacing iptables. More consistent syntax, better performance with large rulesets. iptables still works but nftables is where new development is happening.
  • iptables — still the default on many older Linux systems and still perfectly functional. Just don't start new projects with it.
  • ufw / firewalld — frontends that make iptables/nftables more approachable. ufw is simple and good for basic setups; firewalld is more structured and better for complex rules.
  • pfSense / OPNsense — FreeBSD-based firewall distributions with web UIs. Great for dedicated hardware or VMs where you want a proper router/firewall without managing everything from scratch.

The Cloud Complication

If you run anything in AWS, GCP, or Azure, you're dealing with their security groups and network ACLs whether you want to or not. These are the firewall layer that lives outside your instance — traffic gets filtered before it ever reaches your server. They're stateful (security groups) or stateless (network ACLs), and you generally run both plus a host firewall.

The layered approach is good security practice. The problem is that three layers of firewall rules in three different places is also an excellent way to spend an afternoon debugging why traffic that should work doesn't.

What's Actually New

The buzzwords in enterprise security — Zero Trust, SASE, NGFWs, AI-driven threat detection — are real things, but they mostly apply at the scale of large organizations with dedicated security teams. For running your own servers:

  • Encrypted traffic (HTTPS everywhere) makes content inspection largely useless unless you're doing TLS inspection with your own CA, which introduces its own problems.
  • Container and Kubernetes networking has created new tools (Cilium, Calico) for microsegmentation at the pod level. If you're running containers at scale this matters; for a VPS running a few services, it doesn't.
  • Fail2ban-style dynamic blocking is increasingly important as automated scanning is constant. Whatever firewall you use, something should be watching logs and banning repeat offenders.

What to Actually Run

For a typical self-hosted setup: pick pf if you're on BSD, nftables or ufw if you're on Linux. Block everything by default, open what you need, log what's interesting. Run fail2ban or sshguard. That's 90% of what matters. The rest is tuning.