Messages

[dev.netmap.buf_size]

I would like to respond on this thread. I think its an important topic till this day.

We also have Suricata running in IPS mode. Which is using netmap under the hood.

I found and read the following reply from Giuseppe, which is one of the collaborators of netmap here.


Stating:

The one you are interested in are ring_num and buf_num

Meaning, you can of course increase the buffer size itself, but you most likely want to increase the number of buffers available to netmap.

What I tried thus far is:

• Doubling the buffer size, by setting; dev.netmap.buf_size to: 4096
• More importantly increase the buffers, using; dev.netmap.buf_num to 327680
• As well as setting; dev.netmap.ring_num to 400

You might want to add these values to the tunables and then reboot the system.

WARNING:

Increasing this values do requires sufficient RAM memory to be present (at least 4GB or more). You have been warned in case you do not have enough RAM left.

During reboot Suricata might use some CPU cycles and sysctl dev.netmap | grep curr will initially show "0" until everything is allocated. I believe this is expected.

Eventually dev.netmap.buf_curr_num should match the buf_num set earlier.

That being said... Running a speedtest over a 3+ Gbit/s fiber connection still causes buffer issues in netmap however, despite these settings above:

Code Select Expand

2025-10-17T02:00:29 Notice kernel [99224] 229.066251 [4335] netmap_transmit           ax1 full hwcur 430 hwtail 179 qlen 250
2025-10-17T02:00:29 Notice kernel [99224] 229.059118 [4335] netmap_transmit           ax1 full hwcur 430 hwtail 179 qlen 250
2025-10-17T02:00:28 Notice kernel [99223] 228.063878 [4335] netmap_transmit           ax1 full hwcur 448 hwtail 194 qlen 253
2025-10-17T02:00:28 Notice kernel [99223] 228.055056 [4335] netmap_transmit           ax1 full hwcur 449 hwtail 224 qlen 224
2025-10-17T02:00:27 Notice kernel [99222] 227.047952 [4335] netmap_transmit           ax1 full hwcur 288 hwtail 505 qlen 294
2025-10-17T02:00:27 Notice kernel [99222] 227.039051 [4335] netmap_transmit           ax1 full hwcur 289 hwtail 68 qlen 220
2025-10-17T02:00:26 Notice kernel [99221] 226.092928 [4335] netmap_transmit           ax1 full hwcur 467 hwtail 238 qlen 228
2025-10-17T02:00:26 Notice kernel [99221] 226.084023 [4335] netmap_transmit           ax1 full hwcur 468 hwtail 240 qlen 227
2025-10-17T02:00:25 Notice kernel [99220] 225.196415 [4335] netmap_transmit           ax1 full hwcur 233 hwtail 482 qlen 262
2025-10-17T02:00:25 Notice kernel [99220] 225.188117 [4335] netmap_transmit           ax1 full hwcur 483 hwtail 233 qlen 249
2025-10-17T02:00:24 Notice kernel [99219] 224.038394 [4335] netmap_transmit           ax1 full hwcur 54 hwtail 338 qlen 227
2025-10-17T02:00:24 Notice kernel [99219] 224.030190 [4335] netmap_transmit           ax1 full hwcur 339 hwtail 54 qlen 284
2025-10-17T02:00:23 Notice kernel [99218] 223.335506 [4335] netmap_transmit           ax1 full hwcur 301 hwtail 29 qlen 271
2025-10-17T02:00:23 Notice kernel [99218] 223.325235 [4335] netmap_transmit           ax1 full hwcur 30 hwtail 301 qlen 240
2025-10-16T22:57:20 Notice kernel [88235] 240.462029 [4335] netmap_transmit           ax1 full hwcur 466 hwtail 188 qlen 277
2025-10-16T22:57:20 Notice kernel [88235] 240.452645 [4335] netmap_transmit           ax1 full hwcur 189 hwtail 466 qlen 234
2025-10-16T17:41:57 Notice kernel [69312] 317.711273 [4335] netmap_transmit           ax1 full hwcur 169 hwtail 391 qlen 289
2025-10-16T17:41:57 Notice kernel [69312] 317.702335 [4335] netmap_transmit           ax1 full hwcur 170 hwtail 483 qlen 198
2025-10-16T13:31:43 Notice kernel [54299] 303.926446 [4335] netmap_transmit           ax1 full hwcur 463 hwtail 188 qlen 274
2025-10-16T06:41:43 Notice kernel [29698] 703.601969 [4335] netmap_transmit           ax1 full hwcur 12 hwtail 270 qlen 253
2025-10-16T06:41:43 Notice kernel [29698] 703.593897 [4335] netmap_transmit           ax1 full hwcur 271 hwtail 12 qlen 258
2025-10-16T06:41:43 Notice kernel [135] ax1: VLAN Stripping Disabled
2025-10-16T06:41:43 Notice kernel [135] ax1: VLAN filtering Disabled
2025-10-16T06:41:43 Notice kernel [135] ax1: Receive checksum offload Disabled
2025-10-16T06:41:43 Notice kernel [135] ax1: RSS Enabled
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 7
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 6
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 5
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 4
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 3
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 2
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 1
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 0
2025-10-16T06:41:43 Notice kernel [135] ax1: VLAN Stripping Disabled
2025-10-16T06:41:43 Notice kernel [135] ax1: VLAN filtering Disabled
2025-10-16T06:41:43 Notice kernel [135] ax1: Receive checksum offload Disabled
2025-10-16T06:41:43 Notice kernel [135] ax1: RSS Enabled
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 7
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 6
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 5
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 4
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 3
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 2
2025-10-16T06:41:43 Notice kernel [135] ax1: xgbe_config_sph_mode: SPH disabled in channel 1

