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, how much they can see, and what the landscape looks like for self-hosted setups has evolved. This is a practical overview of what matters and what's actually new.

The Core Concepts Haven't Changed

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

Type	Layer	What it sees	Character
Packet filtering	3 / 4	IP, port, protocol	Fast, simple, blind to connection state
Stateful filtering	3 / 4 + state	Connection state, sequence numbers	Standard for two decades; handles return traffic automatically
Application layer (DPI)	7	Protocol content (HTTP, DNS, TLS)	Powerful, CPU-intensive; HTTPS largely defeats it without MITM

The Tools That Actually Matter

Tool	Platform	Status in 2025
OpenBSD pf	OpenBSD, FreeBSD	The standard for BSD. Clean syntax, tightly integrated. Best choice for BSD-based firewall/routers.
nftables	Linux	The modern Linux kernel firewall, replacing iptables. Where new development happens. Use it for new Linux setups.
iptables	Linux	Still works; still the default on older systems. Don't start new projects with it — nftables is the future.
ufw	Ubuntu / Debian	User-friendly frontend for iptables/nftables. Good for simple setups; command-line focused.
firewalld	Red Hat / Fedora / Rocky	More structured frontend; zones and services model. Better for complex rules than ufw.
pfSense / OPNsense	Dedicated appliance	FreeBSD-based distributions with web UIs. Excellent for dedicated hardware or VMs acting as routers.

The Cloud Complication

If you run anything in AWS, GCP, or Azure, you deal 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.

Security groups (AWS) — stateful, per-instance rules. Traffic matching an outbound rule automatically allows the return.
Network ACLs (AWS) — stateless, per-subnet rules. You must explicitly allow return traffic in both directions.
Host firewall — iptables/nftables/ufw running inside the instance itself.

The layered approach is good security practice. The problem is three layers of firewall rules in three different interfaces is an excellent way to spend an afternoon debugging why traffic that should work doesn't. Keep a diagram of which layer blocks what.

What's Actually New

Encrypted Traffic Everywhere

HTTPS everywhere means most content inspection is useless without TLS termination at the firewall — which introduces its own problems (certificate pinning breakage, new trust boundary, performance cost). The practical effect: application-layer firewalls are less useful for traffic to/from the open internet than they were in the HTTP era.

Container and Kubernetes Networking

Container networking (Docker, Kubernetes) operates at a different level — network policies applied at the pod level rather than the host level. Tools like Cilium (eBPF-based) and Calico implement microsegmentation within a cluster. If you're running containers at scale this matters significantly; for a single VPS running a few services, it's irrelevant.

Dynamic Blocking Is More Important

Automated scanning of the internet is constant and has increased. Whatever firewall you use, something should be watching logs and dynamically banning repeat offenders:

pf — built-in with overload tables and max-src-conn-rate
Linux — fail2ban or sshguard watching logs and adding iptables/nftables rules

What to Actually Run

For a typical self-hosted server:

Pick pf (BSD) or ufw/nftables (Linux)
Default deny — block all inbound, allow what you need explicitly
Log blocked traffic on the external interface
Run fail2ban or pf's overload tables for dynamic brute-force blocking
Use ed25519 SSH keys, disable password auth, disable root login

That covers 90% of what matters for a personal or small production server. The rest is tuning for specific threat models.