Firewall throughput drop issues are often the cause of slow network performance. While firewalls are essential for security, misconfigured rules can slow down your network performance. A firewall doesn’t just block packets; it inspects them, which costs CPU cycles and adds latency. When traffic volume overpasses the firewall’s processing speed, throughput drops, even if your network interface is capable of more.

In this guide from PerLod Hosting, we want to detect the firewall throughput issues and how to optimize performance without sacrificing security.

Why Your Firewall Slows Down Network Performance?

The most important thing is finding the root cause of firewall throughput issues. Throughput drops are rarely due to a bad cable; they are usually due to your Linux system not processing the data fast enough.

Here are the most common causes of firewall throughput issues:

1. Linear Processing: Older firewalls like iptables read rules one by one, from top to bottom. For example, if you have 5,000 rules, the server might have to check a packet against 4,999 of them before accepting it, which creates a massive workload for your processor. Your internet speed drops because the server is too busy reading the rule list to move the data.

2. Connection Tracking Overload: Stateful firewalls try to remember every single active connection. States include NEW, ESTABLISHED, and RELATED. The kernel maintains a massive table in RAM (/proc/net/nf_conntrack) to track these states.

For every packet, the system must look up this table, update timers, and create new entries. High-throughput traffic, like backups or video streaming, generates thousands of packets per second. If the conntrack table gets full or the lookup becomes too slow, the kernel actively drops packets, which causes huge retransmissions and throughput collapse.

3. Lack of Hardware Offloading: By default, your server’s main processor (CPU) handles all firewall tasks. However, modern network cards often have special features to take over this workload.

If this offloading feature is disabled, the main CPU gets stuck inspecting every single packet manually, which causes your powerful Dedicated Server to become a slow software router. Your speed is limited by the CPU’s processing power, not the actual speed of your internet connection.

How To Find Firewall Throughput Drop Issues?

Before implementing the best solutions, you must identify the firewall throughput drop issues. To do this, follow the steps below:

Step 1: You must measure your raw throughput with the firewall active.

On your receiver server, use the following iperf3 command:

iperf3 -s

From the client, run for 30 seconds to stress the connection:

iperf3 -c server_ip -t 30

Watch for the bitrate; if it is lower than your link speed, for example, 4Gbps on a 10Gbps link, continue.

Step 2: Firewall processing happens in SoftIRQ context, so you must check for the CPU SoftIRQ with the command below:

top -1

Look for the %si (Software Interrupt) column; if one specific CPU core shows high %si usage, for example, 90 to 100%, while iperf3 is running, your firewall is CPU-bottlenecked.

Step 3: Use the ethtool command to check if the Network Card itself is dropping packets because the kernel isn’t picking them up fast enough:

ethtool -S eth0 | grep -E "drop|discard|error"

• rx_dropped: Means the kernel ring buffer is full, CPU is too slow to process firewall rules.
• rx_missed_errors: Points to hardware or driver inability to keep up.

Step 4: If throughput starts high, then drops to zero, then recovers, your tracking table might be full.

Check current usage vs max limit with the command below:

count=$(cat /proc/sys/net/netfilter/nf_conntrack_count)
max=$(cat /proc/sys/net/netfilter/nf_conntrack_max)
echo "Usage: $count / $max"

Then, check kernel logs for overflow errors:

dmesg | grep "conntrack: table full"

If you see a full message, the kernel is dropping valid packets immediately.

Best Solutions to Resolve Firewall Throughput Drop Issues

Once you found the firewall throughput drop issues, you can use these solutions to restore your performance.

Solution 1. The NOTRACK Target: For trusted and high-throughput traffic like internal backups or storage synchronization, you should bypass the connection tracking entirely. This is the most effective optimization solution.

For iptables users, you must use the raw table, which is processed before connection tracking.

For example, bypass tracking for port 80 with the commands below:

iptables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK
iptables -t raw -A OUTPUT -p tcp --sport 80 -j NOTRACK

You must also specifically ALLOW UNTRACKED packets in the filter table:

iptables -A INPUT -m state --state UNTRACKED -j ACCEPT

For nftables users, you must attach the rule to a chain with a priority lower than connection tracking, which is -200. Here we use -300.

Create a chain with raw priority with the command below:

nft add chain inet my_table raw_chain { type filter hook prerouting priority -300 \; }

Add the notrack rule with the following command:

nft add rule inet my_table raw_chain tcp dport 80 notrack

Solution 2. Use IPSet or nftables Sets: Never list hundreds of IP addresses as individual rules. It is recommended to use ipset for iptables or native Sets for nftables. This allows the firewall to find a match instantly, regardless of list size. Checking against 10,000 IP addresses becomes just as fast as checking against ten.

For example, for iptables with ipset:

# Create a set for blocked IPs
ipset create blocked_ips hash:ip

# Add an IP
ipset add blocked_ips 192.168.1.50

# Single iptables rule matches the WHOLE list
iptables -A INPUT -m set --match-set blocked_ips src -j DROP

Solution 3. Optimize Sysctl Parameters: If you cannot disable connection tracking, you must tune the kernel to handle the load.

Edit /etc/sysctl.conf file and adjust the following metrics as shown below:

# Increase the size of the tracking table (requires RAM)
net.netfilter.nf_conntrack_max = 524288

# Reduce how long the firewall remembers "closed" connections (frees up space faster)
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 15

Once you are done, apply the changes with the command below:

sysctl -p

By implementing these best fixes, you can restore your performance.

FAQs

Conclusion

Fixing firewall throughput drop isn’t about buying expensive hardware; it’s about helping your server work smarter. When speed drops, your firewall is likely fighting against its own rules.

Instead of upgrading your server, check if your CPU is overwhelmed by SoftIRQ or if your connection table is full. Simple fixes like using NOTRACK for trusted data or IPSets for long lists can instantly remove this issue. These changes ensure your firewall protects your network without slowing it down.

We hope you enjoy this guide. Subscribe to X and Facebook channels to get the latest articles and updates.

For further reading:

Differences between iptables and nftables Performance

MTU mismatch symptoms and fixes