So at this moment I also monitored the processes using ps -axfu during a speedtest. As expected Suricata is using the most CPU cycles, but not maxing out, meaning there is more CPU power left that Suricata is not using.

My conclusion: Increase the buffers might help but doesn't solve the issue. Suricata is just too slow, at this moment, in processing the traffic. Or finally, other fine tuning or configuration might be required to not fill the buffer too much. I have no idea what other tunables options might increase the throughput of Suricata in IPS mode. Maybe enabling RSS?? No idea at this moment how to continue further.

Ps. I also found this note: https://docs.opnsense.org/troubleshooting/performance.html#note-regarding-ips saying that limited by 1 thread. But not sure if this note is still valid or not.

[Solution:]

I also noticed the same issue in v25.7.5:

And yes I have set "Interfaces" of NTP to "All (recommended)". Which is the default value and correct.

Ps. /var/etc/ntpd.conf file is just a generated file, but the file is present.

Code Select Expand

2025-10-12T08:41:23    Notice    kernel     [131] 283.499506 [ 853] iflib_netmap_config       txr 8 rxr 8 txd 512 rxd 512 rbufsz 2048
2025-10-12T08:41:23    Notice    kernel     [131] 283.436679 [ 853] iflib_netmap_config       txr 8 rxr 8 txd 512 rxd 512 rbufsz 2048
2025-10-12T08:41:23    Notice    kernel     [131] 283.429322 [ 853] iflib_netmap_config       txr 8 rxr 8 txd 512 rxd 512 rbufsz 2048
2025-10-12T08:41:23    Notice    kernel     [131] 283.422089 [ 853] iflib_netmap_config       txr 8 rxr 8 txd 512 rxd 512 rbufsz 2048
2025-10-12T08:40:07    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (execute task : wireguard_sync())
2025-10-12T08:40:07    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (execute task : webgui_configure_do(,[opt1]))
2025-10-12T08:40:07    Notice    kernel     <6>[54] pid 50572 (ntpd), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
2025-10-12T08:40:07    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (execute task : vxlan_configure_do())
2025-10-12T08:40:07    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (execute task : unbound_configure_do(,[opt1]))
2025-10-12T08:40:07    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (execute task : openssh_configure_do(,[opt1]))
2025-10-12T08:40:07    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (execute task : opendns_configure_do())
2025-10-12T08:40:07    Error    opnsense     /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '70', the output was 'daemon control: got EOF'
2025-10-12T08:40:06    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (execute task : ntpd_configure_do())
2025-10-12T08:40:06    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (execute task : dhcrelay_configure_if(,[opt1],inet6))
2025-10-12T08:40:06    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (,[opt1],inet6)
2025-10-12T08:40:06    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure vpn (execute task : wireguard_configure_do())
2025-10-12T08:40:06    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure vpn (execute task : openvpn_configure_do(,[opt1]))
2025-10-12T08:40:06    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure vpn (execute task : ipsec_configure_do(,[opt1]))
2025-10-12T08:40:06    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure vpn (,[opt1],inet6)
2025-10-12T08:40:05    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure monitor (execute task : dpinger_configure_do(,[WAN_FTTH_DHCP6]))
2025-10-12T08:40:05    Notice    opnsense     /usr/local/etc/rc.newwanipv6: plugins_configure monitor (,[WAN_FTTH_DHCP6])
2025-10-12T08:40:05    Notice    opnsense     /usr/local/etc/rc.newwanipv6: ROUTING: keeping inet6 default route to fe80::726d:15ff:feea:f800%pppoe0
2025-10-12T08:40:05    Notice    opnsense     /usr/local/etc/rc.newwanipv6: ROUTING: configuring inet6 default gateway on opt1
2025-10-12T08:40:05    Notice    opnsense     /usr/local/etc/rc.newwanipv6: ROUTING: entering configure using opt1
2025-10-12T08:40:05    Notice    opnsense     /usr/local/etc/rc.newwanipv6: IP renewal starting (address: fe80::f690:eaff:fe01:2be0%pppoe0, interface: opt1, device: pppoe0)
2025-10-12T08:40:05    Notice    kernel     <118>[52]  SSH:   SHA256 n7ax3CA2BMRgq16CrHNPdXgrdxXqkHq2VSEJVQ4YRJY (RSA)
2025-10-12T08:40:05    Notice    kernel     <118>[52]  SSH:   SHA256 92s47heG5ihS5fzETP/iCTAnSng42anazcEKE8sw8qs (ED25519)
2025-10-12T08:40:05    Notice    kernel     <118>[52]  SSH:   SHA256 nKDcJMQ4iwjdJRyl0J8m2uKj52vQpergfcLuz1Eu8JM (ECDSA)
2025-10-12T08:40:05    Notice    kernel     <118>[52]                B8 03 4C D7 E0 59 14 34 91 96 34 95 FC 40 39 F7
2025-10-12T08:40:05    Notice    kernel     <118>[52]  HTTPS: sha256 FE D8 BE D2 C5 6F B1 15 0F C1 47 70 1B 57 C7 75
2025-10-12T08:40:05    Notice    kernel     <118>[52]
2025-10-12T08:40:05    Notice    kernel     <118>[52]  WAN_RAW (ax0)   ->
2025-10-12T08:40:05    Notice    kernel     <118>[52]                     v6/DHCP6: fe80::f690:eaff:fe01:2be0%pppoe0/64
2025-10-12T08:40:05    Notice    kernel     <118>[52]  WAN_FTTH (pppoe0) -> v4/PPPoE: 77.61.56.117/32
2025-10-12T08:40:05    Notice    kernel     <118>[52]  RouterWireguard (wg0) -> v4: 192.168.2.1/24
2025-10-12T08:40:05    Notice    kernel     <118>[52]                     v6: 2a02:22a0:bbba:f900::1/64
2025-10-12T08:40:05    Notice    kernel     <118>[52]  LAN_SFP (ax1)   -> v4: 192.168.1.1/24
2025-10-12T08:40:05    Notice    kernel     <118>[52]  LAN_MANAGEMENT (igc0) -> v4: 192.168.2.1/24
2025-10-12T08:40:05    Notice    kernel     <118>[52]  LAN_4 (igc3)    ->
2025-10-12T08:40:05    Notice    kernel     <118>[52]  LAN_3 (igc2)    ->
2025-10-12T08:40:05    Notice    kernel     <118>[52]  LAN_2 (igc1)    ->
2025-10-12T08:40:05    Notice    kernel     <118> LAN_1_BRIDGE (bridge0) -> v4: 192.168.3.1/24
2025-10-12T08:40:05    Notice    kernel     <118>[52]
2025-10-12T08:40:05    Notice    kernel     <118>*** OPNsense.home: OPNsense 25.7.5 (amd64) ***
2025-10-12T08:40:05    Notice    kernel     <118>[52]
2025-10-12T08:40:05    Notice    kernel     <118>[52] Sun Oct 12 08:40:05 CEST 2025
2025-10-12T08:40:05    Notice    kernel     <118>[52] Root file system: zroot/ROOT/default
2025-10-12T08:40:04    Notice    kernel     <6>[51] pid 19904 (ntpd), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : wireguard_sync())
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : webgui_configure_do(,[opt1]))
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : vxlan_configure_do())
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : unbound_configure_do(,[opt1]))
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : openssh_configure_do(,[opt1]))
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : opendns_configure_do())
2025-10-12T08:40:03    Error    opnsense     /usr/local/etc/rc.newwanip: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '70', the output was 'daemon control: got EOF'
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : ntpd_configure_do())
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure newwanip (execute task : dhcrelay_configure_if(,[opt1],inet))
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure newwanip (,[opt1],inet)
2025-10-12T08:40:03    Notice    kernel     <118>[51] >>> Invoking start script 'beep'
2025-10-12T08:40:03    Notice    kernel     <118>[51] Service `sysctl' has been restarted.
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure vpn (execute task : wireguard_configure_do())
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure vpn (execute task : openvpn_configure_do(,[opt1]))
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure vpn (execute task : ipsec_configure_do(,[opt1]))
2025-10-12T08:40:03    Notice    opnsense     /usr/local/etc/rc.newwanip: plugins_configure vpn (,[opt1],inet)
2025-10-12T08:40:03    Notice    opnsense     /usr/local/sbin/pluginctl: plugins_configure crl (execute task : openvpn_refresh_crls(1))
2025-10-12T08:40:03    Notice    kernel     <118>[51] >>> Invoking start script 'sysctl'
2025-10-12T08:40:03    Notice    opnsense     /usr/local/sbin/pluginctl: plugins_configure crl (execute task : core_trust_crl(1))
2025-10-12T08:40:03    Notice    opnsense     /usr/local/sbin/pluginctl: plugins_configure crl (1)
2025-10-12T08:40:03    Notice    kernel     <118>[51] >>> Invoking start script 'openvpn'
2025-10-12T08:40:03    Notice    kernel     OK
2025-10-12T08:40:03    Notice    syslog-ng     Configuration reload finished;
2025-10-12T08:40:03    Notice    syslog-ng     Configuration reload request received, reloading configuration;
2025-10-12T08:40:03    Warning    syslog-ng     WARNING: Configuration file format is newer than the current version, please specify the current version number (4.8) in the @version directive. syslog-ng will operate at its highest supported version in this mode; config-version='4.10'

Logging of NTP service itself is pretty clear about the issue as well:

Code Select Expand

2025-10-12T22:00:45 Error ntpd daemon child died with signal 11
2025-10-12T22:00:45 Error ntpd unable to create socket on wg0 (10) for 192.168.2.1:123
2025-10-12T22:00:45 Error ntpd bind(30) AF_INET 192.168.2.1:123 flags 0x11 failed: Address already in use
2025-10-12T22:00:42 Error ntpd daemon child died with signal 11
2025-10-12T22:00:42 Error ntpd unable to create socket on wg0 (10) for 192.168.2.1:123
2025-10-12T22:00:42 Error ntpd bind(30) AF_INET 192.168.2.1:123 flags 0x11 failed: Address already in use
2025-10-12T22:00:36 Error ntpd daemon child died with signal 11
2025-10-12T22:00:36 Error ntpd unable to create socket on wg0 (10) for 192.168.2.1:123
2025-10-12T22:00:36 Error ntpd bind(30) AF_INET 192.168.2.1:123 flags 0x11 failed: Address already in use
2025-10-12T21:58:13 Error ntpd daemon child died with signal 11
2025-10-12T21:58:13 Error ntpd unable to create socket on wg0 (10) for 192.168.2.1:123
2025-10-12T21:58:13 Error ntpd bind(30) AF_INET 192.168.2.1:123 flags 0x11 failed: Address already in use
2025-10-12T21:58:06 Error ntpd daemon child died with signal 11
2025-10-12T21:58:06 Error ntpd unable to create socket on wg0 (10) for 192.168.2.1:123
2025-10-12T21:58:06 Error ntpd bind(30) AF_INET 192.168.2.1:123 flags 0x11 failed: Address already in use
2025-10-12T21:57:49 Error ntpd daemon child died with signal 11
2025-10-12T21:57:49 Error ntpd unable to create socket on wg0 (10) for 192.168.2.1:123
2025-10-12T21:57:49 Error ntpd bind(30) AF_INET 192.168.2.1:123 flags 0x11 failed: Address already in use
2025-10-12T08:40:07 Error ntpd daemon child died with signal 11
2025-10-12T08:40:07 Error ntpd unable to create socket on wg0 (10) for 192.168.2.1:123
2025-10-12T08:40:07 Error ntpd bind(30) AF_INET 192.168.2.1:123 flags 0x11 failed: Address already in use
2025-10-12T08:40:03 Error ntpd daemon child died with signal 11

In my case it was related to my Wireguard setup. Since  192.168.2.1 is my wireguard instance tunnel address.

Solution: Be sure all your subnets are unique! So I apparently was using this subnet already on another interface. So instead of "reinstalling", try to look if you have any conflicts on your interfaces..

So in my case the solution was to move Wireguard to 192.168.4.x subnet. As stated of course here under "Note": https://docs.opnsense.org/manual/how-tos/wireguard-client.html#step-1-configure-the-wireguard-instance

I know it's an old topic..

But I believe you should select your LAN interface only in Suricata. If not, correct me below via a reply comment.

Now I'm actually more confused.. What is your final verdict here?

To which value should I set it, considering all the information I gave you?

Hi,

After reading the following topic about how-to setup a Shaper to get rid of bufferbloat: https://docs.opnsense.org/manual/how-tos/shaper_bufferbloat.html#quantum

Regarding the correct value for "Quantum" its stated:

The proper value of Quantum should be no more or less than is the WAN MTU.

However, while this might sound clear. This is still too ambiguous for me.

I have fiber connection from my ISP using PPPoE, which is 1500 bytes.
However PPPoE has a connection overhead of 8 Bytes, so the WAN interface with VLAN 6 tag has a MTU of 1508.
So I have set 1508 MTU on my WAN interface (Identifier: opt1, device: ppoe0).

But that is not all, I also have a 'WAN RAW' interface configured as well (Identifier: opt6, device: ax0). Which has the overhead of the VLAN of 4 bytes, meaning that MTU setting is 1512.

Meaning "WAN MTU" term is too ambiguous for me. So what value should I use now for quantum; 1500, 1508 or 1512?

I guess 1512 in my case. Right or not? This could be written more clearly.

Thanks in advance!

Kind regards,
Melroy van den Berg

You're not alone. I also have kernel crashes.. https://forum.opnsense.org/index.php?topic=45138.msg225446#msg225446

It's important the swap is on persistent storage like:

Code Select Expand

Device:       1024-blocks     Used:
/dev/gpt/swapfs   8620216         0

What is your output of the command I gave you earlier?

If there is really a kernel crash happening, and the crash gets logged to the swap partition, after an automatically system restart the kernel crash report should be visible at: System -> Firmware -> Reporter.

If you see "No issues were detected.", there has been no kernel crash. Or the kernel crash was not stored on your swap partition.

You will need a swap partition in order to see kernel crashes getting logged.

Check if you have a swap by executing (only a swap on persistent storage will work):

Code Select Expand

swapctl -l

If you mean other kind of software crashes, like services maybe crashing in the background (aka not a kernel crash), then you might take a look at the log files. For example System -> Log Files -> General

WOw uhmm ok.

• Do NOT enable IDS/IPS on Vlan interfaces. And you also do not need to select WAN. Then also uncheck "Promiscuous mode". And also uncheck "Enable syslog alerts" (unless you have a good reason to have syslog alerts?).
• Then also which rulesets did you downloaded? You didn't show that. I hope you didn't downloaded all.. That is also a bad idea
• Last but not least, you are setting all the rules to "Alert", meaning you do not even block any request with your current IPS setup. Why?

I'm also not maxing out the CPU and definitely not the memory. I would have the same question, I was hoping to get more throughput. So we are in the same boat, but let's help each other.

First, what are the intrusion detection settings you have?

I share my configs so you know what kind of information I'm after.

Under: Services -> ID -> Administration:

• Intrusion Detection -> Checked
• IPS Mode -> Checked
• Interfaces -> ONLY selected one interface. Which is my LAN interface.
• Pattern matcher -> Hyperscan (if your hardware allows it?)
• Under the "Download", I enabled / downloaded the following rules:
  
  
  Code Select Expand
  abuse.ch/Feodo Tracker, abuse.ch/ThreatFox, abuse.ch/URLhaus, ET open/botcc, ET open/drop, ET open/dshield, ET open/emerging-dos, ET open/emerging-exploit, ET open/emerging-exploit_kit, ET open/emerging-phishing, ET open/emerging-scan, ET open/emerging-shellcode, ET open/emerging-sql, ET open/emerging-web_server, ET open/emerging-worm

Then I go to: Services -> ID -> Policy.

Create a new policy:

• Enabled -> Checked
• Rulesets -> Selecting all of the above (which I downloaded)
• Action -> Alert
• New action -> Drop

Please, share your setup.

Last but not least, what kind of tunables did you apply??

I will answer my own question, also for others in the future. After playing around with it bit, and a bit of trial and error.

So the idea of Services -> Intrusion Detection -> Policy. Is you are able to manage both whole multiple rulesets together under "Policies" as well as fine-tune specific rules under "Rule adjustments" tab.

So let's start with the Policies tab. You can create a new policy rule, selecting the rulesets that you want to adjust. Then select for the "Action" the value "Alert". And as "New action" you could select "Drop".

That will automatically change all the rules under the rulesets from Alert to Drop. Thus without the need of changing all the rules manually under the Administration -> Rules tab.

While this all makes very much sense if you understand it. The different menu (sub-menu) items, different naming conventions and the lack of documentation can make this policy feature rather confusing. Especially if you are new to Intrusion detection and these settings (I personally would for example not put rule adjustments under Policy).

Next, the Rule adjustments tab. Allows you to manually adjust a single rule. For example, let's say just enabled the whole ruleset from alert to drop using this policy. However, with rule adjustments can enter a specific SID (rule number) and either disable this rule and/or move the action back to Alert instead of drop again.

@meyergru Can I ask one final question?

I notice that IDS/IPS can optionally also include block lists like Spamhaus, right? However, I notice some people will use maybe a firewall alias for Spamhaus and block the traffic under firewall rules..

So my question would be: Would it be more performant (keep higher throughput) if some of these checks like Spamhaus will be done under the firewall settings rather than under Instruction Detection? Since for some reason, I have the feeling that Instruction Detection is much more demanding than just a firewall block, while again a simple block list like Spamhaus doesn't necessary need to be part of IDS/IDS, Spamhaus (and alike) can be part of a block list...?

I hope my story/question is clear.

IDS mode can inspect packets after the fact and only generate an alarm. At this time, the packet was already processed. IPS mode has to actually check all the rules before it will decide on whether to actually allow the packet to pass.

Now I think about this, this makes of course a lot of sense! So IDS mode is just written differently. And indeed IPS needs to be blocking the traffic if it does find something, so it can not do any post-processing after the fact. Thanks!

I would still like to understand why there is such a big performance impact (I also see a massive reduction in speeds) when enabling IPS Mode.

The reason that I find it strange is that when I only enable  Intrusion Detection (so just IDS), it's very fast. But the system is still checking all the packages, after all it will alert on find matches.

And IPS Mode is basically doing all of the same, but then it will also drop the connection on the rules instead of only an alert. So why is IPS mode so much worse performance wise? I still do not get it.

I think action & new action fields are still very unclear to me, poorly documented also at: https://docs.opnsense.org/manual/ips.html#policies

Hopefully this documentation can be improved. And better explain what the difference is between "Action" vs "New action"  for example. As well as better explain what metadata rules per category are/do.