Understanding NFTables Chain Placement
A common reason for packet dropping failures in nftables is placing drop rules in the wrong chain type. Unlike iptables, which often encourages users to manipulate the INPUT, OUTPUT, and FORWARD chains directly, nftables uses a more flexible hook-based system. If you are trying to block traffic destined for your local machine, you must place the rule in the input hook of the filter table. Placing it in the route hook or the postrouting hook will not work for inbound traffic because those hooks occur after the routing decision has already been made or after the packet has left the local stack.
The hierarchy matters significantly. The prerouting hook processes packets before routing decisions, while the input hook handles packets destined for the local host. If you attempt to drop a packet at the forward hook, it only affects traffic passing through the device, not traffic intended for the device itself. Misidentifying the hook leads to silent failures where packets appear to be accepted despite existing rules.
Implementing Simple Layer 3 Drop Rules
To resolve this issue, simplify your rule set by focusing on Layer 3 (Network Layer) attributes rather than Layer 4 (Transport Layer) details. Dropping based on IP address or protocol is faster and less prone to errors than dropping based on ports or states if the connection tracking is not fully established. A basic rule to drop all IPv4 traffic from a specific source IP should look like this:
nft add rule ip filter input ip saddr 192.168.1.100 dropThis command adds a rule to the ip family, specifically the filter table, in the input chain. It matches packets with a source address of 192.168.1.100 and immediately drops them. Notice that we do not need to specify a port or protocol. By keeping the match criteria minimal, you ensure that the packet is evaluated against this rule early in the processing pipeline. If you have multiple IPs to block, you can group them into an IP set for better performance and manageability.
For IPv6 traffic, the syntax is similar but uses the ip6 family. You might also consider using named sets to manage large lists of blocked addresses dynamically. This reduces the number of individual rules in the chain, improving lookup speeds. For more advanced configurations involving dynamic IP changes, such as remote access scenarios, you may want to explore how to Match Traffic Destination MAC using nftables for Remote IPv6 LAN Access with Dynamic IP to maintain security without manual rule updates.
Debugging Rule Evaluation Order
If your drop rules still fail, the problem is likely rule ordering. nftables evaluates rules sequentially within a chain. The first matching rule determines the fate of the packet. If an accept rule appears before your drop rule, the packet will be allowed, and the drop rule will never be reached. Always verify the order of your rules using the list command.
nft list rulesetExamine the output carefully. Look for the position of your drop rule relative to other rules. If you see an accept rule for a broader range (e.g., ip saddr 192.168.1.0/24) before your specific drop rule for 192.168.1.100, you must reorder them. You can delete the incorrect rule and re-add it in the correct position, or use the nft insert command to place the rule at the top of the chain.
Additionally, check for implicit accept policies. If your chain policy is set to accept, packets that do not match any rule will be accepted. Ensure your chain policy is set to drop or reject if you want a default deny stance, and then explicitly allow necessary traffic. However, even with a drop policy, explicit accept rules can override subsequent drop rules if ordered incorrectly.
Handling Stateful Filtering Issues
Sometimes, administrators try to drop packets based on connection state, such as ct state invalid. While this is a valid strategy, it can sometimes lead to confusion if the connection tracking subsystem is not functioning as expected. In some cases, packets that appear "invalid" to the tracker might still be processed by the kernel networking stack before the drop rule is hit, depending on the hook placement. For straightforward blocking tasks, avoid relying on ct state unless you are dealing with fragmented packets or specific attack patterns.
If you are redirecting local requests to different IPs, understanding how nftables handles NAT and redirection is crucial. Incorrectly configured redirection rules can mask the fact that a drop rule is working, leading to false positives in troubleshooting. For insights on managing traffic redirection, refer to our guide on how to Redirect Local Requests to IP to Other IP (Linux). This ensures that your filtering rules are not being bypassed by unexpected NAT transformations.
Verifying Packet Drops with Logging
To confirm whether your drop rules are active, enable logging for the specific chain or rule. Add a log rule before your drop rule to see what packets are hitting it.
nft add rule ip filter input ip saddr 192.168.1.100 log prefix "DROP: " dropCheck your system logs (dmesg or /var/log/syslog) for entries prefixed with DROP:. If you see these entries, your rule is working correctly, and the issue lies elsewhere, such as application-level behavior or network path anomalies. If you do not see logs, the packet is likely being dropped by a different mechanism or is not reaching the chain you expect.
Frequently Asked Questions
Why does my nftables drop rule work for ping but not for web traffic?
This usually indicates that the web traffic is being handled by a different chain or table, possibly due to conntrack states allowing established connections. Ensure your drop rule is placed in the correct hook (input or forward) and that it does not rely on state tracking that might bypass it for existing sessions.
Can I use nftables to drop packets based on MAC address?
Yes, you can match on MAC addresses using the ether keyword in the bridge or arp families, but it is generally recommended to stick to IP-based filtering for Layer 3 devices. MAC filtering is more efficient in bridge tables but requires careful consideration of hardware offloading features.
How do I make my nftables rules persistent across reboots?
Save your current ruleset to a configuration file using nft list ruleset > /etc/nftables.conf. Most modern Linux distributions automatically load this file during boot via a systemd service or init script. Verify that the service is enabled and running.
What is the difference between drop and reject in nftables?
drop silently discards the packet without sending any response, which can cause timeouts on the client side. reject sends an ICMP error message back to the sender, providing immediate feedback that the connection was refused. Use reject for interactive services and drop for stealthier blocking.
Why are my IPv6 drop rules not working while IPv4 ones do?
IPv6 rules reside in the ip6 family, separate from the ip family used for IPv4. Ensure you are creating rules in the correct table family. Additionally, check if IPv6 is disabled on the interface or if firewall rules are being overridden by SELinux or AppArmor profiles.