I use "set priority", it's working fine, the priority value is reflected in the VLAN header.
According to the documentation :
"Set the priority of packets matching this rule. If both priorities are set here, packets with a TOS of "lowdelay" or TCP ACKs with no data payload will be assigned the latter. If the packets are transmitted on a VLAN interface, the queueing priority will be written as the priority code point in the 802.1Q VLAN header."
But if I use suricata in IPS mode with netmap, the priority vlan isn't set.
This is the documentation of what exactly?
Sorry, I forgot to precise, it's "set prio" of packet filter.
I see. The behaviour you are observing is expected, because netmap is a kernel bypass solution. This means that packets are transmitted from user-space to the NIC without going through the normal kernel stack datapath, including pf/ipfw and similar.
The reason for bypassing everything is efficiency (at least assuming that your IPS interface has native netmap support).
In other words it is not doable to get the behaviour that you are looking for.
However, the packets still passe by packet filter, even with the IPS enabled. I can see them when I enable logging.
Is suricata using netmap over a VLAN interface (rather than a physical interface)?
In that case you are going through the "emulated netmap adapter", which is a way to use netmap (at reduced performance, and with some functional limitation) over any Ethernet interface. In other words, VLAN interfaces do not (and cannot) have native netmap support (e.g. like ixl, ixgbe, em, vtnet, vmx, etc).
This may explain what you see, since in emulated mode you are still partially using the network stack.
Or maybe your suricata is configured to forward packets between the physical interface and its host rings (e.g. between "igb" and "igb+"), which means that packets actually pass through the FreeBSD network stack, and therefore through pf.
In any case netmap does not touch the packets in any way, and does not call into any firewall or similar packet processing element.
Yes, Suricata is configured to forward packets between the physical interface and its host rings.
If you are using a physical interface (e.g. em0 with em0+), where do VLANs come into the picture?
Sorry for confusion, Suricata is configured to forward between em0_vlan70 and em0_vlan70+ in both direction.
I also tried to use directly physical interface but the vlan 70 isn't working.
This is already an issue by itself. Netmap is not designed to run on VLAN interfaces. The application should always open the phisical interface and play with VLAN headers directly. Of course if suricata does not support this you would need to implement that.
Think of Netmap over VLAN interfaces as a thing that "kind of works" (at slow rate, however, because emulated mode is necessary), but that can show some quirks w.r.t. the kernel stack.