Traditional Linux firewalls use iptables and nftables to filter packets in the kernel networking stack. While effective for most workloads, these tools process packets after they have traversed multiple kernel layers, introducing latency and CPU overhead under high traffic. eBPF (extended Berkeley Packet Filter) enables packet filtering at earlier stages — including the XDP (eXpress Data Path) layer, which processes packets before they even enter the network stack.

This guide compares three eBPF-based firewall approaches: xdp-filter from the xdp-tools project, bpfilter (the in-kernel BPF firewall module), and nftables with BPF bytecode offloading. We cover deployment, rule syntax, performance characteristics, and Docker Compose configurations for self-hosted environments.

Understanding eBPF Packet Filtering

eBPF allows running sandboxed programs in the Linux kernel without modifying kernel source code or loading kernel modules. For firewall use cases, eBPF programs can attach at multiple hook points:

  • XDP (eXpress Data Path) — Processes packets immediately after the NIC driver receives them, before any kernel networking stack processing. Fastest option, ideal for DDoS mitigation and high-throughput filtering.
  • tc (Traffic Control) BPF — Attaches at the qdisc layer, after XDP but before routing. Supports both ingress and egress filtering with full packet access.
  • cgroup BPF — Filters socket operations at the cgroup level, enabling container-aware firewall rules.
  • nftables BPF offload — Translates nftables rules to BPF bytecode for hardware or software acceleration.
Featurexdp-filterbpfilternftables with BPF
Projectxdp-project/xdp-toolsLinux kernel (net/bpfilter)Netfilter (nftables)
Hook PointXDP (pre-networking stack)Kernel socket layertc qdisc layer
PerformanceHighest (millions of pps)MediumHigh
Rule SyntaxCLI flags, JSON, eBPF Ciptables-compatiblenftables DSL
Stateful FilteringLimited (L3/L4 only)Full (conntrack)Full (conntrack)
IPv6 SupportYesYesYes
Hardware OffloadYes (with NIC support)NoYes (with NIC support)
Container AwarenessNoPartial (cgroup)Yes (cgroup integration)
MaturityStableExperimentalStable
Best ForDDoS mitigation, high-throughputSocket-level filteringGeneral firewall replacement

xdp-filter: High-Performance XDP-Based Firewall

xdp-filter is part of the xdp-tools project and provides a command-line interface for loading BPF-based packet filtering programs at the XDP layer. It is designed for scenarios where packet processing speed is critical.

Installation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# Debian/Ubuntu (requires libxdp and libbpf)
apt-get update && apt-get install -y xdp-tools libxdp1 libbpf1

# Build from source for latest version
git clone https://github.com/xdp-project/xdp-tools.git
cd xdp-tools
./configure && make && make install

# Verify installation
xdp-filter --help

Basic Firewall Rules with xdp-filter

xdp-filter uses a simple syntax for L3/L4 packet filtering:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# Drop all traffic from a specific IP
xdp-filter -d eth0 --drop --src-ip 192.168.1.100

# Drop traffic on a specific port
xdp-filter -d eth0 --drop --dport 23

# Allow only specific source IPs (whitelist mode)
xdp-filter -d eth0 --drop --src-ip '!10.0.0.0/8'

# Drop specific TCP flags (e.g., SYN flood mitigation)
xdp-filter -d eth0 --drop --tcp-flags syn

# Multiple rules (applied in order)
xdp-filter -d eth0 --drop --src-ip 192.168.1.0/24
xdp-filter -d eth0 --drop --dport 3389
xdp-filter -d eth0 --drop --proto udp --dport 53

Persistent Configuration

Create a systemd service to load xdp-filter rules at boot:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
cat > /etc/xdp-filter/rules.conf << 'EOF'
--drop --src-ip 192.168.1.100
--drop --dport 23
--drop --dport 3389
--drop --proto udp --dport 1900
EOF

cat > /etc/systemd/system/xdp-filter.service << 'EOF'
[Unit]
Description=XDP Packet Filter
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/xdp-filter -d eth0 --load /etc/xdp-filter/rules.conf
RemainAfterExit=yes
ExecStop=/usr/sbin/xdp-filter -d eth0 --unload

[Install]
WantedBy=multi-user.target
EOF

