Stop your conntrack table from overflowing when you handle too many WireGuard peers

Technical Briefing | 8/3/2026

WireGuard is performant, but it lives inside the kernel and respects your netfilter conntrack table just like everything else. If you are running a concentrator for dozens of remote offices, you will eventually hit the connection tracking limit. When that happens, your server starts dropping packets silently, and your logs will show mysterious timeouts that disappear if you just wait a few minutes. I learned this the hard way during a massive re-keying event where every client hammered the gateway simultaneously.

Why conntrack cares about your tunnels

Even if you are only doing routing, your firewall is likely tracking the state of those encapsulated UDP packets. Once you hit the net.netfilter.nf_conntrack_max limit, the kernel starts discarding new flows. Because WireGuard is stateless, it doesn’t care, but your NAT rules and stateful firewalls absolutely do. If you do not bump this ceiling, you are just waiting for a busy Monday morning to watch your traffic fall off a cliff.

sysctl -w net.netfilter.nf_conntrack_max=262144
sysctl -w net.netfilter.nf_conntrack_buckets=65536

• Check your current table utilization with conntrack -C before you panic
• The default bucket size is often too low, forcing longer hash chains which kills CPU performance
• Ensure you are persisting these values in /etc/sysctl.conf so they survive a reboot

Is bypassing stateful inspection worth it

If you really want to optimize, you can skip conntrack entirely for your WireGuard traffic by using the raw table in nftables. You add a rule in the prerouting chain with the notrack verdict. It is faster and safer for high-throughput nodes, but remember that your stateful firewall rules won’t apply to those packets anymore. If you have the RAM to spare, just increase the limits, but if you are pushing multi-gigabit speeds, skipping tracking is the only way to keep the CPU usage sane.

If you find your gateway flapping under load, check those kernel counters first. It is almost never the encryption overhead and almost always the state table giving up on life.