SetVerdictWithMark function is not working properly

[amiq96]

Sometimes it is setting the mark, sometimes it is not setting. We have passed a dns packet via nfqueue in nftables to our custom go program which is using this lib.
When we are setting mark in mangle prerouting and checking in nat prerouting sometimes it is set and sometime it isn't.

I checked this lib: https://github.com/open-ch/go-nfqueue/blob/2a6cb2cc9ef0/nfqueue.go
Here "Flags: netlink.HeaderFlagsRequest", please see if this could be the error

Let me also thank you for this great project

[florianl]

Hey 👋
Can you provide a minimal reproducer for the issue? Did you use tools like pwru to verify the statement and follow its path? If so, can you provide its output?

You are referencing a fork of this package that was updated last +7 years ago. Things were fixed upstream that seems not to be applied downstream to this fork.

[VamshiKrishnaM13]

Hi — Firstly, thank you @florianl for maintaining this project — it's been super helpful.

I just wanted to say that I'm also facing the same issue that @amiq96 described. I am using nftables to pass DNS packets through an nfqueue, handled by a Go program using the go-nfqueue library. When marking packets in the mangle prerouting chain and checking in nat prerouting, I observe that:

Sometimes the mark is correctly applied as observed in the next chain, sometimes it’s not.

Here's a simplified code snippet i am using::

if check(&a) {
    nf.SetVerdict(id, nfqueue.NfAccept)
} else {
    nf.SetVerdictWithMark(id, nfqueue.NfAccept, int(*a.Mark | 1<<16)) // marking 16th bit
}

Even when check() consistently returns false, I randomly observe that the mark is not set when inspected in nat prerouting.

The corresponding nftables rule in nat prerouting:

table ip nat {
    chain prerouting {
        type nat hook prerouting priority dstnat; policy accept;
        meta mark & 0x00010000 != 0x00000000 tcp dport 53 counter nflog group 12 accept
        meta mark & 0x00010000 != 0x00000000 udp dport 53 counter nflog group 12 accept
    }
}

I have also added logs to debug, and confirmed some packets are just not marked even when SetVerdictWithMark() is used.

Questions:

Has anyone confirmed that this issue does not occur?

Is there a known timing or race condition where verdicts are returned from userspace to the kernel, possibly causing the logs I'm reviewing to appear before the kernel marks those specific packets?

Does this behavior change when there are a large number of DNS requests?

Any insights or potential workarounds would be greatly appreciated 🙏

Thanks again!

[florianl]

@amiq96 and @VamshiKrishnaM13 can you please use pwru to verify that the mark is applied? Are DNS packages, that don't get marked, using the same path in the kernel? Can you please provide the relevant logs?