Rethinking Firewall Architecture in the eBPF Era

Most people think iptables is a performance problem. It's not. It's a structural one — by the time your DROP rule would fire, the kernel has already allocated memory for every attacker packet, conntrack has filled up, and legitimate traffic is dying. Your rule never runs.

This talk is about what happens when you move the decision point earlier — to XDP, which runs inside the NIC driver before sk_buff allocation, before conntrack, before iptables. A packet you drop at XDP never existed as far as the kernel is concerned.

But dropping packets is the easy part. The interesting problems are architectural: how do you share state between a kernel program and a userspace daemon without a syscall per packet? What happens when two processes write the same BPF map and an attacker controls the key space? How do you get a full audit trail of rule changes without building one explicitly?

I spent the last year building a firewall daemon from scratch to answer these questions. This talk walks through what I learned — the decisions, the tradeoffs, and the problems that static allow/block rules don't solve.

Live demo: block an IP, watch ping die, restart the daemon, watch rules survive.

1. iptables fails structurally under flood — conntrack exhaustion means your rules never fire. XDP moves the decision before any allocation happens.

2. BPF maps are a kernel/userspace contract — pinned to bpffs, no syscall per packet, survives restarts on both sides.

3. Who writes the map is a security decision — two writers + LRU + attacker-controlled key space creates phantom blocks. One writer closes the race and gives you an audit trail for free.

4. aya makes the type system span the kernel boundary — same Rust type in the map and the REST handler. Drift between them won't compile.