We reproduced an NFQUEUE packet loop with Suricata 8.0.7 when combining workers mode, repeat mode and verdict batching.
Suricata is started with:
suricata -c /etc/suricata/suricata.yaml
-q 1000
–runmode workers
Relevant configuration:
nfq:
mode: repeat
repeat-mark: 0x2000
repeat-mask: 0x2000
batchcount: 20
fail-open: no
The relevant iptables chain is:
-A IDPS_INSPECT -m mark --mark 0x4000/0x4000
-j NFQUEUE --queue-num 500 --queue-bypass
-A IDPS_INSPECT -m mark --mark 0x2000/0x2000
-j RETURN
-A IDPS_INSPECT
-j NFQUEUE --queue-num 1000 --queue-bypass
The intended behavior is:
- An uninspected packet enters queue 1000.
- Suricata inspects it.
- Suricata returns NF_REPEAT with mark 0x2000 .
- The repeated packet matches the 0x2000 rule and leaves the inspection chain.
With batchcount: 20 , ordinary packets repeatedly return to queue 1000 without matching the 0x2000 rule. The NFQUEUE packet sequence increased and TCP connections timed out.
Changing only this setting resolves the issue:
nfq:
batchcount: 1
With --runmode workers and batchcount: 1 :
• The NFQUEUE loop stops.
• Normal TCP/TLS connections complete successfully.
• The expected repeat-mark behavior works.
Reviewing source-nfq.c , the individual-verdict path explicitly combines nfq_config.mark with the packet mark for NFQ_REPEAT . The verdict-cache path appears to consider only mark_modified . For an ordinary packet, mark_modified is false, so the cache appears to use nfq_set_verdict_batch() rather than a mark-aware batch verdict containing the configured repeat mark.
Is batchcount > 1 expected to be supported with nfq.mode: repeat and nfq.repeat-mark ? If so, should the batched path apply the effective repeat mark through nfq_set_verdict_batch2() ?
Environment
• Suricata 8.0.7
• NFQUEUE workers run mode
• Linux iptables
• libnetfilter_queue batch-verdict support enabled
• Reproduced with normal TCP/TLS traffic; no alert or drop rule is required
• batchcount: 20 reproduces consistently
• batchcount: 1 consistently resolves the issue