Important Info: Inline IPS Mode with Suricata and VLANs
-
@cyb3rtr0nian said in Important Info: Inline IPS Mode with Suricata and VLANs:
This is correct. The netmap implementation in FreeBSD does not deal with VLAN tags. They do indeed get stripped out.
Such a shame though, I mean Pfsense+Suricata is an amazing product already, but it would be even more amazing if we could combine both the segmentation of VLANs with the policing of Suricata inline IPS don’t you think? I have it running in IDS mode with several VLANs on the untagged interface. (But I still prefer the In-line IPS mode. ) Will there ever be a different emulation device used in the future capable of reading VLAN tags you think?
I seriously doubt the netmap limitations within FreeBSD itself with regard to VLANs will be fixed in the future because it would require rewriting substantial portions of the kernel network stack code. That would potentially break other things.
One thing currently implemented in the pfSense Suricata package is a software-enforced ban on using emulated netmap adapters. This was done in the interest of speed (and because of some other quirks that once existed with the emulated netmap adapter). The creation of IPS mode on an interface is restricted unless the NIC driver supports native netmap operation. VLAN interfaces are inherently a virtual interface in the operating system and thus can never pass the "native mode" test for netmap operation. The pfSense Suricata package silently adjusts any VLAN-enabled IPS interfaces to use the physical NIC instead of the VLAN virtual interface.
There have been a few beneficial updates to the netmap adapter code in recent editions of FreeBSD. None of them address the fundamental slowdown you experience when using a host stack endpoint, though.
It would be possible to make some test edits to the PHP source code of the package to enable IPS operation with virtual VLAN interfaces using the emuated netmap adapter. I suspect throughput will be pretty abysmal unless you have a very powerful CPU, but someone may want to test it. I do not have a VLAN setup in my private LAN. I keep it pretty simple, and I no longer have a large test lab either. But if you want to tinker around with emulated netmap, I can share which sections of PHP code to edit. It's fairly trivial. There is one caveat, though. The emulated adapter with VLANs will only work on the newest versions of pfSense Plus (and possibly 2.8.0 DEVEL once those snapshots resume). It will not work without throwing a syntax error on pfSense 2.7.2 CE and versions earlier. The
libnetmapcode update that allows proper parsing of VLAN interfaces by netmap was only added to pfSense with the move to FreeBSD 15-CURRENT. That code fix is not present in earlier pfSense kernels. -
Just found out about this thread and am curious to ask...
If I understand correctly, neither Snort or Suricata are capable of differentiating traffic through VLAN's from their parent interface and therefore cant do inline filtering at the VLAN level...
I didnt know this, and created a Snort instance for each VLAN I have on my lan (parent interface) using different rulesets (some VLANs are more restrictive than others, etc etc...)
Unless I am wrong (and I need to do more testng) is that I noticed what you described (i.e. if something is blocked on a VLAN, it is blocked on all VLANs of the same parent interface). However, the advantage of having snort run on VLAN's instead of the parent interface is that in the reports tab, I can tell on which VLAN the block occured. I find it more straightforward to troubleshoot something that way.
IS there any drawback other than consuming more resources ? I didnt notice any instabilities at the firewall level so far.....
-
@pftdm007 said in Important Info: Inline IPS Mode with Suricata and VLANs:
Just found out about this thread and am curious to ask...
If I understand correctly, neither Snort or Suricata are capable of differentiating traffic through VLAN's from their parent interface and therefore cant do inline filtering at the VLAN level...
I didnt know this, and created a Snort instance for each VLAN I have on my lan (parent interface) using different rulesets (some VLANs are more restrictive than others, etc etc...)
Unless I am wrong (and I need to do more testng) is that I noticed what you described (i.e. if something is blocked on a VLAN, it is blocked on all VLANs of the same parent interface). However, the advantage of having snort run on VLAN's instead of the parent interface is that in the reports tab, I can tell on which VLAN the block occured. I find it more straightforward to troubleshoot something that way.
IS there any drawback other than consuming more resources ? I didnt notice any instabilities at the firewall level so far.....
It should be fine to continue with your current configuration. As you observed, under the covers Snort is actually running on the physical parent interface and polices traffic at that level (meaning all VLANs on the same parent are treated as a single network). This is due to the how the netmap kernel device in FreeBSD is wired into the network stack. It does not see the VLAN tags. It's the netmap device that makes IPS mode possible, and since it can't see VLAN tags, then IPS mode can't use them to separate and treat the defined VLANs differently.
