Arch Linux

avi9526

Member

Registered: 2015-05-15

Posts: 117

Suricata in NFQUEUE losing packets

I have

iptables -t mangle -A PREROUTING ! -i lo -m mark ! --mark 0x1/0x1 -j NFQUEUE --queue-num 0 --queue-bypass -m comment --comment "Pass to Suricata, bypass if not available"

and suricata build with nfqueue support running as systemd service

[Unit]
Description=Suricata Daemon on NFQueue %I
After=network.target

[Service]
Type=forking
PIDFile=/var/run/suricata.pid
RuntimeDirectory=suricata
RuntimeDirectoryMode=750
ExecStart=/usr/bin/suricata -D --user=suricata --group=suricata -q%i
ExecReload=/bin/kill -HUP $MAINPID

PrivateTmp=true

[Install]
WantedBy=multi-user.target

systemctl start suricata-nfqueue@0

When suricata is stopped everything is ok.

But once it started some things stop working, like Reflector, it uses python library "urllib.request", which works fine when suricata not running but fails otherwise

import urllib.request
url='https://bbs.archlinux.org'
f=urllib.request.urlopen(url, None, 5)
r=f.read()

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/http/client.py", line 454, in read
    return self._readall_chunked()
  File "/usr/lib/python3.7/http/client.py", line 564, in _readall_chunked
    value.append(self._safe_read(chunk_left))
  File "/usr/lib/python3.7/http/client.py", line 610, in _safe_read
    chunk = self.fp.read(min(amt, MAXAMOUNT))
  File "/usr/lib/python3.7/socket.py", line 589, in readinto
    return self._sock.recv_into(b)
  File "/usr/lib/python3.7/ssl.py", line 1049, in recv_into
    return self.read(nbytes, buffer)
  File "/usr/lib/python3.7/ssl.py", line 908, in read
    return self._sslobj.read(len, buffer)
socket.timeout: The read operation timed out

And I have no idea why. Suricata does not drop any packets (no drops in logs, only alarms and not related), it has "fail-open" option to skip check if queue is full. Queue is not full (cat /proc/net/netfilter/nfnetlink_queue). I've seen some related old bugs about problem with iptables conntrack after suricata https://www.spinics.net/lists/netfilter … 27247.html that suggest to use suricata in "raw" table. Moving Suricata from "mangle" to "raw" table does not fix this problem, so I assume it may be something else. What can be done to find a reason for this?