Bug #6587
openDPDK 'tap' mode doesn't alert on TCP protocol rules
Description
Tested using:
Suricata version 8.0.0-dev (d005fff7b 2023-11-24)
Suricata version 7.0.3-dev (aae6beaa5 2023-11-22)
Suricata version 7.0.3-dev (c8a7204b1 2023-11-02)
In a Debian 12 Qemu VM using either e1000 or virtio NICs.
Test sensor has two detection NICs, straddling two virtual networks. Each virtual network has a VM, one acting as a client (10.1.11.1/16) and one acting as a server (10.1.12.1/16). I ran inetsim on the 'server'.
I tried detecting SMTP, HTTP, DNS and FTP using the attached local.rules
I generated traffic with attached generate_detections.sh
When running Suricata using attached manual_dpdk_suricata.sh, I get no TCP protocol detections. See attached fast.dpdk.log.
When running Suricata using attached manual_bridge_suricata.sh, I get the expected detections. See attached fast.br0.log
Files
Updated by Jason Ish about 1 year ago
Perhaps related, https://redmine.openinfosecfoundation.org/issues/5871. I've had nothing but trouble testing AF_PACKET and NFQ IPS modes in KVM and VirtualBox.
Updated by Francis Trudeau about 1 year ago
Jason Ish wrote in #note-1:
Perhaps related, https://redmine.openinfosecfoundation.org/issues/5871. I've had nothing but trouble testing AF_PACKET and NFQ IPS modes in KVM and VirtualBox.
It's looking like that.
I'm getting the exact same behavior using af-packet tap and IPS mode. IPS blocks all TCP traffic and tap doesn't alert on any layer 4 rules over TCP but does pass the traffic.
I also sniffed on the 'server' interface of the af-packet IPS setup. The SA packets are showing up at the interface so it's Suricata that's not letting them through. I wasn't able to verify that using DPDK.
related:
Updated by Victor Julien about 1 year ago
- Related to Bug #6588: DPDK 'ips' mode doesn't pass TCP traffic added