NFQUEUE may split GSO TCP packets before userspace unless `NFQA_CFG_F_GSO` is set (was: Subsequent TCP segments of the same connection are also enqueued to nfqueue)

[dilluti0n]

When nftables matches a ClientHello packet and sends it to nfqueue, Linux conntrack may cause all subsequent segments of the same TCP connection to be enqueued as well. This was confirmed by observing a 114-byte segment (clearly not a ClientHello) entering send_split immediately after a 1448-byte segment from the same connection.

Impact

In practice, these subsequent segments going through handle_packet is harmless. They belong to the same connection as the ClientHello and will be split anyway. However, the current implementation treats every packet entering send_split as a full ClientHello, which is incorrect. Fragmented continuation segments are being processed as if they were independent ClientHellos, which diverges from the intended behavior.

Possible mitigations

• TCP reassembly: Reassemble segments before processing. Correct, but expensive.
• Inspect nfqueue metadata: Use conntrack state or packet metadata exposed by nfqueue to distinguish the first segment from continuations, and route them separately without ClientHello processing.

Either approach involves non-trivial refactoring cost.

Platform note

WinDivert behavior on Windows needs to be investigated. It may or may not exhibit the same characteristic.

[dilluti0n]

Turns out it was caused by default nfqueue behavior, not related with conntrack. If a packet hooked in the queue is longer than the mtu, queue normalize the packet and then delivers it to user space. This behavior can be turned off setting NFQA_CFG_F_GSO to queue. (See https://netfilter.org/projects/libnetfilter_queue/doxygen/html/group__Queue.html)

This is verified through bpftrace.

$ sudo bpftrace -e '
#include <linux/skbuff.h>

kprobe:nf_queue
{
    $skb = (struct sk_buff *)arg0;
    printf("%s (%d)\n", comm, pid);
    printf("skb->len: %d\n", $skb->len);
    printf("%s", kstack);
}
'
curl (1053157)
skb->len: 1622
        nf_queue+5
        nf_hook_slow+163
        __ip_local_out+284
        ip_local_out+27
        __ip_queue_xmit+400
        __tcp_transmit_skb+2761
        tcp_write_xmit+1265
        __tcp_push_pending_frames+54
        tcp_sendmsg_locked+3108
        tcp_sendmsg+43
        __sys_sendto+462
        __x64_sys_sendto+36
        do_syscall_64+135
        entry_SYSCALL_64_after_hwframe+118

Here the length of the skb passed to nf_queue() is 1622 bytes.

2026-06-30 22:51:08 [DEBUG] send_split: dst=172.217.213.113 order=[[0,1), [1,end)] tcp_payload_len=1400
2026-06-30 22:51:08 [DEBUG] send_split: dst=172.217.213.113 order=[[0,1), [1,end)] tcp_payload_len=170

Identical packets are observed to be coming in split in the dpibreak logs. (1570 + tcp header + ip header)

One point of confusion is that in this case, the normalize processed by nf_queue() seems like tcp segmentation (inferred from dpibreak log), but non-tcp packets can enter hook/queue also. The documentation may use normalize because method varies by L3. (Though I doubt there's much documentation on this outside the nf_queue() source...)

[dilluti0n]

However, if NFQA_CFG_F_GSO is set, packets larger than the MTU enter the program, so when writing to the raw socket in send_to_raw, EMSGSIZE occurs if the packet being written is larger than the MTU. If split it in advance considering the MTU using the -o function like this, it works normally:

2026-07-01 01:30:44 [DEBUG] send_split: dst=142.251.157.119 order=[[0,1), [1,500), [500,1000), [1000,1500), [1500,2000),[2000,end)] tcp_payload_len=2468

If not (with -o 0,1,500):

2026-07-01 01:32:43 [WARNING] handle_packet: Message too long (os error 90)

Stack backtrace:
...
   2: dpibreak::platform::linux::send_to_raw
             at ./src/platform/linux.rs:170:13
   3: dpibreak::pkt::send_segment
             at ./src/pkt.rs:163:5
   4: dpibreak::pkt::send_split
             at ./src/pkt.rs:180:9
   5: dpibreak::pkt::handle_packet
             at ./src/pkt.rs:253:5
   6: dpibreak::platform::linux::run
             at ./src/pkt.rs:261:15
   7: dpibreak::main_1
             at ./src/main.rs:44:5
   8: dpibreak::main
...
  25: _start

Warning and packet not processed (verdict::Accept).

Making this the default isn't bad in terms of specifications, but since most users will likely find it inconvenient, I think some consideration is needed.

---

diff --git a/src/platform/linux.rs b/src/platform/linux.rs
index bebc6f4..d7f25b8 100644
--- a/src/platform/linux.rs
+++ b/src/platform/linux.rs
@@ -184,8 +184,10 @@ fn open_nfqueue() -> Result<nfq::Queue> {
     use nix::fcntl::{fcntl, FcntlArg, OFlag};
 
     let mut q = nfq::Queue::open()?;
-    q.bind(crate::opt::queue_num())?;
-    crate::info!("nfqueue: bound to queue number {}", crate::opt::queue_num());
+    q.bind(opt::queue_num())?;
+    q.set_fail_open(opt::queue_num(), true)?;
+    q.set_recv_gso(opt::queue_num(), true)?;
+    crate::info!("nfqueue: bound to queue number {}", opt::queue_num());
 
     // to check inturrupts
     let raw_fd = q.as_raw_fd();