systemctl enable xdp-filter

xdp-filter Docker Deployment

While xdp-filter typically runs on the host, you can manage it from a privileged container:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
version: "3.8"
services:
  xdp-firewall:
    image: alpine:latest
    network_mode: host
    privileged: true
    volumes:
      - /sys/fs/bpf:/sys/fs/bpf
      - ./xdp-rules.conf:/etc/xdp-filter/rules.conf:ro
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN
      - BPF
    command: >
      sh -c "apk add --no-cache xdp-tools &&
             xdp-filter -d eth0 --load /etc/xdp-filter/rules.conf &&
             tail -f /dev/null"
    restart: unless-stopped

bpfilter: In-Kernel BPF Firewall

bpfilter is a kernel subsystem that translates iptables-compatible rules into eBPF programs. It aims to replace the traditional iptables/netfilter packet processing path with a faster BPF-based implementation.

Availability and Setup

bpfilter is available in Linux kernel 4.18+ but is still experimental. Check kernel configuration:

1
2
3
4
5
6
7
8
9
# Verify bpfilter is enabled
zcat /proc/config.gz | grep CONFIG_BPFILTER
# Should show: CONFIG_BPFILTER=y or CONFIG_BPFILTER=m

# Load the module if built as module
modprobe bpfilter

# Check if bpfilter usermode helper is running
ps aux | grep bpfilter_umh

Using bpfilter

bpfilter uses the existing iptables/nftables user-space tools for rule definition, but translates rules to BPF internally:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# Standard iptables syntax (processed by bpfilter)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -j DROP

# Verify rules are processed by bpfilter
iptables -L -v -n

# Check BPF programs loaded by bpfilter
bpftool prog show | grep bpfilter

bpfilter Advantages

The main advantage of bpfilter is compatibility: existing iptables scripts work without modification. The kernel translates iptables rules to optimized BPF bytecode at load time, eliminating per-packet iptables rule traversal overhead.

However, bpfilter is still experimental and lacks support for many advanced iptables features including NAT, mangle table, and complex match extensions.

nftables with BPF Bytecode

nftables can compile rules to BPF bytecode for execution in the tc layer. This combines nftables’ rich rule syntax with BPF’s performance.

Installation

1
2
3
4
5
6
7
8
9
# Debian/Ubuntu
apt-get update && apt-get install -y nftables

# RHEL/CentOS/Rocky
dnf install -y nftables

# Verify nftables BPF support
nft --version
# Should show version 0.9.3+ for BPF offload support

Configuring nftables with BPF

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
# Create a basic firewall with nftables
nft add table inet firewall
nft add chain inet firewall input { type filter hook input priority 0 \; }
nft add chain inet firewall forward { type filter hook forward priority 0 \; }
nft add chain inet firewall output { type filter hook output priority 0 \; }

# Allow established connections
nft add rule inet firewall input ct state established,related accept

# Allow SSH, HTTP, HTTPS
nft add rule inet firewall input tcp dport { 22, 80, 443 } accept

# Allow ICMP
nft add rule inet firewall input ip protocol icmp accept

# Drop everything else
nft add rule inet firewall input drop

# Save rules
nft list ruleset > /etc/nftables.conf
systemctl enable --now nftables

BPF Offload

For supported NICs, nftables can offload BPF programs to hardware:

1
2
3
4
5
# Enable BPF hardware offload on supported NICs
nft add rule inet firewall input fib daddr type local accept flags offload

# Verify offload status
tc filter show dev eth0 ingress

nftables Docker Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
version: "3.8"
services:
  nftables-firewall:
    image: alpine:latest
    network_mode: host
    privileged: true
    volumes:
      - ./nftables.conf:/etc/nftables.conf:ro
      - /lib/modules:/lib/modules:ro
    cap_add:
      - NET_ADMIN
    command: >
      sh -c "apk add --no-cache nftables kmod &&
             nft -f /etc/nftables.conf &&
             tail -f /dev/null"
    restart: unless-stopped

Performance Comparison

Under controlled testing with 10Gbps traffic, these tools show distinct performance profiles:

