nftables: With nftables.AsLasting(), Flush() does not return an error although rules are not executed

Problem

I was trying to add a firewall rule which was not supported by my backend of the linux machine (nftables v0.9.0 (Fearless Fosdick) I was not able to add a NAT Chaintype into an inet table. But the flush command did not raise any errors and it was very hard to debug the problem bc no errors were returned. When trying to add the Chain with the linux tool “nft” it threw an error telling me something like:

 sudo nft add chain inet wg0 test-chain2 '{type route  hook output  priority 100; policy accept; }'
Error: Could not process rule: No such file or directory
add chain inet wg0 test-chain2 {type route  hook output  priority 100; policy accept; }

The ip table was recognized

Expected Behaviour

The Wrapper throws an error when the backend is not able to add the functionality into the ruleset

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 1
Comments: 15 (6 by maintainers)

Most upvoted comments

hm, I don’t have access to a Debian system that old.

An easy fix for that is to create a VM and install debian 10. gnome-boxes is an easy to use VM program 😃

Looking at this issue more, one piece of the puzzle is the duplicated AddChain() call in: https://github.com/ziggie1984/nftables_sample/blob/2331b08955e78c20c3520c0a94611bb54c37bf76/main.go#L25-L33

When I remove one of the AddChain() calls, the example also works (i.e. prints an error message for the last, non-working request) with a lasting nftables connection.

I think in the scenario where we send two AddChain() calls, we still only Receive() one error message, and then for the next AddTable() call, we receive the error message from the previous AddChain() call.

This only matters when using a lasting connection — when re-connecting for each Flush(), at least the first NLMSG_ERROR reply will always match the first request sent, papering over this issue.

The problem might be how we call (mdlayher/netlink.Conn).Receive(): https://github.com/google/nftables/blob/1f0380f5c76eb92b9bc92aa1d20585e6871ae4b3/conn.go#L185

I’m thinking we might need to call it an appropriate number of times based on what we send. mdlayher/netlink has its own handling for multi-part messages, but I think multi-part messages might be orthogonal? Perhaps we just need to count how many netlink.Acknowledge flags we send out?

cc @mdlayher in case you happen to know off the top of your head how acknowledgement/error handling is supposed to be done with netlink 😃

stapelberg on Jun 11, 2022