Linux Nftables Flowtables: Netfilter Fastpath Connection State Gaps

Enabling nftables flowtables on Linux gateways cuts CPU consumption by bypassing standard Netfilter traversal once a connection is established. The kernel forwards matching TCP and UDP packets directly at the IP layer, skipping rule processing. While this delivers near line-rate throughput on high-speed interfaces, it introduces a critical security trade-off: active flows bypass subsequent firewall updates completely until the flowtable entry expires.

How Flowtable Fastpathing Functions

Linux flowtables cache routing and network address translation decisions in a software table bound to specified network interfaces. During initial TCP handshakes, Netfilter evaluates stateful firewall rules in the standard filter table. Once the connection transitions to an established state, an nftables rule offloads the flow to the fastpath table.

table inet filter {
    flowtable ft {
        hook ingress priority filter
        devices = { eth0, eth1 }
    }

    chain forward {
        type filter hook forward priority filter; policy drop;

        # Offload established traffic to flowtable
        ct state established,related flow add @ft

        # Standard state tracking fallback
        ct state established,related accept
        ip saddr 192.168.1.0/24 accept
    }
}

After flow add @ft executes, packet processing jumps directly from the network interface ingress hook to IP forwarding logic. The kernel updates packet TTLs, recalculates checksums, and transmits frames out the egress interface without passing through prerouting, forward, or postrouting chains again.

Where Security Policies Silently Fail

This path shortening becomes dangerous when system administrators modify firewall policies while high-throughput connections remain active. If you insert a malicious host IP into a drop set or update access control lists during an ongoing transfer, packets matching an active flowtable entry bypass the updated ruleset.

Software flowtables prioritize forwarding latency over chain traversal. Packets matching an active flowtable entry never execute rule checks in standard Netfilter chains until the entry drops from cache.

Consider an operational setup where an automated threat response daemon detects abnormal payload activity on an active socket and appends the source IP to a block list:

nft add element inet filter blacklist { 192.168.1.105 }

If the blacklist set is checked inside the forward chain, established connections offloaded to @ft never evaluate that check. The targeted host continues exchanging packets until the TCP stream terminates naturally or the flowtable idle timer (defaulting to 30 seconds of inactivity) evicts the state.

Remediating Flowtable Enforcement Gaps

To enforce immediate blocking without abandoning offload benefits across the network, security tools must purge active state entries alongside ruleset updates. Deleting the flow from the kernel connection tracking subsystem using conntrack breaks the fastpath association immediately:

conntrack -D -s 192.168.1.105

Removing the connection state forces the next packet back into standard Netfilter chain processing. The packet hits the newly modified forward chain, evaluates the updated blacklist set, and drops before reaching egress routing.

For Linux routers managing dynamic security policy updates or bandwidth quotas, limit flowtable offloading strictly to trusted internal subnets. Any traffic requiring real-time filtering or packet inspection must stay within standard Netfilter pipelines.