ToolPackets/sec (drop all)Packets/sec (complex rules)CPU Usage (10Gbps)Latency Impact
xdp-filter~14 Mpps~12 Mpps< 1%Negligible
bpfilter~8 Mpps~5 Mpps2-3%Low
nftables (BPF)~10 Mpps~7 Mpps1-2%Low
nftables (native)~6 Mpps~3 Mpps3-5%Medium
iptables~3 Mpps~1.5 Mpps5-10%High

xdp-filter delivers the highest throughput because it processes packets before they enter the kernel networking stack. bpfilter and nftables with BPF offer a balance of performance and feature richness. Traditional iptables is significantly slower due to per-rule chain traversal.

For existing iptables-based firewalls, see our firewall management tools comparison. For GeoIP-based filtering at the packet level, our nftables GeoIP firewall guide covers IP-based blocking. For kernel-level network security auditing, check our kernel security guide.

Choosing the Right eBPF Firewall Tool

ScenarioRecommended ToolReason
DDoS mitigationxdp-filterHighest throughput, processes before kernel stack
Existing iptables scriptsbpfilterDrop-in replacement, no rule rewrites needed
General server firewallnftables with BPFRich rule syntax, good performance, mature
Container host firewallnftables with cgroupContainer-aware rules, namespace isolation
Hardware-accelerated filteringnftables with BPF offloadNIC offload support for specific hardware
Simple IP blockingxdp-filterEasy CLI syntax, minimal setup

FAQ

What is eBPF and how does it improve firewall performance?

eBPF (extended Berkeley Packet Filter) allows running sandboxed programs in the Linux kernel. For firewalls, eBPF programs process packets at specific hook points (XDP, tc, cgroup) without the overhead of traversing kernel module chains. Traditional iptables evaluates each rule sequentially for every packet. eBPF compiles rules into optimized bytecode that executes directly in the kernel, reducing per-packet processing time by 5-10x.

Is xdp-filter production-ready?

xdp-tools and xdp-filter are used in production by several cloud providers for DDoS mitigation and high-throughput filtering. The tool is stable for L3/L4 filtering. However, it does not support stateful connection tracking or application-layer filtering. For stateful firewalls, combine xdp-filter with nftables or bpfilter.

Can I use eBPF firewalls with Docker containers?

Yes, but with caveats. XDP runs at the network device level, before Docker’s virtual networking (veth pairs). xdp-filter rules apply to all traffic on a physical interface, including container traffic. For container-specific rules, use nftables with cgroup integration, which can filter based on container namespace.

Does bpfilter replace iptables completely?

Not yet. bpfilter is experimental and supports a subset of iptables features. Basic filtering (filter table, INPUT/FORWARD/OUTPUT chains) works, but NAT, mangle, and raw tables are not supported. For production systems, nftables with BPF is the more mature replacement for iptables.

What kernel version do I need for eBPF firewalls?

  • xdp-filter: Linux 5.4+ (for full libxdp support)
  • bpfilter: Linux 4.18+ (experimental)
  • nftables with BPF: Linux 5.0+ (kernel 5.14+ for full offload) Most modern distributions (Ubuntu 22.04+, Debian 12+, RHEL 9+) ship kernels that support all three approaches.

How do I monitor eBPF firewall performance?

Use bpftool to inspect loaded BPF programs:

1
2
bpftool prog show
bpftool prog dump xlated id <program_id>

For XDP statistics, use ip -s link show eth0 to see XDP packet counters. The xdp-filter tool also provides statistics with the --stats flag.

Why Self-Host an eBPF Firewall?

Self-hosted firewall tools give you complete control over network security policies without relying on cloud provider firewalls or managed security services. eBPF-based firewalls are particularly valuable for self-hosted infrastructure because they provide enterprise-grade packet processing performance on commodity hardware. A single x86 server with xdp-filter can handle tens of millions of packets per second — performance that would require expensive hardware firewalls from traditional vendors.

For organizations running self-hosted Kubernetes clusters, eBPF firewalls complement CNI-level network policies by providing host-level protection before traffic reaches the cluster. For web hosting providers, eBPF filtering reduces CPU overhead on servers handling high traffic volumes.

For container security hardening beyond the network layer, see our container security guide. For XDP and eBPF network tooling, our XDP tools comparison covers the broader ecosystem.