Bug 236219

Summary:	netmap bug pf set prio
Product:	Base System	Reporter:	r.gabet
Component:	kern	Assignee:	freebsd-net (Nobody) <net>
Status:	Closed Works As Intended
Severity:	Affects Some People	CC:	markj, vmaffione
Priority:	---
Version:	11.2-STABLE
Hardware:	Any
OS:	Any

Description r.gabet 2019-03-04 14:25:53 UTC

Hi,

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.


https://forum.opnsense.org/index.php?topic=7372

Comment 1 Vincenzo Maffione freebsd_committer

2019-03-06 12:03:26 UTC

Hi,
  This is the documentation of what exactly?

Comment 2 r.gabet 2019-03-07 07:13:18 UTC

Sorry, I forgot to precise, it's "set prio" of packet filter.

https://www.freebsd.org/cgi/man.cgi?query=pf.conf&apropos=0&sektion=0&manpath=FreeBSD+11.2-stable&arch=default&format=html

Comment 3 Vincenzo Maffione freebsd_committer

2019-03-07 09:51:48 UTC

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.

Comment 4 r.gabet 2019-03-08 12:56:36 UTC

However, the packets still passe by packet filter, even with the IPS enabled. I can see them when I enable logging.

Comment 5 Vincenzo Maffione freebsd_committer

2019-03-08 14:08:49 UTC

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.

Comment 6 r.gabet 2019-03-11 06:58:09 UTC

Yes, Suricata is configured to forward packets between the physical interface and its host rings.

Comment 7 Vincenzo Maffione freebsd_committer

2019-03-11 08:44:36 UTC

If you are using a physical interface (e.g. em0 with em0+), where do VLANs come into the picture?

Comment 8 r.gabet 2019-03-14 07:14:36 UTC

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.

Comment 9 Vincenzo Maffione freebsd_committer

2019-03-14 08:13:10 UTC

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.