OPNsense Forum
Archive => 22.1 Legacy Series => Topic started by: sja1440 on March 09, 2022, 12:31:28 pm
-
My question is: why does IPS mode with vlans work without using Promiscuos mode on 22.1 and 21.7?
I have read the Opnsense documentation on using IPS mode with vlans and I have also seen various posts about related issues.
After many months of trying to get IPS mode with vlans to work stably, I finally succeeded with opnsense 21.7 by ignoring one piece of official advice: I do not use Promiscuous mode on my interfaces or with Suricata.
Of course, it might be that my configuration is incorrect or inconsistent or even that it has uncovered a bug somewhere. But the point is, on my hardware at least, it seems to work on 22.1 as it did on 21.7.
Below is a summary of my configuration. I use IPS on two internal interfaces (LAN and DMZ) both with vlans. The hostname of my Opnsense firewall is OHM.
Hardware: Intel J3160 4 core box with 4x Intel i210-AT Gigabit Ethernet
Opnsense version: OPNsense 22.1.2_1-amd64
Interfaces:LAN (igb1): Promiscuous mode: no
Interfaces:DMZ (igb3): Promiscuous mode: no
Interfaces: Settings
Hardware CRC: disabled
Hardware TSO: disabled
Hardware LRO: disabled
VLAN Hardware Filtering: disabled
Services: Intrusion Detection: Administration
Enabled: yes
IPS mode: yes
Promiscuous mode: No
Pattern matcher: Hyperscan
Interfaces: DMZ,LAN
Here is the evidence confirming that promiscuous mode is not activate on any interface:
root@OHM:~ # ifconfig | grep -i prom
pflog0: flags=20100<PROMISC,PPROMISC> metric 0 mtu 33160
Here is the evidence that Suricata is indeed listening on the hardware and the vlans
Extract from /var/log/suricata/latest.log:
<Notice> -- opened netmap:igb3/R from igb3: 0x855a93000
<Notice> -- opened netmap:igb3^ from igb3^: 0x855a93300
<Notice> -- opened netmap:igb3^ from igb3^: 0x881093000
<Notice> -- opened netmap:igb3/T from igb3: 0x881093300
<Notice> -- opened netmap:igb1/R from igb1: 0x8ac693000
<Notice> -- opened netmap:igb1^ from igb1^: 0x8ac693300
<Notice> -- opened netmap:igb1^ from igb1^: 0x8d7c93000
<Notice> -- opened netmap:igb1/T from igb1: 0x8d7c93300
<Notice> -- all 4 packet processing threads, 4 management threads initialized, engine started.
To verify that Suricata is indeed triggering, I have crafted a few non invasive custom rules (one drop and one alert) which trigger only when I do certain actions on the network. By the way, once you create a rule, before testing it you need to await the 'rule reload complete' Suricata log entry - this can take many minutes. On triggering my test conditions, the relevant Suricata log entries are indeed there.