IPS cut off GUI access from WAN

[marianh]

Enabling IPS cut off GUI access from WAN. Only solution is to kill suricata process.
Cut off - ping from OPNsense to upstream gateway works but I cannot access GUI (connection timeout).
NIC: em0 - Intel Pro/1000 7.6.1 also 7.6.2.
Offloads completely disabled. No IPS rulesets loaded. No alerts.
I did packet capture and it seems that OPNsense and my workstation communicates.

Enabling IPS:
Sep 7 09:27:33    kernel: 253.050654 [ 274] generic_find_num_queues called, in txq 0 rxq 0
Sep 7 09:27:33    kernel: 253.036456 [ 266] generic_find_num_desc called, in tx 1024 rx 1024
Sep 7 09:27:33    kernel: 253.022228 [ 798] generic_netmap_dtor Restored native NA 0
Sep 7 09:27:33    kernel: 253.008023 [ 274] generic_find_num_queues called, in txq 0 rxq 0
Sep 7 09:27:33    kernel: 252.996591 [ 266] generic_find_num_desc called, in tx 1024 rx 1024
Sep 7 09:27:33    kernel: 252.979590 [ 798] generic_netmap_dtor Restored native NA 0
Sep 7 09:27:33    kernel: 252.965387 [1233] netmap_mem_global_config reconfiguring
Sep 7 09:27:33    kernel: 252.951174 [ 274] generic_find_num_queues called, in txq 0 rxq 0
Sep 7 09:27:33    kernel: 252.931346 [ 266] generic_find_num_desc called, in tx 1024 rx 1024


Disabling IPS:
Sep 7 09:28:49    kernel: 329.427691 [ 798] generic_netmap_dtor Restored native NA 0

[AdSchellevis]

Hi marianh,

If all hardware offloading is off, you could try to use the original driver from intel.
There seem to be more issues with the ones delivered standard in FreeBSD.

If you want to try this, make sure you're running the latest version of OPNsense (if you weren't already, you should try an upgrade first).
Then execute this in the console:

Code Select Expand

pkg install intel-em-kmod


And add the following to your /boot/loader.conf:

Code Select Expand

if_em_updated_load="YES"


Eventually we will make it easier to install intel's standard.

Best regards,

Ad

[marianh]

Hi, AdSchellevis

as I wrote in my first post, I already have intel-em-kmod (7.6.2) in my system.

[franco]

What's your WAN config? PPPoE, VLAN, etc?

[marekdes]

PPPoE - no
VLAN - no

It's even worse, it disables whole OPNsense, LAN clients cannot access internet.
I am unable to find any log which would enlighten my situation.

[franco]

So what's your NIC driver? Your hardware platform? Which OPNsense version? What interfaces are in IPS mode? How are they configured?

Lots of things that can lead to the same result, lots of solutions, too. :)

[marekdes]

NIC driver: Intel(R) PRO/1000 Network Connection 7.6.2
Hardware platform: amd64
OPNsense version: 16.7.3-amd64 (FreeBSD 10.3-RELEASE-p7)
What interfaces are in IPS mode: WAN
How are they configured: static IP address

[franco]

Did you check the alert log? Maybe you have a rule that blocks your traffic. It happenes to me too sometimes when I use the custom rules...

[marekdes]

Did you check the alert log?

Yes

Maybe you have a rule that blocks your traffic.

No, I have not.

[Ciprian]

Hello!
I know it's a long time since last reply to this post, but I have the same problem, meaning, the same output on console.

I can't activate IPS without network services like RDP (windows mstsc) connections or Veeam backups to not become unstable, and slow.
RDP sometimes connect, sometime doesn't, during connection initiation I see loops of "Initiating remote connection" <-> "Configuring remote connection".
Veeam backups never reaches peak performance, transfer in between the server being backed up and data storage is almost all the time at a bare minimum, with a short spike of up to 10% of the transfer speed without IPS.

I use OPNsense in a virtual environment, Vmware ESXi 5.0. Tried E1000 virtual NICs, VMXNET3... I double checked that hardware offloading to be OFF including VLANs... I don't know what else to try.

Is there anyone that managed to use OPNsense + Suricata successfully on a virtual Vmware environment? What should be done, what are the appropriate settings?

Thank you very much!

[Ciprian]

UPDATE:

Regarding this:

RDP sometimes connect, sometime doesn't, during connection initiation I see loops of "Initiating remote connection" <-> "Configuring remote connection".

It took me a while, but I found out that having "Emerging-dos" ruleset activated put a big dent on RDP connections. I haven't find the time to further isolate to a particular rule (or rules) in that ruleset, but it's definitely "emerging-dos" ruleset that is creating my problems.

Also, when I find the time to dig further, I will try to isolate the rule(set) cousing problem with Veeam BKP transfers:

Veeam backups never reaches peak performance, transfer in between the server being backed up and data storage is almost all the time at a bare minimum, with a short spike of up to 10% of the transfer speed without IPS.

Anyway, I am pretty sure now that not Suricata itself is the culprit of my network problems, but some ET rules (rulesets).